Minetest logo

IRC log for #minetest-dev, 2017-04-16

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:09 Puka joined #minetest-dev
00:33 nore hmmm, with all new keybindings of #1439, I screwed up the keybindings menu, any idea how to fix that?
00:33 ShadowBot https://github.com/minetest/minetest/issues/1439 -- Add configurable key bindings for selecting next/previous hotbar item and changing the volume by Wuzzy2
00:40 nore #5598
00:40 ShadowBot https://github.com/minetest/minetest/issues/5598 -- Add configurable key bindings for selecting next/previous hotbar item and changing the volume by Ekdohibs
00:42 nore ^ I need those rebased PRs quickly reviewed please, and I would like to know what I should do about the screwed up keybindings menu as well
00:49 kaeza joined #minetest-dev
01:19 Tmanyo joined #minetest-dev
01:49 Tmanyo joined #minetest-dev
02:57 Tmanyo joined #minetest-dev
03:47 XtremeHacker joined #minetest-dev
05:46 diegom joined #minetest-dev
05:59 DS-minetest joined #minetest-dev
06:07 cx384 joined #minetest-dev
06:52 Hunterz joined #minetest-dev
07:07 YuGiOhJCJ joined #minetest-dev
07:14 nerzhul joined #minetest-dev
07:15 celeron55 could we have something like minetest.conf.example.extra or whatever that would house all the stuff that isn't generated from builtin/settingtypes.txt
07:16 DS-minetest +
07:16 celeron55 having to manually put settings into two places would already be ridiculous, but currently there are THREE places
07:16 celeron55 it's like someone deliberately wants us to not have settings
07:18 nerzhul celeron55, i agree the duplicate settings is anoying, i don't know what is the interest of builtin/settingstypes.txt but it's a big dup
07:18 celeron55 builtin/settingstypes.txt is the canonical setting listing as it stands now; it has the most information in the most parseable format
07:19 celeron55 there's an uncommentable line at the end of mainmenu/dlg_settings_advanced.lua that causes the main menu to generate minetest.conf.example and src/settings_translation_file.cpp
07:19 nerzhul why not use it to generate minetest.conf.example then ? :p
07:19 celeron55 it can, but currently minetest.conf.example contains extra things it doesn't generate
07:19 nerzhul oh
07:20 celeron55 they need to be moved elsewhere
07:20 nerzhul maybe we should finish that work to simplify our work
07:20 celeron55 that's what my first line there ^ says
07:21 celeron55 are people ok with adding a file called minetest.conf.example.extra and putting the extra mapgen parameter topic from minetest.conf.example into there?
07:21 nerzhul sorry, i just got up :p
07:23 celeron55 alternatively builtin could be modified to understand extra sections in builtin/settingstypes.txt that aren't related to any setting in particular and ignore them for the settings menu but copy them as-is to minetest.conf.example in the place they belong, but that's probably more work than anyone wants to do right now
07:32 Warr1024 joined #minetest-dev
07:47 nerzhul omg i found a very very anoying bug on android
07:48 nerzhul when you open task list on android and kill mt from tasklist, mt stays opened in background
07:48 nerzhul the only wait to exit is to stay on the task and do a force stop
07:48 nerzhul nore merging #5596 tested it now with a fresh build
07:48 ShadowBot https://github.com/minetest/minetest/issues/5596 -- Disable android leveldb by default by Ekdohibs
07:57 nerzhul celeron55, do you want me to test your PR on android ?
07:58 nerzhul i just don't know see how can i test it really on android :p
08:00 celeron55 wait a moment, i just pushed a thing to it
08:01 nerzhul no problem, i'm working on a progressbar fix for android, it's too little for android screens
08:01 celeron55 https://github.com/minetest/minetest/pull/5595#issuecomment-294339233
08:04 nerzhul sounds interesting and the overhead is quite nice :)
08:07 celeron55 the 94% comes from the ratio of 1 MapBlock per 3*3*3 MapBlocks, which is 96%
08:07 celeron55 i mean, 3*3*3-1 MapBlocks per 3*3*3 MapBlocks
08:09 celeron55 actually, 94% is pretty much exactly 1 - 1./(3*3*2), which sounds accurate as usually one complete 1*3*3 side of the 3*3*3 (block + all neighbors) has to be updated in that situation, which is map loading
08:10 celeron55 in a situation where a block keeps updating in the middle of loaded blocks, 96% might be reached; not sure
08:11 celeron55 yeah, holy shit, it actually works that way
08:11 celeron55 on the VE-S server i see 96 hit%
08:12 celeron55 standing still, with 5 MB of cache use (at 20 MB setting)
08:13 nerzhul a strange thing, on Android the progress bar seems a little bit upper and repeat
08:16 nerzhul celeron55, #601 strange no ? i'm not an irrlicht expert and it only shows on android
08:16 ShadowBot https://github.com/minetest/minetest/issues/601 -- Install "build" and "survival" games with "make install" by kaeza
08:16 nerzhul #5601 *
08:16 ShadowBot https://github.com/minetest/minetest/issues/5601 -- Android progressbar fix by nerzhul
08:19 celeron55 the width is ok but the height isn't?
08:23 celeron55 can't guess, seems weird
08:26 celeron55 some android devices have issues with non-2^x sized textures
08:28 celeron55 https://github.com/minetest/minetest/issues/5403
08:28 celeron55 that's what people are guessing here too
08:30 celeron55 so if you just resize it to like 512x64, it will work
08:34 nerzhul yeah it's that
08:34 nerzhul i resized to 1024*128 and it's nice
08:35 nerzhul see #5601 heh :)
08:35 ShadowBot https://github.com/minetest/minetest/issues/5601 -- Android progressbar fix by nerzhul
08:39 nerzhul celeron55, are you okay with it ?
08:43 celeron55 having a separate image that is stretched like that is a pretty crude solution
08:43 celeron55 really the original image should be rendered on a 2^x texture by MT and used from it, but... eh, whatever lol
08:44 nerzhul okay, look for scaling image then
08:44 celeron55 there's a function called Align2Npot2 in client/tile.cpp that is used for a similar purpose
08:45 celeron55 i would imagine it probably does something useful 8)
08:46 celeron55 the TextureSource isn't available in the loading screen, i guess it would be able to automate all that
08:46 celeron55 or is it?
08:46 nerzhul i have a ITexture and AlignNpot2 take IImage
08:48 nerzhul oh maybe i can use a template function it should work
08:49 celeron55 uh oh maybe not
08:50 celeron55 what if you pass the client's m_tsrc (or the client and use Client::getTextureSource()) and then just ask tsrc->getTexture("progress_bar.png")
08:51 nerzhul i don't have client in this function, hmm
08:56 celeron55 (the texture source is one thing that could be global; it's thread-safe and it's not strictly meant to exist as parallel to the environment or server or anything)
08:58 celeron55 (and it's... kind of useful, lol)
09:00 nerzhul a such refactor 1 month before release is too huge for me :)
09:00 nerzhul okay drawloadscreen is called by client, and should be part of it maybe instead of being a standalone funciton, no ?
09:03 celeron55 it's called by Game too
09:03 celeron55 but it owns the client
09:04 nerzhul yeah but game has access to client
09:06 celeron55 i think you should just add ITextureSource as a parameter to draw_load_screen; then if we have non-client related UIs that need load screens, it's already there and the function won't be stuck to the client with no reason if TextureSource is made global some day
09:06 nerzhul okay, only texture_update_progress is a problem now
09:07 celeron55 it should be client's method
09:07 nerzhul not simple as it's a callback function
09:07 nerzhul i'm adding it to callbvack args
09:08 celeron55 oh... oops, true
09:09 celeron55 i for sure hope TextureSource actually does something useful, for all this hassle
09:11 nerzhul i'm trying it, we will see :)
09:14 nerzhul it's not good in fact
09:14 nerzhul client was not created at this moment :p
09:14 celeron55 oops, lol
09:14 nerzhul oh the problem can be fixed for first, we create texture_src just after
09:15 nerzhul hmmm anoying
09:15 nerzhul spagheti fix
09:15 nerzhul i think it's better to use my method for a first fix and we will cleanup later no ? :p
09:15 celeron55 the texture source becomes a prerequisite of showing the load screen instead of being a thing loaded under the load screen; that's kind of weir
09:15 celeron55 +d
09:15 nerzhul too many things to refactor to make it working
09:16 nerzhul showOverlayMessage(wgettext("Loading..."), 0, 0);
09:16 nerzhul texture_src = createTextureSource(device);
09:16 nerzhul :)
09:17 celeron55 createTextureSource is very cheap though, it doesn't actually load anything
09:17 celeron55 you could just move it above
09:19 nerzhul oh yeah it's a call member
09:19 nerzhul class*
09:19 celeron55 if you won't do it, i will do it :P
09:19 nerzhul okay it works bug i cannot load texture image :p
09:19 nerzhul (the native client not android)
09:20 nerzhul generateImage(): Could not load image "/home/nerzhul/Devel/minetest-stock/textures/base/pack/progress_bar.png" while building texture
09:20 nerzhul strange
09:20 nerzhul the path is good but it is not happy
09:21 celeron55 i've never seen that happen
09:21 nerzhul it seems it waits for a normal map...
09:21 nerzhul if (part_of_name.find("_normal.png") == std::string::npos){
09:21 celeron55 no it doesn't
09:21 celeron55 i just says a different error if it's a normal map
09:22 nerzhul exact
09:22 celeron55 driver->createImageFromFile() fails for some reason
09:22 celeron55 in the old code driver->getTexture() for the same file works
09:22 celeron55 that's weird
09:23 celeron55 actually, there's an info message that you might not see
09:23 DS-minetest already 4 people have confirmed that something is wrong with the daily ppa https://forum.minetest.net/viewtopic.php?f=6&t=17212
09:24 nerzhul 2017-04-16 11:24:00: INFO[Main]: SourceImageCache::getOrLoad(): No path found for "/home/nerzhul/Devel/minetest-stock/textures/base/pack/progress_bar.png"
09:24 nerzhul wtf
09:24 celeron55 lol i should know how this is supposed to work
09:25 celeron55 wait what do you pass to tsrc->getTexture?
09:25 celeron55 the full path? it wants only the file name
09:25 nerzhul oh
09:25 nerzhul i'm in draw_load_screen then i have full path only due to texture packs
09:25 celeron55 it's able to automatically load from textures/base/pack/
09:26 nerzhul okay trying to hardcore path
09:26 nerzhul hardcode*
09:26 nerzhul nice !
09:26 kilbith joined #minetest-dev
09:26 nerzhul it works as intended and simplify the code
09:26 nerzhul now i'm testing it on android
09:27 celeron55 and also it will search texture packs first which means the selected texture pack can modify the load screen
09:27 * VanessaE peeks in
09:27 nerzhul yeah, it permit to have unified code between loading texture and other textures, as it's not the case atm :) good
09:28 nerzhul strange adventure, i just wanted to fix an image on android and i fixed the loading screen to use the texture source :p
09:29 nerzhul okay now i need to upscale image
09:31 celeron55 you should be able to just multiply the values in img_size
09:31 nerzhul yeah
09:31 celeron55 or wherever they go
09:31 nerzhul or just fixed it for a decent android size ?
09:32 celeron55 just override imgW and imgH to fixed values? seems fine enough for now
09:32 nerzhul the current image was not corrected, i have same problem as before, i returned back to previous behaviour
09:33 kilbith this fix is utterly incorrect, I'll leave a comment
09:33 kilbith "fix"
09:33 celeron55 there are many issues and at least one is fixed already
09:34 celeron55 kilbith: what do you think is the correct fix to... i mean whatever is utterly incorrect?
09:34 nerzhul celeron55, yes, but not the visible part :p
09:35 kilbith celeron55: https://github.com/minetest/minetest/pull/5601/files#diff-3caa81f71bc3ee0838c9b7a1cfcfa6acR640
09:35 celeron55 getting the texture from tsrc didn't make it x^2-sized?
09:35 kilbith this is not scaling on a power of 2
09:35 nerzhul yeah i was fixing it, but it's a rangelim and image doesn't respect it
09:36 kilbith and besides, manually scaling the current images to 1024px is fucking ugly
09:36 celeron55 it's just the size it's rendered at
09:36 nerzhul when i hardcode height and width it doesn't work, the texture is upscales but the repeat bug remains
09:36 calculon joined #minetest-dev
09:37 kilbith try out this patch instead : https://github.com/minetest/minetest/issues/5403#issuecomment-288161942
09:37 celeron55 nerzhul: are you trying to scale it unproportionally?
09:37 nerzhul it's the case yes
09:38 nerzhul seems normal then
09:41 celeron55 trying kilbith's suggestion won't hurt i guess
09:41 nerzhul trying
09:42 kilbith you'll need to change the header to <GLES/glew.h>
09:42 kilbith I think
09:42 nerzhul this header doesn't exists
09:42 nerzhul this header doesn't exists
09:42 nerzhul oops sorry
09:43 celeron55 i don't get it though; why is gles1 tiling the texture in one direction but not the other?
09:44 kilbith celeron55: width is at 256px
09:44 nerzhul i will try directly without version checking first
09:46 nerzhul okay texture disappears
09:46 nerzhul it's not the fix
09:47 nerzhul oh !
09:47 nerzhul no my fault
09:47 nerzhul u32 imgW = get_POT_size(imgW)
09:47 nerzhul why compiler let me write this ?
09:47 nerzhul imgW doesn't exist :p
09:47 nerzhul create + function + affect
09:48 nerzhul sorry but with the POT texture is exactly same as before
09:48 nerzhul no change
09:48 celeron55 i guess the compiler is pretending it's first constructed and then assigned into
09:50 celeron55 gles1 is supposed to be able to render any texture in any position on the screen, it won't tile anything at that point; the tiling happens when an image loaded from the disk is converted to a texture, if the image isn't converted to 2^n first
09:50 celeron55 as far as what i would suppose
09:51 nerzhul strange my client crashew now after sayling loading textures, since the tsrc change
09:52 nerzhul how can i get backtrace...
09:52 celeron55 lol maybe we should revert all of it and do something else
09:52 nerzhul my first commit works well, not the best but it works
09:53 nerzhul oh an assertion failure
09:53 nerzhul 04-16 11:52:29.935 27126 27142 E Minetest: 2017-04-16 11:52:29: ERROR[Main]: jni/../jni/src/client/tile.cpp:319: virtual void TextureSource::rebuildImagesAndTextures(): An engine assumption 'img->getDimension().Height == npot2(img->getDime
09:53 nerzhul nsion().Height)' failed.
09:53 nerzhul .
09:54 nerzhul this change is good for PC but android doesn't like it :p
09:54 kilbith you don't need to change anything for the desktop
09:54 nerzhul i talked about the texture source usage to unify loading the progress bar
09:55 nerzhul assertion is in android code part
09:56 nerzhul okay i think it's the check to ensure our texture is good for android no ? :p
09:56 calculon joined #minetest-dev
09:57 celeron55 umm
09:57 celeron55 i think that code is wrong
09:57 celeron55 Align2Npot2 can return a non-2^x image if the system says that it supports 2^x images
09:58 celeron55 this means your system is saying it supports them, while not supporting them, and additionally MT is always broken if android says it supports them (???)
09:58 celeron55 lol wut
09:59 nerzhul if i use a properly scaled image no problem
09:59 celeron55 but the code can only fail if there are non-2^x images in the game
09:59 celeron55 as otherwise Align2Npot2 doesn't do anything
10:01 celeron55 wait, no
10:01 celeron55 or maybe yes
10:01 celeron55 TextureSource::rebuildImagesAndTextures() is called only in Client::afterContentReceived, and it does have all game textures at that point, so yes, what i said is true
10:03 celeron55 so the two sanity checks should be removed, they're wrong
10:03 celeron55 but additionally your android is telling Align2Npot2 it supports x^2 textures while it doesn't
10:03 celeron55 comment out the if (extensions.find("GL_OES_texture_npot")) line in tile.cpp and see what happens
10:04 nerzhul okay i will lunch and test that after
10:04 celeron55 this is ridiculous, i didn't expect both MT _and_ android to be so broken
10:06 celeron55 kilbith's check for GL version might work better for android, but not for desktop because on desktop opengl 1 usually supports non-x^2 textures just fine
10:07 kilbith seems to be not entirely true : https://www.khronos.org/opengl/wiki/NPOT_Texture
10:11 celeron55 it just lists some gl2 cards that are broken and says nothing about gl1
10:12 kilbith Core since version2.0
10:13 celeron55 afaik usually when you stumble upon gl1 or something like that, its a windows system without some sort of a gaming video card
10:20 celeron55 like https://i.ytimg.com/vi/iXEm41r1mFk/maxresdefault.jpg
10:21 celeron55 i'm pretty sure whatever that is running on can use npot without any issues whatsoever
10:24 kilbith I only see 16x16px textures on your screenshot
10:25 celeron55 a gpu is free to support any gl extensions and on desktop npot tends to be important so they support it even at gl1
10:25 celeron55 but won't show up as gl2 because they can't do the stuff gl2 requires mainly for fancy games
10:26 kilbith well, the Khronos group claims the opposite
10:27 celeron55 the only thing that page says is that it's mandatory for gl2 and some gl2 cards are broken
10:28 celeron55 khronos' recommendations mean nothing to me
11:17 nerzhul celeron55, the part you want me to comment fixes the problem
11:19 DS-minetest joined #minetest-dev
11:20 MoNTE48 joined #minetest-dev
11:22 celeron55 ok, hmm
11:23 celeron55 i mean, it doesn't show up as tiled then?
11:24 nerzhul no, it's the perfect texture, no repeat
11:25 nerzhul i'm writing an upscaling formula to make texture fit phone screens properly
11:25 celeron55 ok, then checking for the GL_OES_texture_npot opengl extension isn't sufficient as the system erroneously reports it
11:25 celeron55 maybe the detection logic in kilbith's patch is required
11:26 nerzhul you mean verify if GL 1 + extension ?
11:27 rubenwardy joined #minetest-dev
11:28 celeron55 i would try this: if ((gl version is 1) || (extensions.find("GL_OES_texture_npot") != std::string::npos))
11:29 celeron55 oops
11:29 celeron55 corrected: if ((gl version is > 1) || (extensions.find("GL_OES_texture_npot") != std::string::npos))
11:30 celeron55 wait
11:30 celeron55 i think my brain just stopped working
11:30 nerzhul :p
11:31 celeron55 i meant this: if ((gl version is > 1) && (extensions.find("GL_OES_texture_npot") != std::string::npos))
11:31 celeron55 which means the extension's existence is trusted only if opengl version isn't 1
11:34 MoNTE48 joined #minetest-dev
11:34 celeron55 it seems there probably should be a test done at startup that sees whether an npot texture will render correctly and if not, it'll enable that function accordingly
11:35 celeron55 as the opengl extensions can't be trusted
11:36 nerzhul i updated #5601 with texture source and scale (final screenshot only) i just don't pushed the commented part
11:36 ShadowBot https://github.com/minetest/minetest/issues/5601 -- Android progressbar fix by nerzhul
11:36 DI3HARD139 joined #minetest-dev
11:37 celeron55 the stretched pixels look ugly but... at least it isn't utterly broken now
11:37 nerzhul yes it's sky i had another texture :p
11:38 nerzhul okay i added the version check
11:38 nerzhul it works
11:39 nerzhul #5601 is now ready for a final review celeron55 , i'm waiting for you
11:40 ShadowBot https://github.com/minetest/minetest/issues/5601 -- Android progressbar fix by nerzhul
11:41 celeron55 you still need to comment the sanity_checks because they can still fail on gles2 hardware, because they're wrong
11:41 celeron55 i mean, remove
11:42 nerzhul are you sure ? they was triggered before on my hardware but since the fix it isn't ? (also it's triggered only in debug builds not release :) )
11:43 celeron55 it will literally always crash into them on androids that support npot textures, when there are npot textures, and now there always is, the progress bar
11:43 celeron55 yours doesn't so it doesn't crash
11:44 nerzhul okay removed, tell me when you're okay for a squash+merge
11:46 celeron55 adding a comment before "if (get_GL_major_version()" would be good; something like "// Only GLES2 is trusted to correctly report npot support"
11:49 nerzhul added
11:57 kilbith please ask sfan5 a review also
11:59 celeron55 we need better management for this npot stuff; it should be made easily checkable whether MT is in npot-avoidance mode or not
12:04 celeron55 nerzhul: do you notice how the progress bar is stretched after the x^2 conversion? it should probably be fixed by enforcing the known aspect ratio of the source image when drawing it
12:04 kilbith_ joined #minetest-dev
12:05 celeron55 instead of using whatever tsrc ended up returning as it may have to do those npot scalings
12:06 celeron55 instead of this:
12:06 celeron55 const core::dimension2d<u32> &img_size = progress_img_bg->getSize();
12:06 celeron55 do something like this:
12:06 celeron55 const core::dimension2d<u32> img_size(256, 48);
12:07 nerzhul i respect the ratio of the image
12:07 nerzhul https://github.com/minetest/minetest/pull/5601/files#diff-3caa81f71bc3ee0838c9b7a1cfcfa6acR640
12:07 celeron55 it might seem weird but it's how you're supposed to handle npot images in opengl rendering
12:08 celeron55 yes, the ratio becomes wrong after the required Align2Npot2 so you have the wrong ratio there
12:09 nerzhul progress_img_bg->getOriginalSize()
12:09 nerzhul then ?
12:09 troller joined #minetest-dev
12:09 celeron55 that probably doesn't work due to how TextureSource works
12:09 kilbith it has the same effect, I tried
12:10 nerzhul celeron55, oh, testing it fast to see
12:10 nerzhul no change
12:10 celeron55 it only works if irrlicht itself does the npot conversion and apparently it doesn't do them
12:10 nerzhul celeron55, but if i hardcode it it's wrong, if we change the image we should change the code
12:11 celeron55 images shouldn't define shapes of UI elements anyway
12:11 celeron55 the UI shape is defined by code in this case
12:12 nerzhul 64/256
12:12 nerzhul it's wrong yes :)
12:12 nerzhul then hardcode ?
12:13 celeron55 just hardcode, that's what opengl expects anyway
12:14 nerzhul hmmm not good, my texture is cut at 48 now
12:15 celeron55 oh, you need to supply the correct source size to draw2DImageFilterScaled
12:16 celeron55 this is kind of weird when we have no existing textured UI practices at all
12:21 celeron55 i'm looking into where irrlicht comes up with the size for getOriginalSize()
12:22 nerzhul okay everything is okay now :)
12:23 celeron55 looks like irrlicht internally does an npot conversion if Driver->queryFeature(EVDF_TEXTURE_NPOT)
12:23 nerzhul 1.8.4 ?
12:23 celeron55 i'm looking at 1.7.2 as i have it hanging around but probably nothing has changed
12:24 celeron55 COpenGLTexture::getImageValues in COpenGLTexture.cpp
12:24 celeron55 TextureSize=ImageSize.getOptimalSize(!Driver->queryFeature(EVDF_TEXTURE_NPOT));
12:25 celeron55 looks like it checks for the extension ARB_texture_non_power_of_two
12:26 celeron55 i guess your android device gets that wrong too
12:26 nerzhul maybe :)
12:26 celeron55 all this automation is nice but it's completely useless when the starting values are wrong
12:29 lisac joined #minetest-dev
12:31 celeron55 really if we weren't this nice we could as well just decide your android is broken and not support it
12:32 celeron55 because that's quite what it is
12:35 nerzhul my android is quite recent, it's Android 6.0 on a Huawei Honor 8 :p
12:35 nerzhul sfan5, okay for a merge now ? i addressed your comments :) celeron55 too
12:43 nerzhul merging, thanks celeron55 and kilbith for your support :)
12:44 celeron55 that's way too much work for a fix for a broken android phone though
12:49 XtremeHacker joined #minetest-dev
13:21 halt_ joined #minetest-dev
13:21 Grandolf joined #minetest-dev
13:28 octacian joined #minetest-dev
13:49 kilbith_ joined #minetest-dev
14:09 kilbith_ joined #minetest-dev
14:20 Megaf joined #minetest-dev
14:29 Fixer joined #minetest-dev
15:06 paramat joined #minetest-dev
15:08 kaeza joined #minetest-dev
15:08 paramat celeron55 "are people ok with adding a file called minetest.conf.example.extra and putting the extra mapgen parameter topic from minetest.conf.example into there?" fine for me. two sections: https://github.com/minetest/minetest/blob/master/minetest.conf.example#L1200 and https://github.com/minetest/minetest/blob/master/minetest.conf.example#L1284
15:10 paramat related issue: #4390
15:10 ShadowBot https://github.com/minetest/minetest/issues/4390 -- Settings / .conf: Mgv5 ground noise unsettable / missing. 2 problems with .conf auto-generation
15:28 halt_ joined #minetest-dev
15:38 DS-minetest joined #minetest-dev
15:45 cx384 joined #minetest-dev
16:17 xtremehacker_ joined #minetest-dev
16:50 halt_ joined #minetest-dev
16:50 Grandolf joined #minetest-dev
16:57 octacian joined #minetest-dev
17:38 kaeza joined #minetest-dev
17:49 juhdanad joined #minetest-dev
17:50 nore oh hey juhdanad
17:51 juhdanad Hey!
17:51 nore quick question: do you still intend to work on changing the lightbanks meaning?
17:51 juhdanad I'm not finished reading logs yet.
17:51 nore heh, I guess there are a lot of them
17:51 juhdanad Yes, I would like to add artificial light instead of day light.
17:52 nore good, that is something I would also like a lot :)
17:52 juhdanad But that will have a performance penalty: converting map blocks for older clients on the fly.
17:53 nore hmmm, that shouldn't be too expensive
17:53 nore it's the old->new conversion which is
17:54 nore also, there would be a performance gain when updating light
17:54 nore (especially in areas that are only artificial lit)
17:56 juhdanad nore: That will be easy to code once #5373 is merged. That contains a map block light fixing method already.
17:56 ShadowBot https://github.com/minetest/minetest/issues/5373 -- Add the possibility to skip light update and fix light later by juhdanad
17:56 juhdanad (at least I hope it will be easy then.)
17:58 * nore is reviewing the code
18:00 kaeza joined #minetest-dev
18:27 nore juhdanad: I'm trying your PR and minetest.fix_light is returning false, even though the block is generated (and even loaded, since I'm standing inside it)
18:28 juhdanad I'll look at it...
18:28 nore otherwise, code looks good :)
18:29 juhdanad Thank you for your efforts! I'm really happy that my code is appreciated!
18:30 nore you're welcome, this is something I wanted done for a very long time and I was always too lazy to code :)
18:32 juhdanad There's a mod for testing: https://gist.github.com/juhdanad/8d52aed02fcfd9d59c0364dc786d45c4
18:32 juhdanad You just type in "/fixlight" to correct light in the chunk you are standing in.
18:33 nore ah
18:33 nore so you've got to use minetest.fix_light with the block position?
18:34 * nore misread the api
18:34 juhdanad Well, you have to tell the program where to look for bugs. :)
18:35 nore I thought it was the node position :s
18:35 juhdanad Now, to create lighting bugs, use paramat's "chambers" mod, but add 'false' to all 'write_to_map()' calls.
18:35 nore ok, working as advertised
18:35 kaeza it should use node positions IMHO. I don't think block units are used anywhere else in the API
18:36 nore ^ I used another mod I'm working on :)
18:36 nore kaeza: that's a big question
18:37 juhdanad Since blocks are corrected instead of individual nodes, users need to know the definition of a map block in order to to use my function.
18:37 nore the problem is: if you don't know that, you have to call it for *each* node position you want to fix
18:37 nore and that's not good
18:37 nore so... both are ok for me
18:38 nore minetest.forceload_block also uses blocks and not nodes
18:38 nore (although the API is per-position)
18:39 kaeza juhdanad, I understand your point of view, but as you see in your own code, you need more boilerplate code (converting to block units) to use the feature. the average user/modder doesn't need to know what a mapblock is
18:39 nore kaeza: yes, but that's a feature only useful when using vmanips I think
18:39 nore but anyway, I guess converting would be easy enough
18:41 juhdanad kazea: so you are suggesting cuboid of map blocks as a parameter, right?
18:41 juhdanad *map nodes
18:41 juhdanad like minetest:fix_light(pos1, pos2)
18:42 kaeza juhdanad, that could be an option. doesn't VManip use that system?
18:43 kaeza i.e. you request an arbitrary cuboid, but in fact get whole blocks
18:44 nore ^ this would be fine with me, it is like vmanip works as well
18:45 juhdanad yes, it is.
18:46 kaeza well, VManip code also needs the VoxelArea helper class to do anything meaningful, so...
18:47 nore kaeza: yes, but VoxelArea doesn't care about mapblocks
18:52 YuGiOhJCJ joined #minetest-dev
18:58 celeron55 the lua API shouldn't deal with block positions
18:59 celeron55 there are some misdesigned parts that shouldn't be there that use block positions but they shouldn't be there
19:00 juhdanad so the Minetest world has to be continuous.
19:02 celeron55 the api (and most of the internals) is designed to abstract away mapblocks and that's for very good reasons
19:03 celeron55 it's very annoying to try to do continuous things with a non-continuous api
19:04 nore #5598 updated to fix the remaining problem
19:04 ShadowBot https://github.com/minetest/minetest/issues/5598 -- Add configurable key bindings for selecting next/previous hotbar item and changing the volume by Ekdohibs
19:04 nore and #5597 should be reviewed as well
19:04 ShadowBot https://github.com/minetest/minetest/issues/5597 -- getTime refactoring by Ekdohibs
19:11 juhdanad Does anyone know if there are client side object references already?
19:12 nore juhdanad: you mean references to entities in the client lua api ?
19:12 juhdanad Yes!
19:12 nore I don't think so yet
19:13 juhdanad Well, I'm looking forward to them, they are required for pointed things.
19:13 nore ah, indeed
19:14 celeron55 commented 5597 and edited the comment a few times
19:14 celeron55 it doesn't seem like good quality code
19:16 nore ah, saw the edits
19:16 nore I guess now the code is rebased that ShadowNinja can get a look at it indeed
19:17 celeron55 i don't think the code even knows what it's trying to achieve at this poin
19:17 celeron55 +t
19:17 celeron55 somebody has to define that first
19:34 kaeza joined #minetest-dev
19:51 rubenwardy joined #minetest-dev
20:02 kilbith joined #minetest-dev
20:12 kilbith_ joined #minetest-dev
20:20 nerzhul juhdanad, no entity objects in client yet
20:20 nerzhul csm*
20:20 juhdanad Okay, thank you.
20:20 juhdanad I suppose they will be read-only.
20:22 nerzhul exact, it's a server object shown on client
20:22 nerzhul but we can permit some things like adding texts over it for example
20:23 juhdanad So graphics can be modified.
20:28 sofar please don't move the sign problem to entities on the client
20:29 * VanessaE looks forward to "the sign problem" being fixed enough to make signs_lib little more than a shell :)
20:29 Tmanyo joined #minetest-dev
20:32 nerzhul sofar, please review my player to db PR
20:32 rdococ sign problem?
20:32 sofar eating lunch, then afk again
20:33 nerzhul okay :)
20:36 juhdanad rdococ: #1367
20:36 ShadowBot https://github.com/minetest/minetest/issues/1367 -- Proper display of text on the surface of a node(box)
20:37 rdococ ah
20:37 rdococ k
20:43 octacian_ joined #minetest-dev
20:44 octacian joined #minetest-dev
20:44 octacian joined #minetest-dev
20:51 juhdanad #5186 is rebased.
20:51 ShadowBot https://github.com/minetest/minetest/issues/5186 -- Soft node overlay by juhdanad
20:56 VanessaE juhdanad: I was wondering..  have you done any benchmark of the overlays versus normal nodes with equivalent, baked-in textures?
20:57 VanessaE (since you mention being concerned about the extra geometry)
20:57 juhdanad VanessaE: no, I have not.
20:57 VanessaE ok.  just curious.
20:57 juhdanad I just tested it in-game.
20:57 VanessaE (still looking forward to it going in :) )
20:58 juhdanad I don't know how to properly measure memory usage.
20:59 VanessaE no worries.  it probably doesn't add up to much, especially compared to the hacky method I use in e.g. blox and unifiedbricks.
21:00 juhdanad In fact the only benefit of my approach is that only the surface is drawn. You can achieve the same effect with meshes.
21:01 juhdanad (but indeed it makes a difference, because the surface is usually much smaller than the whole structure's volume)
21:01 VanessaE that's what I do now, but your proper method has the advantage of hidden face removal
21:02 VanessaE using meshes to simulate the effect means more than twice the number of visible faces
21:04 VanessaE (because with the meshes, there are 12 faces, and engine can't strip away the hidden ones that are against some other node)
21:04 VanessaE +the
21:04 juhdanad That's true.
21:08 TC02 joined #minetest-dev
21:26 kilbith joined #minetest-dev
21:40 kilbith joined #minetest-dev
21:56 kaeza joined #minetest-dev
22:07 Taoki joined #minetest-dev
23:10 * benrob0329 mumbles about render-to-texture being handy for portals and fake mirrors
23:10 rdococ adding render-to-texture might be nice
23:10 juhdanad From Lua?
23:11 rdococ yes
23:11 benrob0329 Irrlicht supports it, but minetest doe not
23:11 rdococ it would be nice
23:11 rdococ I mean, sure, it might lag the game
23:12 rdococ but not that much
23:12 proller joined #minetest-dev
23:12 juhdanad But then Lua modders should use OpenGl functions, matrices, vertices and so on...
23:12 rdococ I, myself, wouldn't mind matrices
23:12 rdococ some lua modders might not know what they are
23:13 benrob0329 perhaps a sort of minetest.register_camera("name" {pos, fov, facedir})
23:13 rdococ yes
23:13 rdococ facedir should be yaw and pitch
23:13 rdococ hm
23:13 juhdanad So if you have a camera, the world is rendered twice?
23:13 benrob0329 tiles = { minetest.get_camera_by_name("name") }
23:13 benrob0329 yes
23:13 rdococ how about a camera entitySAO?
23:14 benrob0329 so they need to be used sparringly
23:14 juhdanad That halves FPS.
23:14 rdococ Not if the resolution is lower
23:14 juhdanad And the camera must not look at the tile you are currently rendering.
23:15 rdococ if that happens, just assume a white or black texture
23:15 rdococ portal does it
23:16 rdococ I don't see why someone can't try. ofc there are more important things but it would be nice.
23:16 rdococ you would have a texture modifier for getting a camera
23:16 rdococ and parameters like horizontal flip, or vertical flip
23:17 rdococ and whether that flip is relative to the player camera or not
23:17 rdococ tho that would only take effect when player cameras have roll
23:17 rdococ actually, you could just use [transform for that. but it wouldn't be relative to the player camera
23:22 rdococ so will anyone consider it?
23:26 VanessaE rdococ: I guess that is a 'no'.  :P
23:26 rdococ :c
23:26 * rdococ is now sad
23:27 benrob0329 :-(
23:32 VanessaE as for the camera views thing
23:32 proller joined #minetest-dev
23:32 VanessaE if you have some node that would have a camera view on its surface, you wouldn'
23:32 VanessaE ...
23:32 rdococ ?
23:33 VanessaE ...wouldn't lose fps if the view were forced, by the engine, to only include that which you could ordinarily see if there were a hole in the wall there
23:33 rdococ ah. that's true
23:33 benrob0329 yes, but that'd need more complex code
23:33 VanessaE that is, if the thing being displayed on the surface were simply more world on the otherside of the wall
23:34 benrob0329 it would be, but possibly in another location
23:34 VanessaE the same would theoretically be true of any such feature, really
23:34 rdococ anyway, if not on nodes then at least on entities
23:35 VanessaE nothing says, for example, that you couldn't restrict the view range of the "projected" area to some really low value
23:35 VanessaE (say 20m)
23:35 benrob0329 having both a "worldportal" and camera would be nice, camera for camera things, worldportal for portals and illutions
23:36 VanessaE mirrors too, but yeat
23:36 VanessaE yeah*
23:36 benrob0329 for eg, a worldportal could just stich two areas together
23:37 benrob0329 whereas a camera would render two views
23:37 rdococ if you don't want the code to be too complicated you could restrict the worldportal to grid coordinates and to the cardinal directions
23:37 benrob0329 that would work
23:38 benrob0329 however, you'd have to figure out how to make worldportals not render over the portal "frame"
23:39 rdococ perhaps
23:39 rdococ it depends on how you go about it
23:40 VanessaE now, I could see a render-to-texture-once feature being useful
23:40 rdococ most implementations of worldportals use cameras anyway
23:40 VanessaE like if you wrote a teleporter mod and you wanted a menu (as in Sokomine's travelnets), but with previews of the target areas
23:41 benrob0329 or a wormhole mod
23:41 benrob0329 tardis
23:41 benrob0329 etc
23:41 VanessaE or even have it just go to one location, and have a preview of the area generated once in a while as the back-inside of the booth
23:42 rdococ possibly
23:42 VanessaE so, don't bother to render it in realtime
23:42 benrob0329 perhaps at 1 fps or something
23:42 VanessaE once a second would be more than enough
23:42 rdococ I still think a realtime option should be offered
23:42 VanessaE yesd
23:42 benrob0329 or have that be configurable
23:43 benrob0329 however, view tracking would be hard
23:43 rdococ yeah
23:43 rdococ so that when you look from a steep angle, you see the steep side of the other side of the portal
23:43 benrob0329 that is where a worldportal-stick the meshgen together thing would be useful
23:43 VanessaE so don't make it track the view then
23:44 rdococ but that would look kinda ugly
23:44 rdococ sure, it's better than nothing but it would be worse than a realtime implementation
23:44 benrob0329 you could do that, but it would ruin the illution
23:44 VanessaE now someone just has to code it.
23:45 xerox123 joined #minetest-dev
23:45 rdococ I would rather someone code it realtime
23:45 benrob0329 i think having an fps option would be good
23:46 VanessaE something like that should be settable from Lua, from the mod
23:46 rdococ yes
23:46 VanessaE but with the client able to limit the fps
23:46 rdococ and view tracking
23:46 VanessaE so the mod could ask for a realtime view of something, but the client could limit it to, oh, say 5 fps if the user wanted to
23:46 benrob0329 rendered at the current fps if set too high (or nil)
23:47 benrob0329 but also a worldportal option for things that would need camera tracking
23:51 * rdococ waits for someone to care
23:51 rdococ s/someone/a coder/
23:51 VanessaE they're waiting for you to code it.
23:52 rdococ wait
23:52 rdococ they're waiting for _me_ to code it? I'm experienced with lua modding but not in the C++ core
23:52 rdococ unless I can somehow do it in a mod
23:53 VanessaE theoretically you could
23:53 VanessaE but it would be horrendously slow and hacky
23:53 rdococ exactly
23:53 benrob0329 here, just use the Tardis' telepathic circuits
23:53 benrob0329 :P
23:53 VanessaE ok guys getting offtopic here now
23:53 rdococ that aws just benrob0329
23:53 rdococ wa*
23:53 rdococ was*

| Channels | #minetest-dev index | Today | | Google Search | Plaintext