| Time |
Nick |
Message |
| 01:02 |
MTDiscord |
<Warr1024> I'm fairly sure that -0.5, -0.5, -0.5 to 15.5, 15.5, 15.5 is one mapblock, and I think that from -0.5, -0.5, -0.5 to 79.5, 79.5, 79.5 is one mapchunk. |
| 01:03 |
MTDiscord |
<Warr1024> If your chunksize != 5 then I have no idea how well the math holds up. Presumably anything that depends on knowing where chunk boundaries are will break because 99% of it has probably only ever been tested with ==5. |
| 02:09 |
|
jwmhjwmh joined #minetest-dev |
| 02:11 |
jwmhjwmh |
I think only chunks entirely within the mapgen_limit are generated, but chunks are offset by some blocks. I opened an issue #12057 about this. |
| 02:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/12057 -- Method of finding "actual" mapgen limit |
| 02:51 |
MTDiscord |
<Warr1024> I'd love for MT to have an actual API for that |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:03 |
|
MTDiscord joined #minetest-dev |
| 06:12 |
|
calcul0n joined #minetest-dev |
| 06:27 |
|
tuxedoedpenguin[ left #minetest-dev |
| 06:58 |
|
Baytuch joined #minetest-dev |
| 09:44 |
|
HuguesRoss joined #minetest-dev |
| 09:51 |
paradust |
It appears Irrlicht's internal color format (SColor) is ARGB, and minetest intentionally loads all images as ARGB as well... |
| 09:52 |
paradust |
But while OpenGL/GLES/GLES2 all support RGBA, and ARGB causes issues |
| 09:52 |
paradust |
OpenGL conditionally supports ARGB, otherwise it needs to be converted (this happens in the driver at the last minute) |
| 09:53 |
paradust |
GLES1 doesn't support it at all, so it needs to convert |
| 09:53 |
paradust |
GLES2 doesn't support it, but it can be fixed with a swizzle in the shaders |
| 09:54 |
paradust |
So my dumb question, why not just switch everything to RGBA? |
| 10:05 |
paradust |
also, it looks like the swizzle in the shaders would break most other texture formats, forcing ARGB for everything |
| 10:05 |
paradust |
(unless I missed something) |
| 10:17 |
|
basicer joined #minetest-dev |
| 10:45 |
sfan5 |
we simply haven't had the opportunity to make changes that deep until recently (Irrlicht fork) so nobody will have considered it |
| 10:50 |
erle |
paradust so you are proposing to adjust the texture conversion functions, right? |
| 10:50 |
erle |
paradust does that speed up rendering? |
| 10:50 |
paradust |
i see. maybe i'll give it and try and see if anything breaks :D |
| 10:52 |
paradust |
probably no effect on a modern OpenGL which natively supports ARGB anyway. But it may speed up texture loading on OGLES1&2 a little bit |
| 10:54 |
sfan5 |
ogles2 doesn't convert though |
| 10:54 |
sfan5 |
or shouldn't if it uses the shader workaround you mentioned |
| 10:55 |
paradust |
oh true |
| 10:55 |
paradust |
there is an extra memcpy though due to existing code that wasn't quite cleaned up |
| 10:59 |
paradust |
https://github.com/minetest/irrlicht/pull/106 |
| 11:00 |
erle |
paradust which openGL extensions are relevant here? |
| 11:02 |
erle |
i have GL_OES_rgb8_rgba8 am i safe? :D |
| 11:03 |
paradust |
erle: https://github.com/minetest/irrlicht/blob/master/source/Irrlicht/COpenGLDriver.cpp#L367 |
| 11:04 |
erle |
paradust i have GL_EXT_abgr, GL_EXT_bgra lol |
| 11:12 |
paradust |
i think that's slightly different, although related |
| 11:14 |
paradust |
this is for colors part of the vertex (mesh) data, which I think is generally only used for custom (programmatically generated) meshes |
| 11:14 |
erle |
paradust so what exactly are the gains of choosing a different byte order? like, benchmarking it, what order of magnitude? |
| 11:14 |
paradust |
but even when its not used the conversion still takes place |
| 11:15 |
erle |
i mean dumb code isn't worth too much of a big refactor if it does not cause any pain (i.e. it is just dumb) |
| 11:15 |
paradust |
honestly the only benefit might be cleaner code. only OGES1 will have a significant improvement, and who uses that? |
| 11:16 |
erle |
people on whose hardware the OGLES1 renderer is faster than OGLES2 |
| 11:16 |
paradust |
is that really a thing? |
| 11:16 |
erle |
(there is a hilarious conversation in the issue tracker where hecks claims devices like that are extinct in the wild to a person who has such a device) |
| 11:17 |
paradust |
might indicate a problem with the OGLES2 driver, I would not expect it to perform worse |
| 11:17 |
erle |
apparently? i don't know, i only have once devices with better OGLES2 rendering performance than OGL performance and a bunch of devices where OGLES2 is worse than desktop OGL |
| 11:17 |
erle |
“once devices” → “one device” |
| 11:17 |
sfan5 |
if we can get a new renderer written support for ogl1 or ogles1 will go |
| 11:17 |
sfan5 |
so it's not worth investing time in that |
| 11:17 |
paradust |
unless that device is emulating some features of ogles2 in a bad way |
| 11:20 |
erle |
if |
| 11:20 |
paradust |
new renderer? |
| 11:23 |
erle |
paradust AFAIK one of the motivations behind the irrlichtmt thing is to remove all rendering options except OGLES2 to a) simplify the code b) end support for older harwdare. |
| 11:23 |
sfan5 |
hecks wanted to write a new shader-based renderer on the feature set OpenGL ES 2 provides (so would run on OpenGL too) but then he disappeared |
| 11:23 |
erle |
oh i misrepresented it apparently |
| 11:23 |
sfan5 |
you can probably find some thoughts scattered around some issues |
| 11:23 |
erle |
i thought hecks meant “use OGLES2”, but “use the common features of OGLES2 and OGL” is something else obv |
| 11:24 |
erle |
you can have shaders in old OGL after all |
| 11:24 |
erle |
sfan5 has anyone tried to investigate what happened to hecks? do you think it would be appropriate to try? |
| 11:24 |
erle |
it makes me feel uneasy when people just … vanish |
| 11:25 |
sfan5 |
idk |
| 11:25 |
MTDiscord |
<exe_virus> hecks is sporadically around, not worried. Definitely not expecting anything to come of their rewrite though |
| 11:26 |
MTDiscord |
<exe_virus> The biggest thing I think front end they were working on was the formspec+hud replacement/combination |
| 11:26 |
sfan5 |
around where? |
| 11:26 |
MTDiscord |
<exe_virus> Git history |
| 11:27 |
erle |
like, you mean on github? |
| 11:27 |
MTDiscord |
<exe_virus> Yeah iirc |
| 11:28 |
erle |
it makes me feel a bit better about it, if someone just loses motivation. but they could still have issues or need help. |
| 11:28 |
erle |
(i stop coding for weeks when i am overwhelmed with other stuff) |
| 11:28 |
erle |
well |
| 11:29 |
paradust |
is there a relevant issue/PR? |
| 11:33 |
sfan5 |
#11396 looks relevant e.g. |
| 11:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/11396 -- Shader and material system by hecktest |
| 11:34 |
paradust |
thanks |
| 11:36 |
Zughy[m] |
celeron55: rubenwardy: sfan5: $2500 fund for free software, please try to apply https://appwrite.io/oss-fund-announcement |
| 11:37 |
rubenwardy |
We don't really have anything to use it on |
| 11:38 |
rubenwardy |
The next thing would be a paid dev, you'd need a fair amount for that |
| 11:38 |
Zughy[m] |
can't you pay them part time for two months? |
| 11:38 |
erle |
i doubt you get very far with that kind of money without a project plan |
| 11:38 |
erle |
like what would it be used for |
| 11:39 |
erle |
is google summer of code still a thing? if so, might be worthwhile. (and easier to get than full grants) |
| 11:40 |
rubenwardy |
GSoC is students and requires a lot of mentoring |
| 11:40 |
Zughy[m] |
imagine having someone gifting $2500 away and people saying "but that's not too much" |
| 11:40 |
Zughy[m] |
like.. excuse me? |
| 11:41 |
rubenwardy |
We're in the sweet spot where we have enough to cover expenses but not enough to make more use of it |
| 11:42 |
erle |
Zughy[m] do you work as a freelance dev? if so, exactly how much would you promise a customer for 2.5k monies without a strict project plan? |
| 11:42 |
MTDiscord |
<Warr1024> Could use it to encourage people to make content, run contests, or bug bounties or something. |
| 11:42 |
|
basicer` joined #minetest-dev |
| 11:42 |
erle |
that would be nice, but i somehow doubt grants are easily given out for such stuff |
| 11:43 |
erle |
“fund our next game jam” ;) |
| 11:43 |
MTDiscord |
<Warr1024> If we need a plan for how to use the money in advance then to seems unlikely we would be awarded it. |
| 11:50 |
rubenwardy |
If we were to hire someone, someone for the graphics pipeline or Android would make sense to me |
| 11:50 |
erle |
rubenwardy has the android crash situation improved meanwhile? |
| 11:51 |
rubenwardy |
No |
| 11:52 |
paradust |
erle: issue for this? |
| 11:52 |
rubenwardy |
Needs someone to investigate how to get unobfuscated crash tracebacks from users |
| 11:52 |
erle |
paradust i don't know, rubenwardy knows much more about android crashes than me and has access to some stats about it i think. |
| 11:52 |
paradust |
no reproducer? |
| 11:52 |
rubenwardy |
#12062 |
| 11:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/12062 -- Frequent crashes on Android, no error log in debug.txt |
| 11:53 |
erle |
i just know it was ridiculously common with no clear cause |
| 11:53 |
rubenwardy |
> The 5.5.0 release was cancelled for Android because of a huge uptick in crashes. We don't have a good way of getting crash information currently, so it's super hard to debug |
| 11:53 |
rubenwardy |
The error rate increased by 35x |
| 11:53 |
erle |
that's definitely the kind of problem that makes sense to throw money at |
| 11:53 |
erle |
that → where it |
| 11:54 |
rubenwardy |
For previous releases, I was able to take the obfuscated stack trace from play store and use a SDK tool to get actual info using the debug symbols locally |
| 11:54 |
rubenwardy |
But that didn't work for that release |
| 11:55 |
rubenwardy |
The Android SDK also documents a way to upload symbols to the play store but our build system doesn't generate this even when you enable the option |
| 11:55 |
rubenwardy |
And I wasn't able to generate it manually |
| 11:55 |
erle |
paradust, if you are an expert on texture formats, could you maybe take a look at this? https://github.com/minetest/minetest/issues/12306 |
| 11:55 |
celeron55 |
it's ok to me if someone (a trusted person) wants to grab that fund and hire an android developer to deal with the crashes |
| 11:55 |
paradust |
i'll look at all of these tomorrow, about to go sleep |
| 11:56 |
erle |
paradust, what time zone are you in? |
| 11:56 |
sfan5 |
well targa isn't really that important |
| 11:56 |
sfan5 |
it was almost removed, too |
| 11:56 |
erle |
not this again |
| 11:56 |
paradust |
erle: i'm in california, but on hawaii time |
| 11:57 |
erle |
sfan5, there is only one way this could be a TGA decoder problem and multiple ways this could be a “convert textures between different formats” problem (i.e. a general one). |
| 11:57 |
celeron55 |
(however i do think just any android developer probably isn't set for debuggin something like this; i think it needs someone with android C++ experience, some sort of game engine person or something) |
| 11:58 |
celeron55 |
+g |
| 11:58 |
sfan5 |
erle: tga is the only image loader that deals with anything other than RGB(A), so regardless of where the issue is it will only affect TGA |
| 11:58 |
erle |
sfan5 the thing is, if paradust changes the texture format CColorConverter.cpp is to be used anyway |
| 11:59 |
erle |
so i was aiming for more of a drive-by effort ;) |
| 11:59 |
sfan5 |
more of a detour than a drive-by but ok |
| 12:00 |
erle |
weird, i thought all image loaders spit out RGBA at the end |
| 12:00 |
erle |
oh i see |
| 12:00 |
erle |
there is a different special-cased function for PNG since it is possibly way more complex |
| 12:01 |
sfan5 |
wat |
| 12:01 |
erle |
also there is code that is interested in handling the gAMA chunk wtf https://github.com/minetest/irrlicht/blob/372b3642bf524da2694cc09bdc8bdacb23f5fd0e/source/Irrlicht/CImageLoaderPNG.cpp#LC191 |
| 12:02 |
sfan5 |
celeron55: there's some easy things like running the whole app in a debugger than can still be tried but someone needs to be motivated to do it |
| 12:02 |
|
proller joined #minetest-dev |
| 12:03 |
erle |
i thought, gamma was just ignored and that caused the rendering failures. turns out, it's probably just faulty. maybe loss of precision? |
| 12:04 |
MTDiscord |
<luatic> are you sure that it isn't ignored at a later stage? |
| 12:05 |
MTDiscord |
<luatic> NVM |
| 12:05 |
erle |
well if the intention is to have no gamma correction support here, the decoder should bug out at this point or not do anything |
| 12:05 |
erle |
but it is doing something |
| 12:06 |
MTDiscord |
<luatic> but I don't think that there are precision issues, it uses a double |
| 12:06 |
MTDiscord |
<luatic> and a float would probably suffice |
| 12:06 |
erle |
yeah i seriously wonder what it does here |
| 12:07 |
erle |
i *think* this is the naive conversation of values to the screen gamma |
| 12:07 |
erle |
the one that works if you have no blending operations applied to the texture |
| 12:07 |
|
Taoki joined #minetest-dev |
| 12:07 |
erle |
but then i wonder why the gamma test nodes look wrong |
| 12:10 |
sfan5 |
you don't have to guess, read the libpng documentation? |
| 12:11 |
MTDiscord |
<luatic> I have |
| 12:11 |
MTDiscord |
<luatic> But it seems to be used correctly |
| 12:11 |
erle |
http://www.libpng.org/pub/png/libpng-manual.txt |
| 12:11 |
erle |
for reference |
| 12:13 |
erle |
i think if the usage is correct, the gamma test nodes basically show what the degree of visual degradation to expect because of lack of precision. |
| 12:13 |
erle |
(which seems useful information) |
| 12:14 |
|
proller joined #minetest-dev |
| 12:14 |
MTDiscord |
<luatic> > From libpng-1.5.4 this information can be set before reading the PNG file > header. In earlier versions png_set_gamma() existed but behaved incorrectly if > called before the PNG file header had been read and png_set_alpha_mode() did not > exist. |
| 12:14 |
MTDiscord |
<luatic> erle: what is your libpng version? |
| 12:16 |
MTDiscord |
<luatic> It seems Irrlicht does indeed set the gamma before reading the header |
| 12:16 |
sfan5 |
you know that 1.5.4 is more than 10 years old right? |
| 12:16 |
rubenwardy |
Could be using debian |
| 12:17 |
rubenwardy |
(/s) |
| 12:17 |
erle |
sadly minetest --version does not show me the libpng version lol |
| 12:19 |
erle |
anyway, i conclude that no one, including me, has actually done a deep dive into this corner of the texture handling recently (before today) |
| 12:19 |
erle |
^^ |
| 12:49 |
|
Fixer joined #minetest-dev |
| 13:09 |
|
behalebabo joined #minetest-dev |
| 13:55 |
|
erle joined #minetest-dev |
| 14:43 |
rubenwardy |
Found another bug caused by game name vs game id |
| 14:45 |
rubenwardy |
oh neverment |
| 14:48 |
rubenwardy |
#12030 |
| 14:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/12030 -- Deprecate game.conf name, use title instead by rubenwardy |
| 14:53 |
|
proller joined #minetest-dev |
| 15:12 |
rubenwardy |
also #12284 and #12185 |
| 15:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/12284 -- [No Squash] Show dep errors in Select Mods modal by rubenwardy |
| 15:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/12185 -- Add register dialog to separate login/register by rubenwardy |
| 15:23 |
|
proller joined #minetest-dev |
| 15:34 |
|
fluxionary joined #minetest-dev |
| 18:50 |
sfan5 |
https://github.com/minetest/minetest/issues/12312#issuecomment-1123439668 thoughts? |
| 18:52 |
Krock |
yes, all at once is a good idea |
| 19:05 |
erle |
making linear searches contast time sounds like it could be useful for irrlicht. or would it not be, because it breaks compat? |
| 19:05 |
erle |
constant time |
| 19:59 |
MTDiscord |
<luatic> Hmm, it seems Irrlicht uses a list to manage a set here, which is a bad idea in the first place. How is it ensured that ParentPos is kept up to date though? |
| 20:00 |
MTDiscord |
<luatic> erle: Can you confirm my suspicions or am I missing something? https://github.com/minetest/irrlicht/pull/105/files#r870698221 |
| 20:01 |
erle |
luatic i can not, ask CuteAlien of irrlicht |
| 20:01 |
erle |
i am simply too bad at C++ |
| 20:01 |
MTDiscord |
<luatic> erle: It's about the algorithm |
| 20:01 |
|
appguru joined #minetest-dev |
| 20:02 |
appguru |
paradust: are you available? |
| 20:04 |
erle |
luatic the problem is that a) your question seems to make sense on its face b) i im not competent enough to answer it c) i am distracted by other things rn. i realize that you are asking about the algorithmic complexity, but there might be all kinds of optimizations that render arguments regarding that invalid. |
| 20:04 |
appguru |
hmmm alright |
| 20:05 |
appguru |
It's not all about algorithmic complexity though, it's also about correctness |
| 20:05 |
sfan5 |
"potentially shifted children" ???? |
| 20:05 |
sfan5 |
it's a linked list |
| 20:06 |
appguru |
see, that was exactly what I was trying to avoid |
| 20:06 |
sfan5 |
and the erase() documentation you linked says that iterators keep their validity |
| 20:06 |
appguru |
paradust: nevermind |
| 20:07 |
appguru |
sorry, somehow I assumed that std::list was an ArrayList based on the docs mentioning linear complexity (I now realize it's probably due to one of the signatures allowing searching by element) |
| 20:09 |
sfan5 |
not that I have seen a lot but I've only ever seen array "lists" in java |
| 20:09 |
sfan5 |
the C++ equivalent is just a std::vector and std::list is a real list |
| 20:09 |
appguru |
ahh I see |
| 20:10 |
appguru |
I was vaguely aware of vectors, but completely oblivious to the fact that apparently linked lists are often called just lists |
| 20:11 |
appguru |
TBF this isn't even a C++ thing, but the other langs that do it (Haskell) are rather uncommon |
| 20:13 |
sfan5 |
https://en.cppreference.com/w/cpp/container <- very detailed page |
| 20:21 |
appguru |
thanks |
| 20:22 |
sfan5 |
https://en.cppreference.com/w/cpp/thread/async hey this is just like minetest.handle_async() |
| 20:22 |
sfan5 |
didn't know this exists |
| 20:23 |
erle |
are you saying a refactoring is in order? |
| 20:24 |
erle |
or is this just a design that's so good that it is independently invented again and again? |
| 20:25 |
sfan5 |
neither really |
| 20:27 |
appguru |
erle: https://xkcd.com/2592/ |
| 20:37 |
|
proller joined #minetest-dev |
| 21:48 |
|
Alias joined #minetest-dev |
| 21:56 |
|
erle joined #minetest-dev |
| 22:35 |
|
panwolfram joined #minetest-dev |
| 23:05 |
|
AliasAlreadyTake joined #minetest-dev |
