Time Nick Message 10:52 [MatrxMT] Hello people, 10:52 [MatrxMT] Do we want a more game-agnostic main menu (https://github.com/minetest/minetest/issues/6733#issuecomment-2480817302) or something more artistic but speficic (two messages afterwards)? 11:13 Krock Looks cool, but I do prefer tab-styled approaches to quickly jump around. 11:13 Krock tacotexmex' mockup is decent. 11:15 Krock I like the logo design of yours. 12:56 [MatrxMT] Krock: if anyone wants to propose it as official logotype, be my guest. CC BY-SA 4.0 Zughy (Sumi released the 3D one under CC0) 13:01 MTDiscord Having a game-agnostic menu seems like a better idea from both an engine and platform standpoint, and helps encourage implementing game-provided menus 13:02 sfan5 @luatic what would you do about the plenty of code inside irrlicht that uses non-argb8 images? 13:08 [MatrxMT] greenxenith: I'm starting leaning towards the illustration, not gonna lie. But please check Matrix if you wanna discuss more about it 13:48 MTDiscord sfan5: I'll see what I can do about that, maybe I'm underestimating the extent 13:49 MTDiscord but if it's just as a temporary thing during reading, we should be able to use plain arrays for that 13:49 sfan5 yeah that's the main thing I'm thinking about 14:10 sfan5 I wonder how hard it would be to make irrlicht's scene graph sort stuff by material before rendering 14:11 sfan5 (it would be good for entities) 14:20 sfan5 because I fear applying the ClientMap approach to entities would also force shadow mapping to be handled manually 15:40 MTDiscord speaking of bucketing, currently particles are married to particle buffers via mutable refs essentially, i think it would be cleaner to just collect them into particle buffers on render 15:48 sfan5 sure, but keeping the buffer ready at all times is more efficient 16:00 MTDiscord sfan5: i doubt that 16:00 MTDiscord asymptotically there isn't really a difference, both ought to be linear time 16:01 MTDiscord so it comes down to the constant factors and it really isn't obvious why "keeping the buffer ready" would be better 16:02 MTDiscord we essentially need to mutate and reupload the entire buffer anyways 16:02 MTDiscord with the mutref approach each particle needs to keep a buffer ptr and index, and updates could in principle be bad for cache locality (though in practice most of them will be contiguous, i think) 16:02 MTDiscord also ParticleBuffer::release needs to manage a free list 16:03 MTDiscord either way if i was to refactor it, i would of course benchmark it to make sure i'm not worsening anything. 16:04 sfan5 in theory particles can stay unmodified in the buffer if nothing has changed 16:05 MTDiscord i don't think we have code to do a sparse buffer update and i don't think we'll need such code 16:06 MTDiscord i also believe that most particles will not be static but i have no statistic on this 16:06 MTDiscord and even with static particles they will disappear so you need to update buffers 16:07 sfan5 I'm not talking about the GL side, just "the buffer is already there and you need to update it a bit" vs. "collecting everything anew every frame" 16:07 sfan5 I may be wrong but this should scale better for high particle counts 16:08 sfan5 in practice we rewrite all vertices every frame, even if the particle is static and the camera angle wasn't changed 16:09 sfan5 the "make particle" face the camera thing could be moved into a shader 16:09 sfan5 or even a geometry shader for generating the vertices 16:09 sfan5 but that then reduces the amount of stuff we can batch 16:10 sfan5 either way particle rendering is very much good enough and spending time thinking about it is wasted 16:12 MTDiscord sfan5: agreed about the make it face the camera thing, it's a shame we're doing that math on the CPU just for the GPU to undo it 16:13 [MatrxMT] might interest devs https://mastodon.social/@Nezchan@wandering.shop/113482717909576966 16:14 rubenwardy I think that's a third-party distro maintainer breaking things 16:14 rubenwardy we haven't changed our storage names yet 16:14 sfan5 they're using flatpak 16:16 MTDiscord I'm not sure what's going on there. As far as I'm aware we did not touch where Luanti reads things from at all, precisely because of such concerns. 16:16 MTDiscord I tested the Flatpak myself and it did preserve my data (a game installation and world) just fine. 16:37 MTDiscord anyways btw sfan: the particle thing i consider more of a code quality than a performance thing, at least atm. 17:57 SFENCE I am trying to compile Luanti on platform without opengl, so I enabled gles2 and sdl. I see errors as GLint, GLenum etc is not defined. But I do not see where we include GLES headers. How this works? (SDL is builded without opengl and with gles). 17:59 sfan5 we include or a vendored copy of gl.h 17:59 SFENCE thx 18:16 sfan5 just tested and the -DENABLE_OPENGL=0 -DENABLE_OPENGL3=0 -DENABLE_GLES2=1 combo does work 18:17 [MatrxMT] lol 18:19 sfan5 I forgot -DENABLE_GLES2=1 and it turns out it's also possible to not include any video driver at all 18:19 sfan5 +at first 18:22 sfan5 @luatic actually a big usecase for static particles could be simulating fog and such 18:32 Krock hmm. Having no video driver could allow us to perform simple client unittests 18:33 Krock although that's already done right now - the buildbot compiles with OpenGL (ES) already. 18:34 sfan5 that would be possible with video_driver=null already 19:37 SFENCE hmmm.... interesting.... it looks like SDL_opengl.h shoudl not include GLES2 headers, SDL_opengles2.h should do it. 19:40 sfan5 can you open a bug with full details? this problem should not be happening and I can't make sense of it 19:43 SFENCE I also do not understand, becuse we are doing Android relases with GLES and withou OpenGL, Iam I right? 19:46 sfan5 yes 19:46 sfan5 or actually looking at our cmake files opengl is always enabled by default 19:47 sfan5 it will just not work on 90% on android devices (nvidia is notable for supporting it) 19:48 sfan5 and it's not disabled in android/native/build.gradle either 19:51 SFENCE_arch I will colect more info and do a PR. It also looks that irr/src/OPENGLES2/Driver.cpp uses definition not known in GLES2. 19:56 SFENCE_arch For example GL_RGB8 is not listed in https://registry.khronos.org/OpenGL/api/GLES2/gl2.h 19:57 SFENCE_arch and is used here https://github.com/minetest/minetest/blob/8d2e7703619205dd76ee9cc12fb0b660868c910b/irr/src/OpenGLES2/Driver.cpp#L52 19:58 sfan5 it's from gles3 19:58 sfan5 a gles2 header won't work to compile the driver 20:00 SFENCE_arch So the problem is that no gles3 headers is included here. 20:01 sfan5 the include is here https://github.com/minetest/minetest/blob/8d2e7703619205dd76ee9cc12fb0b660868c910b/irr/src/OpenGL/Common.h#L9-L15 20:06 SFENCE_arch Yeah, I tryed to add SDL_opengles2.h here (as test hotfix). But it looks like it incldues only GLES2 headers. 20:11 sfan5 sdl_opengl.h will silently just not define anything if you're on iOS. how useful 20:11 sfan5 is that what you are doing? 20:23 SFENCE_arch Yeah, I am trying build for iOS/iPhoneSimulator target. 20:24 sfan5 let it include vendor/gl.h instead 20:44 SFENCE Good typ. vendor/gl.h looks to perform well. 21:09 sfan5 https://0x0.st/XduU.png apparently my thoughts repeat themselves too 22:46 sfan5 I think we will eventually need to drop enable_post_processing so we don't have to maintain different code paths 22:58 sfan5 merging #15442, #15374 22:58 ShadowBot https://github.com/minetest/minetest/issues/15442 -- Remove unused and rarely used irrlicht color functions by HybridDog 22:58 ShadowBot https://github.com/minetest/minetest/issues/15374 -- Replace occurences of 'wiki.minetest.net' with 'wiki.luanti.org' by veprogames