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: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
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: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 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: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 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 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       ^^
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
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
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: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/