| Time |
Nick |
Message |
| 00:00 |
|
kilbith joined #minetest-dev |
| 01:21 |
|
diceLibrarian joined #minetest-dev |
| 01:37 |
|
kilbith joined #minetest-dev |
| 02:22 |
MTDiscord |
<FatalError> why is the async API so vague? |
| 02:23 |
MTDiscord |
<FatalError> does it have access to serialize? |
| 02:34 |
MTDiscord |
<FatalError> https://cdn.discordapp.com/attachments/747163566800633906/1030307520683724840/unknown.png |
| 02:36 |
|
YuGiOhJCJ joined #minetest-dev |
| 03:37 |
|
diceLibrarian joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:08 |
|
diceLibrarian joined #minetest-dev |
| 05:37 |
MTDiscord |
<kimapr> 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 |
| 06:28 |
|
calcul0n_ joined #minetest-dev |
| 06:42 |
|
appguru joined #minetest-dev |
| 07:01 |
|
appguru1 joined #minetest-dev |
| 07:18 |
|
calcul0n_ joined #minetest-dev |
| 07:37 |
|
calcul0n joined #minetest-dev |
| 07:46 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:42 |
|
appguru joined #minetest-dev |
| 09:47 |
|
appguru joined #minetest-dev |
| 11:31 |
|
proller joined #minetest-dev |
| 11:34 |
|
cranezhou joined #minetest-dev |
| 11:43 |
|
cranez joined #minetest-dev |
| 11:53 |
|
Taoki joined #minetest-dev |
| 12:06 |
|
cranezhou joined #minetest-dev |
| 12:18 |
|
cranezhou joined #minetest-dev |
| 12:52 |
|
Desour joined #minetest-dev |
| 13:13 |
|
Fixer joined #minetest-dev |
| 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. |
| 17:30 |
|
Fixer_ joined #minetest-dev |
| 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 |
<Warr1024> 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 |
<Warr1024> Oh, yeah, that'd be pretty nice. |
| 19:14 |
MTDiscord |
<Warr1024> 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 |
<sfan5> [...] 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" |
| 20:07 |
|
proller joined #minetest-dev |
| 20:31 |
|
Desour_ joined #minetest-dev |
| 20:41 |
|
Alias joined #minetest-dev |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 23:43 |
|
AliasAlreadyTake joined #minetest-dev |
