Time Nick Message 02:22 MTDiscord why is the async API so vague? 02:23 MTDiscord does it have access to serialize? 02:34 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1030307520683724840/unknown.png 05:37 MTDiscord print(dump(_G)) 06:21 sfan5 I tried to be not so vague but the only alternative is writing down every function it does have, which I wanted to avoid 06:21 sfan5 rule of thumb is that everything which interacts with the game world or players is not available 14:41 sfan5 schwarzwald[m]: can you rebase irr#136? 14:41 ShadowBot https://github.com/minetest/irrlicht/issues/136 -- Replace _IRR_OVERRIDE_ macro with override keyword by JosiahWI 14:41 sfan5 not because it's needed but so the workflow run once more 16:43 schwarzwald[m] I can do that when I get home. 18:31 Desour what do you all think about adding SDL_image as dependency at some point? it supports all image formats we use: https://wiki.libsdl.org/SDL_image/FrontPage ; also, we'd not be the only game that uses it; and it says it supports simple svg 18:32 Desour (sdl2_image of course, not the sdl1 version) 18:44 sfan5 which libraries does it depend on? 18:51 Desour on archlinux: sdl2 libpng libtiff libjpeg libwebp libavif libjxl 18:51 Desour but the docs say that you can turn some off via build option 18:52 rubenwardy makes sense if we're moving to sdl2 18:52 Desour that is: libavif, libjxl, libtiff, libwebp 18:53 Desour (those are off by default it says) 19:07 sfan5 so none for svg apparently 19:10 MTDiscord SVG support would be neat, but given that it's a super complex format with tons of features and libraries only ever support some subset, and that you'd still have to have a setting for the resolution to render them to for texture loading (and there might be no one single value that's good for any given user across all meshes) it might have been unrealistic to try to support SVG seriously in MT. 19:12 sfan5 I was thinking svg is good for GUI usage, MT would then render at some fixed resolution (e.g. always 256x on 1080p screens) and leave the rest up to bilinear scaling 19:13 MTDiscord Oh, yeah, that'd be pretty nice. 19:14 MTDiscord For GUI use, you actually COULD render SVGs on the fly to specific exact resolutions, because you'll know the pixel size that they'll be displayed at; it won't vary based on how close people get to things or something... 19:15 Desour instead of rasterizing svgs we could of course instead create our own format, i.e. where the user gives some 2d vertices (with colors or uv coordinates), vertex indices and a primitive mode 19:46 pgimeno [...] render at some fixed resolution (e.g. always 256x on 1080p screens) and leave the rest up to bilinear scaling 19:46 pgimeno do you mean downscaling? 19:47 sfan5 well if you have an image button larger than 256 pixels it'd not be downscaling 19:47 pgimeno downscaling can produce aliasing if you downscale to less than 50% of the original resolution (Nyquist theorem) 19:48 Desour then just remove the high frequencies, use mipmapping 19:50 pgimeno well, with mipmapping active it wouldn't be a problem, but things get somewhat more complex, as mipmapping is a rendering option, and it increases memory usage 19:50 sfan5 but yes I mean downscaling 19:50 celeron55 some users have been wanting to have image per-pixel reading support on the server, adding sdl_image as a dependency to the server could be considered if it would anyway be a dependency of the client 19:50 sfan5 you'd pick the fixed resolution so that image buttons are usually within 50-100% of it by size 19:56 pgimeno that may work, only problem is "usually"