| Time |
Nick |
Message |
| 01:41 |
|
v-rob joined #minetest-dev |
| 03:25 |
|
calculon joined #minetest-dev |
| 03:27 |
|
SFENCE_ joined #minetest-dev |
| 04:37 |
|
v-rob joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:52 |
|
SFENCE joined #minetest-dev |
| 07:27 |
|
ivanbu joined #minetest-dev |
| 07:30 |
|
cranezhou joined #minetest-dev |
| 09:22 |
|
Warr1024 joined #minetest-dev |
| 09:47 |
|
Warr1024 joined #minetest-dev |
| 10:52 |
[MatrxMT] |
<Zughy> Hello people, |
| 10:52 |
[MatrxMT] |
<Zughy> 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. |
| 11:43 |
|
fluxionary joined #minetest-dev |
| 12:56 |
[MatrxMT] |
<Zughy> 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 |
<greenxenith> 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] |
<Zughy> 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 |
<luatic> sfan5: I'll see what I can do about that, maybe I'm underestimating the extent |
| 13:49 |
MTDiscord |
<luatic> 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 |
| 13:51 |
|
vampirefrog joined #minetest-dev |
| 13:59 |
|
SFENCE joined #minetest-dev |
| 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:25 |
|
Alias joined #minetest-dev |
| 15:40 |
MTDiscord |
<luatic> 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 |
<luatic> sfan5: i doubt that |
| 16:00 |
MTDiscord |
<luatic> asymptotically there isn't really a difference, both ought to be linear time |
| 16:01 |
MTDiscord |
<luatic> 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 |
<luatic> we essentially need to mutate and reupload the entire buffer anyways |
| 16:02 |
MTDiscord |
<luatic> 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 |
<luatic> also ParticleBuffer::release needs to manage a free list |
| 16:03 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> i also believe that most particles will not be static but i have no statistic on this |
| 16:06 |
MTDiscord |
<luatic> 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 |
<luatic> 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] |
<Zughy> 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 |
<luatic> 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 |
<luatic> I tested the Flatpak myself and it did preserve my data (a game installation and world) just fine. |
| 16:37 |
MTDiscord |
<luatic> anyways btw sfan: the particle thing i consider more of a code quality than a performance thing, at least atm. |
| 16:48 |
|
SFENCE joined #minetest-dev |
| 17:26 |
|
BuckarooBanzai joined #minetest-dev |
| 17:27 |
|
BuckarooBanzai joined #minetest-dev |
| 17:29 |
|
BuckarooBanzai joined #minetest-dev |
| 17:34 |
|
BuckarooBanzai joined #minetest-dev |
| 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 <SDL_opengl.h> 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] |
<Zughy> 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 |
| 18:56 |
|
SFENCE_arch joined #minetest-dev |
| 19:17 |
|
SFENCE joined #minetest-dev |
| 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:54 |
|
SFENCE joined #minetest-dev |
| 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 |
| 19:59 |
|
SFENCE joined #minetest-dev |
| 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:05 |
|
SFENCE joined #minetest-dev |
| 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:15 |
|
v-rob joined #minetest-dev |
| 20:23 |
SFENCE_arch |
Yeah, I am trying build for iOS/iPhoneSimulator target. |
| 20:24 |
sfan5 |
let it include vendor/gl.h instead |
| 20:26 |
|
SFENCE joined #minetest-dev |
| 20:35 |
|
SFENCE joined #minetest-dev |
| 20:44 |
SFENCE |
Good typ. vendor/gl.h looks to perform well. |
| 21:05 |
|
hwpplayer1 joined #minetest-dev |
| 21:09 |
sfan5 |
https://0x0.st/XduU.png apparently my thoughts repeat themselves too |
| 21:53 |
|
vampirefrog joined #minetest-dev |
| 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 |
| 23:14 |
|
Thomas-S joined #minetest-dev |
| 23:14 |
|
Thomas-S joined #minetest-dev |
| 23:35 |
|
panwolfram joined #minetest-dev |
