Time  Nick       Message
09:50 MTDiscord  <exe_virus> Yeah no, that's hilariously wrong
09:51 MTDiscord  <exe_virus> It should store the binary vertex buffer version
10:18 sfan5      that's what I thought too
10:19 sfan5      so I wrote the code to do this and the parsed versions are 7x times bigger than the files
10:19 sfan5      and loading on demand doesn't seem to ever have been a problem since it's so quick
11:02 celeron55  that's quite funny
11:02 celeron55  it's so wrong it's better
11:08 rubenwardy if it's parsed on demand, is it parsed for each usage?
11:12 sfan5      yes
14:01 jan_Elon   just noticed the 3d sokoban minetest game, and now i'm wondering if it's possible to make wolfenstein in minetest
14:45 MTDiscord  <exe_virus> But it's gotta be faster to store them some other way? Like at least pre do the string reading and parsing? Store the actual variables in struts rather than .txt?
14:46 MTDiscord  <exe_virus> I mean, it's gotta be more efficient for .obj specifically, a float is 4 bytes, and to store say "1.025" is 5 bytes.
14:46 MTDiscord  <exe_virus> And a float is native and "1.025" requires a function conversion call...
14:47 MTDiscord  <exe_virus> I'll have to test out an intermediate format I guess, cause that's crazy it would be 7x internally.
15:14 sfan5      @exe_virus @Luatic feel free to test https://github.com/minetest/minetest/pull/11652
15:15 sfan5      and/or benchmark
15:15 MTDiscord  <Jonathon> @Luatic ^
15:18 MTDiscord  <exe_virus> Will do, I have a newborn though, so I can't say I'll get to it in any particular timeframe
15:19 sfan5      sure I don't expect you to test it, just highlighted you since you wondered about it
16:11 MTDiscord  <exe_virus> Thank you, I do intend to be a better contributor going forward engine side. Just current project is  'game' related trying to package minetest into a retail store box before Christmas season in the US
16:36 sfan5      pushing http://sprunge.us/hCpURe?diff in a few mins
20:17 pgimeno    any thoughts on https://codeberg.org/pgimeno/irrlichtmt/pulls/1 ?
20:18 sfan5      I agree but I'd do it a bit differently
20:18 pgimeno    like looking for all uses of s32 and replace them with u32?
20:19 pgimeno    or?
20:19 pgimeno    oh by the way, Irrlicht doesn't support top-down BMPs, the height field is unsigned
20:20 sfan5      I'd move the limit/checking code to a shared header file
20:20 pgimeno    thus the compiler is giving a warning in the comparison
20:20 pgimeno    hmm... I'd say it's a format-specific thing, like the number of planes
20:20 pgimeno    I mean channels, more than planes
20:22 pgimeno    you know whether to keep parsing only once you've parsed the header
20:24 pgimeno    the patch also limits the BMP planes, checks that the PNG bitdepth is sensible, and handles invalid TGA colormap bit depths
20:26 sfan5      ah yeah about PNG: I'm pretty sure that's pointless
20:26 sfan5      the code tells libpng to convert 16-bit to 8-bit and <8-bit to normal RGBA or whatever it is expecting
20:32 pgimeno    and what would it do with 7 bits?
20:32 pgimeno    or with 40 bits
20:33 pgimeno    rather than checking that it's safe, I went with a validation
20:34 pgimeno    the PNG spec says that only 1, 2, 4, 8 or 16 bpp are valid
20:34 sfan5      I'm sure libpng checks that then
20:38 pgimeno    probably, but I don't know if libpng passes a validated value to the app, I have my doubts
20:39 pgimeno    and if it doesn't, and it passes 40 to the app when it's in the header, and treats that as 16 internally, Irrlicht will misbehave, because it expects 16
20:40 pgimeno    if it considers an invalid value a fatal error, or if it filters the value from the header when reading it, then yes, the check is pointless