| 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* |
