Time |
Nick |
Message |
00:13 |
|
AliasAlreadyTake joined #minetest-dev |
00:32 |
|
v-rob joined #minetest-dev |
01:04 |
|
olliy joined #minetest-dev |
01:58 |
|
tekakutli joined #minetest-dev |
02:28 |
|
v-rob joined #minetest-dev |
03:29 |
|
queria^clone joined #minetest-dev |
03:33 |
|
queria^clone joined #minetest-dev |
03:34 |
|
jingkaimori joined #minetest-dev |
03:36 |
jingkaimori |
how can I retrieve CGUITTFont from client device? |
03:54 |
|
v-rob joined #minetest-dev |
04:14 |
|
v-rob joined #minetest-dev |
04:36 |
|
olliy joined #minetest-dev |
05:00 |
|
MTDiscord joined #minetest-dev |
05:12 |
|
Guest2 joined #minetest-dev |
05:53 |
|
jingkaimori joined #minetest-dev |
06:12 |
|
asdflkj_sh joined #minetest-dev |
06:22 |
jingkaimori |
are there some utility function in minetest that can calculate coordinates of a rect align at center of another rect? |
06:36 |
jingkaimori |
https://github.com/minetest/minetest/issues/1367 |
06:36 |
jingkaimori |
for this issue, I worked a texture render like this: |
06:50 |
jingkaimori |
https://i.bmp.ovh/imgs/2022/02/53f0ef03ecc88e5a.png |
06:50 |
jingkaimori |
texture is testnodes_1.png^[text:h |
06:50 |
jingkaimori |
text is overlaid and scattered |
07:11 |
|
v-rob joined #minetest-dev |
07:20 |
|
calcul0n joined #minetest-dev |
07:25 |
jingkaimori |
Is there a api to format a row of text and print them into irr:IImage? |
07:25 |
|
v-rob joined #minetest-dev |
07:28 |
jingkaimori |
I simply combine textures of glyph and I got this: https://i.bmp.ovh/imgs/2022/02/1e082a5b2315ff41.png |
07:40 |
MTDiscord |
<MNH48> I can't see any of your images btw, maybe ask your image host to see why they block some people from seeing the images |
07:40 |
MTDiscord |
<MNH48> https://cdn.discordapp.com/attachments/747163566800633906/944136341480951828/unknown.png |
07:42 |
MTDiscord |
<Sublayer plank> works for me, probably a cloudflare issue that is out of their control |
07:42 |
erlehmann |
it is not out of their control. they take responsibility. |
07:42 |
|
ivanbu joined #minetest-dev |
07:42 |
erlehmann |
here is a working pastebin/imagehost that is most likely without such issues https://mister-muffin.de/paste |
07:43 |
erlehmann |
https://mister-muffin.de/post.htm |
07:43 |
erlehmann |
a webinterface for non curl users |
07:45 |
jingkaimori |
another one with gui? |
07:46 |
erlehmann |
https://mister-muffin.de/post.htm |
07:46 |
erlehmann |
that is a GUI |
07:47 |
erlehmann |
1. select file 2. submit |
07:47 |
erlehmann |
it returns the filename |
07:47 |
jingkaimori |
https://mister-muffin.de/p/JANH.png first one |
07:48 |
jingkaimori |
https://mister-muffin.de/p/kuxq.png second one |
07:49 |
erlehmann |
do your glyph textures have all the same height? |
07:49 |
jingkaimori |
use default font |
07:50 |
jingkaimori |
height different |
07:54 |
sfan5 |
what you want to do is (re)use the the code in CGUITTFont because it already does typesetting |
08:01 |
jingkaimori |
but these code do not format characters onto the same baseline |
08:02 |
|
jingkaimori67 joined #minetest-dev |
08:03 |
|
appguru joined #minetest-dev |
08:04 |
|
jingkaimori65 joined #minetest-dev |
08:04 |
|
jingkaimori52 joined #minetest-dev |
08:05 |
jingkaimori52 |
sorry, my client is malfunctioning |
08:14 |
|
jingkaimori joined #minetest-dev |
08:35 |
erlehmann |
should i use localtime_s here? https://github.com/minetest/minetest/pull/12080 |
08:36 |
erlehmann |
the mingw build suggests it |
08:40 |
MTDiscord |
<Sublayer plank> localtime_s appears to be a newer version of localtime in the win32 API that supports... catching errors? |
08:42 |
MTDiscord |
<Sublayer plank> maybe windows should use the same code that it was using before, it's not POSIX so I'd assume it won't be able to be optimised in this way anyways (or it already is?) |
08:43 |
erlehmann |
oh, i have to check for errors obviously |
08:43 |
erlehmann |
abort on NULL |
08:44 |
erlehmann |
rubenwardy, https://github.com/minetest/minetest/security/advisories/GHSA-fvwv-qcq6-wmp5 is missing an association with CVE-2022-24301 and i can not seem to edit it. |
08:53 |
jingkaimori |
VS also suggest to use localtime_s |
08:55 |
erlehmann |
yes, but is this, ultimately, the correct thing to do? |
08:56 |
erlehmann |
given, for example, the target environment |
08:56 |
sfan5 |
if windows has no other function, probably |
08:56 |
sfan5 |
but localtime_s is not POSIX |
08:56 |
erlehmann |
it is an optional enhancement, as far as i see |
08:57 |
erlehmann |
sfan5 do you know if windows localtime() is similarly botched and reads files all the time? |
08:57 |
erlehmann |
or stats them |
08:57 |
erlehmann |
i mean, i get it, if the time zone changes during the program run, this will lead to wrong timestamps |
08:58 |
sfan5 |
I don't know Windows internals no |
08:58 |
erlehmann |
i have a friend with windows. any idea what is the windows equivalent of “strace -e %file” or so? |
08:58 |
erlehmann |
i can ask him to test |
09:16 |
|
jingkaimori joined #minetest-dev |
09:28 |
|
tekakutli joined #minetest-dev |
10:17 |
|
wsor4035 joined #minetest-dev |
10:33 |
|
queria[m] joined #minetest-dev |
10:33 |
|
_Zaizen_[m] joined #minetest-dev |
10:33 |
|
programmerjake joined #minetest-dev |
10:33 |
|
unexploredtest[m joined #minetest-dev |
10:33 |
|
zehka[m] joined #minetest-dev |
10:33 |
|
mister-e[m] joined #minetest-dev |
10:33 |
|
tochigi joined #minetest-dev |
10:33 |
|
freshreplicant[m joined #minetest-dev |
10:35 |
|
HuguesRoss joined #minetest-dev |
10:54 |
|
proller joined #minetest-dev |
12:10 |
|
appguru joined #minetest-dev |
12:22 |
|
Fixer joined #minetest-dev |
14:19 |
|
tekakutli joined #minetest-dev |
14:22 |
|
tekakutli joined #minetest-dev |
14:28 |
|
Taoki joined #minetest-dev |
14:42 |
|
Fixer joined #minetest-dev |
15:43 |
|
asdflkj_sh joined #minetest-dev |
15:58 |
|
v-rob joined #minetest-dev |
16:08 |
|
v-rob joined #minetest-dev |
16:13 |
|
Yad joined #minetest-dev |
16:23 |
|
erlehmann joined #minetest-dev |
16:34 |
|
calcul0n joined #minetest-dev |
17:04 |
erlehmann |
oh lol, localtime_s is cursed |
17:05 |
erlehmann |
in C11: struct tm *localtime_s( const time_t *restrict timer, struct tm *restrict buf ); |
17:05 |
erlehmann |
in microsoft CRT: errno_t localtime_s( struct tm* const tmDest, time_t const* const sourceTime ); |
17:06 |
erlehmann |
the order of parameters is reversed |
17:06 |
erlehmann |
thanks microsoft, i guess |
17:08 |
|
v-rob joined #minetest-dev |
17:13 |
erlehmann |
in minetest codebase, how do i do an ifdef for 32 and 64 bit versions of windows? |
17:13 |
sfan5 |
#ifdef _WIN32 |
17:15 |
sfan5 |
if you find yourself adding an ifdef in multiple places consider writing a wrapper function instead |
17:15 |
erlehmann |
so _WIN32 is also 64 bit windows? |
17:16 |
sfan5 |
yes |
17:16 |
erlehmann |
good |
17:16 |
erlehmann |
thx |
17:16 |
erlehmann |
i have two places and no idea why the screenshot function does not get the timestamp like everyone else. and i am not a fan of refactoring while bugfixing. it might obscure things. |
17:16 |
erlehmann |
so i will do it after my approach is validated |
17:25 |
erlehmann |
haha my github repo description was just test.mine.bz |
17:25 |
erlehmann |
https://web.archive.org/web/20111010002614/http://test.mine.bz/ |
17:35 |
|
Fleckenstein joined #minetest-dev |
18:40 |
erlehmann |
sfan5 this the correct use of ifdef given the rest of the codebase? https://github.com/minetest/minetest/pull/12080/files |
18:47 |
sfan5 |
s/^\s+// |
18:49 |
erlehmann |
wdym |
18:49 |
erlehmann |
no whitespace? |
18:50 |
rubenwardy |
^ is beginning of line |
18:50 |
rubenwardy |
so delete whitespace before # |
18:51 |
erlehmann |
ok |
18:56 |
erlehmann |
a side effect of my patch is that timestamps will be wrong if you change the time zone while playing minetest |
18:56 |
erlehmann |
because it reads the time zone once |
18:57 |
erlehmann |
i consider this an acceptable tradeoff for not doing a bazillion of syscalls |
18:57 |
erlehmann |
(for minetest, not for system software) |
18:58 |
MTDiscord |
<Sublayer plank> hmm, so how would it behave on a daylight savings rollover, for e.g. a server? would it just be one hour wrong until it restarts? |
18:59 |
Pexin |
does the OS changeover dst at midnight? |
18:59 |
erlehmann |
Subplayer plank i do not understand |
18:59 |
erlehmann |
i mean, i think it behaves the same as before, but what does this have to do with my patch? |
19:00 |
sfan5 |
DST is part of a timezone, the timezone does not change when DST rolls over |
19:00 |
erlehmann |
oh i see because i call tzset(3) |
19:00 |
MTDiscord |
<Sublayer plank> oh alright |
19:01 |
erlehmann |
if you have DST depends on the time zone |
19:01 |
erlehmann |
tzset(3) will set daylight to 1 if there is a time (past, present, future) where DST rules apply in the timezone |
19:03 |
MTDiscord |
<Jonathon> with your patch does minetest.get_us_time() still work reliably ? |
19:05 |
erlehmann |
uh, why would i mess with that? |
19:05 |
erlehmann |
i am literally only touching the conversion from timestamps to printable strings, strftime needs a tm struct |
19:07 |
erlehmann |
my primary goal is writing the code so it is obviously correct. please tell me how to achieve that. |
19:08 |
erlehmann |
and by obviously, i mean, i do not want anyone who looks at it later think this is a weird workaround that can be removed or something. |
19:08 |
erlehmann |
so please tell me if something in the code is not absolutely clear. |
19:09 |
erlehmann |
the localtime_s() thing is bad. bad microsoft! :< |
19:16 |
|
olliy1or joined #minetest-dev |
19:22 |
sfan5 |
erlehmann: the tool is called 'Process Monitor' btw https://i.imgur.com/FbCDyfU.png |
19:23 |
|
olliy joined #minetest-dev |
19:29 |
erlehmann |
thx |
19:29 |
erlehmann |
so how do i get approvals for my localtime fix |
19:29 |
erlehmann |
do i have to add a test case |
19:30 |
erlehmann |
i mean, i could actually make the CI fail if minetest is started and stats the same file over and over again hehe |
19:30 |
erlehmann |
but would that be accepted? |
19:43 |
MTDiscord |
<luatic> core devs: #11696 needs love (and reviews) |
19:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11696 -- Depth sorting for node faces by x2048 |
19:43 |
MTDiscord |
<luatic> it's really one of the most important fixes I see right now |
19:43 |
MTDiscord |
<Jonathon> ^ |
19:44 |
MTDiscord |
<luatic> it's really awesome x2048 put in the work, so please don't let it die |
19:45 |
MTDiscord |
<luatic> as x2048 seems to be a core dev now BTW, a single approval by another core dev should suffice |
19:45 |
erlehmann |
i wlll look at it |
19:46 |
erlehmann |
hopefully it fixes the slime behind glass case |
19:47 |
erlehmann |
or well, glass behind glass |
19:52 |
MTDiscord |
<Warr1024> or water behind glass |
19:53 |
MTDiscord |
<Warr1024> I have to be extremely conservative about alpha-blend-using materials as it is now, but even with only one it's not hard to find cases where it breaks. |
19:53 |
erlehmann |
slimes do not display when player is in water |
19:56 |
|
v-rob joined #minetest-dev |
20:00 |
MTDiscord |
<Warr1024> I'm not sure if that depth-sorting thing would necessarily help with that, would it? I'm unclear on whether it's for the whole scene or just stuff like mapblock meshes; it might be only a partial solution to the overall problem. |
20:01 |
MTDiscord |
<Warr1024> Also entities have this wonderful ability to intersect with terrain, which would put a simple per-surface depth sort at a bit of a disadvantage for dealing with that kind of situation unambiguously correctly. |
20:02 |
MTDiscord |
<Warr1024> I'd like to see the change merged but also the work continue in any areas where it still isn't 100%. I'd definitely NOT like to see this get stuck at 98% and never get merged because it doesn't hit 100%, though. |
20:14 |
appguru |
Warr1024, erlehmann: pretty sure it can't fix entity-node, particle-node or particle-entity depth sorting issues (and doesn't attempt to fix particle-particle depth sorting) |
20:14 |
appguru |
So it's mostly node-node and IIRC entity-entity? |
20:14 |
appguru |
For particle-particle there's raymoo's PR |
20:46 |
|
v-rob joined #minetest-dev |
21:04 |
|
v-rob joined #minetest-dev |
21:27 |
|
Yad joined #minetest-dev |
21:34 |
|
v-rob joined #minetest-dev |
22:07 |
HuguesRoss |
rubenwardy or sfan5: Can one of you give #9517 another quick look and confirm if your approvals stand? Both of you approved before issues were found and resolved, there are *technically* 3 approvals but only one occurred after this so it'd be nice to wrap this one up |
22:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/9517 -- FormspecMenu: make drawing of backgrounds less hacky by Desour |
22:08 |
erlehmann |
do approvals not get revoked with changes in a PR? o.0 |
22:09 |
HuguesRoss |
Apparently not |
22:09 |
HuguesRoss |
It threw me for a loop when I saw that today, I was about to give the merge countdown before I double-checked |
22:13 |
erlehmann |
HuguesRoss since you are looking at things, wanna look at https://github.com/minetest/minetest/pull/11978 ? |
22:15 |
|
proller joined #minetest-dev |
22:17 |
HuguesRoss |
Sure, why not |
22:21 |
Pexin |
!title |
22:21 |
ShadowBot |
Add TGA test nodes to devtest by erlehmann · Pull Request #11978 · minetest/minetest · GitHub |
22:44 |
|
v-rob joined #minetest-dev |
22:48 |
HuguesRoss |
After some consideration I've added my approval. I'll merge #11978 in about half an hour, barring a very good reason not to do so |
22:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/11978 -- Add TGA test nodes to devtest by erlehmann |
22:49 |
|
tekakutli joined #minetest-dev |
22:50 |
HuguesRoss |
I don't particularly like being in the position to make these kinds of deciding votes though. Generally I try to limit my involvement to verification, not decision-making. Given that this is a relatively small change and has multiple people voicing support, I'm making an exception here. |
22:53 |
MTDiscord |
<Jonathon> is tga going to be depreciated? only thing i can see. been said that it might, but nothing really official |
22:53 |
HuguesRoss |
There's been enough back-and-forth that I'd personally regard it as "that TODO that never gets addressed" |
22:53 |
HuguesRoss |
In such a case, better to at least have tests |
22:54 |
HuguesRoss |
Honestly, "that TODO that never gets addressed" describes a lot of things in Minetest |
22:55 |
v-rob |
/ TODO: Address all the TODOs |
22:56 |
v-rob |
TODO: Address the above TODO ^ |
23:11 |
|
v_rob joined #minetest-dev |
23:16 |
erlehmann |
Jonathon TGA was ripped out under the impression it was unused by hecks, then added after it was found out that this breaks mcl_maps. additionally, since it's basically a header followed by a bitmap (optionally colormapped or RLEd) it's really easy to read and write. i, for example, nead to read it in a future version of mcl_maps which will reveal the map piecewise. |
23:16 |
erlehmann |
some people suggested to use bmp or png for that purpose, but i'd bet money they never even checked if that makes sense. |
23:17 |
erlehmann |
(bmp has less features, png is needlessly complex for editing small bitmaps) |
23:17 |
sfan5 |
apart from the objection I raised TGA being potentially ripped out relatively soon would be another rason not to merge that |
23:17 |
erlehmann |
well someone would really not have to understand game engines to even *want* to rip it out? |
23:18 |
erlehmann |
i mean it's the one useful texture format that you can load fast |
23:18 |
erlehmann |
all others that were removed were not useful |
23:19 |
erlehmann |
sfan5, imagine changing a single pixel in a bitmap in a PNG file vs an uncompressed or compressed TGA file. |
23:19 |
erlehmann |
in the ideal case |
23:19 |
MTDiscord |
<Jonathon> what are texture modifiers |
23:19 |
erlehmann |
i am not going to create a 128x128 map image from texture modifiers |
23:19 |
erlehmann |
no thanks |
23:19 |
erlehmann |
that's horrible |
23:19 |
MTDiscord |
<Jonathon> not to mention there done client side so you dont have to send a new texture |
23:20 |
MTDiscord |
<Jonathon> unlike converting tga and then sending it |
23:20 |
erlehmann |
i think before making some assertions about that you should try to implement it |
23:20 |
MTDiscord |
<Jonathon> been there, done that |
23:20 |
erlehmann |
hint: mcl_maps used png at the beginning and then … not |
23:21 |
erlehmann |
well then i guess your creation is working, but cursed |
23:21 |
sfan5 |
erlehmann: and then what |
23:21 |
erlehmann |
sfan5 it's just that. if i want to draw a *lot* on a bitmap, it needs to be as close to the in-memory-representation. |
23:21 |
sfan5 |
I can imagine scenarious fine but that doesn't help any without knowing about whatever usecase you might be thinking of |
23:21 |
erlehmann |
i think the map that reveals whenever the player moves is a good one |
23:23 |
erlehmann |
like think about how to implement that |
23:23 |
erlehmann |
having a pixel array that you can just poke bytes in is a pretty neat thing |
23:23 |
erlehmann |
for both reading and writing |
23:24 |
sfan5 |
so bmp? |
23:24 |
erlehmann |
no, bmp is actually not that |
23:24 |
erlehmann |
tga is 18 bytes of header and then you dump your pixels and append a footer (not necessary, but minetest wants it, wasting bytes) |
23:25 |
erlehmann |
bmp is more header, then you have a weird row-based thing, then you have some padding, basically, it probably corresponded to *some* hardware at some point, but is not close to an RGBA pixel array in memory |
23:25 |
erlehmann |
look at the size of the bmp reader vs the tga reader if you don't believe me ;) |
23:26 |
erlehmann |
also bmp has features like “32bpp, but 8 bits are just padding, so it really is a weird RGB and not RGBA lol” |
23:26 |
sfan5 |
so by your definition a "bitmap" is "the exact in-memory pixel array format mineclone uses" |
23:26 |
erlehmann |
no |
23:26 |
sfan5 |
no? |
23:27 |
erlehmann |
think about how you would write a pixel array in a c program |
23:27 |
erlehmann |
and then serialize it |
23:27 |
erlehmann |
the BMP reading and writing will *always* be more steps than TGA |
23:28 |
erlehmann |
and BMP is lacking stuff too |
23:28 |
erlehmann |
there is a reason why games rarely use BMP for textures, but lots use TGA |
23:28 |
erlehmann |
incidentally, if you don't have a game where textures are largely 16x16, this makes them giant, even with RLE compression |
23:29 |
erlehmann |
so about bmp |
23:29 |
erlehmann |
bmp has a notion of “rows” |
23:29 |
sfan5 |
a negative linesize and padding does not suddenly make bmp "not a bitmap" or "pixel array that you can just poke bytes" false |
23:29 |
erlehmann |
rows need to be 4-byte aligned and are nul byte padded |
23:30 |
erlehmann |
also you have no alpha chanel in bmp (i believe this is important) |
23:31 |
erlehmann |
sfan5, look, bmp is not a contiguous streamable bitmap, but has rows and alignment and padding. is that a better wording? |
23:31 |
erlehmann |
really, i think “it's a lot more work to read or write it and you end up with less features” should settle it, i thought |
23:33 |
erlehmann |
not to get into stuff like “a bmp can optionally link to another file that contains a color profile” |
23:33 |
sfan5 |
to return to the initial point: you are not making your requiements clear, you said you needed a "pixel array that you can just poke bytes" but BMP doesn't actually cut it because your in memory format doesn't have padding (this is not BMP's fault) and also you just remembered that you want alpha too |
23:33 |
erlehmann |
or whatever that was |
23:34 |
erlehmann |
ok i must say, i have conflated the general case with my requirements |
23:36 |
erlehmann |
my requirements are: easy to write an implementation, easy to write a reader, has to deliver 32bpp BGRA, 16bpp ARGB, color-mapped. has to be streamable, low overhead when writing or reading. |
23:37 |
erlehmann |
use optipng on the checkerboard texture in devtest and then tell me the engine can do a better job :P |
23:37 |
erlehmann |
(last i checked, that PNG is 20 times the size it should be) |
23:38 |
erlehmann |
oh yeah also i need something for reference data |
23:38 |
erlehmann |
and no, your idea to use some pixel arrays in source code is really not workable |
23:38 |
erlehmann |
because i won't be able to edit them easily with the gimp (yes, XPM or so exist, but no) |
23:40 |
erlehmann |
i believe i should maybe have made the requirements by map authors clearer and then the abomination that is the [png texture modifier could maybe not have happened. |
23:40 |
erlehmann |
map as in, mcl_maps |
23:41 |
erlehmann |
regardless, i don't think it even makes sense to discuss removal of something that is in wide use. i mean, i advocated for bmp removal myself (since it's useless if you have TGA and PNG), but rubenwardy said it is used, so you have to keep it ig. |
23:42 |
erlehmann |
ironically, i even tried to figure out how to best remove tga from the engine without disrupting anything |
23:42 |
erlehmann |
but it turns out that kinda requires improving TGA support, so it's the wrong direction haha |
23:42 |
erlehmann |
so i stopped thinking about it |
23:43 |
sfan5 |
it's funny how easily you are calling usecases that do or do not match your own "wide use" or "useless" |
23:43 |
erlehmann |
oh no, i mean: everything that you will want to do with bmp you can do with tga or png better |
23:43 |
erlehmann |
if you look at them in isolation |
23:43 |
sfan5 |
that's not quite the same |
23:43 |
erlehmann |
obv ms paint might only write bmp or something |
23:44 |
sfan5 |
you just argued that BMP did not work for you because it had a different pixel layout, someone with code that writes BMP could argue the reverse |
23:45 |
erlehmann |
i am pretty sure that everyone i have met that evaluated this question chose tga in the end |
23:45 |
erlehmann |
in particular game devs |
23:45 |
erlehmann |
i mean a lot of ppl think of bmp first |
23:46 |
erlehmann |
(until they want to read or write it) |
23:46 |
erlehmann |
devine for example |
23:47 |
erlehmann |
devine implemented a tga parser in december 2021 for uxn |
23:48 |
erlehmann |
and writer i guess? a whole toolchain |
23:49 |
erlehmann |
sfan5, really, i think the best way to figure it out for yourself is to actually try to do something that makes map art and encode it in lua. |
23:49 |
sfan5 |
I would be using core.encode_png obviously |
23:49 |
erlehmann |
and then you read it back to edit the map again … how? |
23:50 |
sfan5 |
raws can be cached in whatever format is convenient completely independent of the end products |
23:51 |
erlehmann |
again, if you want it to be, a TGA is 18 bytes header + whatever raw bytes you have laying around |
23:51 |
erlehmann |
+ footer because irrlicht lol |
23:51 |
sfan5 |
ineffiency is free |
23:51 |
sfan5 |
how convincing |
23:51 |
erlehmann |
indeed, it is. PNG for example, will write 69 bytes before it stores a single pixel |
23:52 |
erlehmann |
which means the [png texture modifier will have about … |
23:52 |
sfan5 |
you didn't mention how many pixels your maps are |
23:52 |
erlehmann |
92 bytes of useless busywork |
23:54 |
erlehmann |
my maps are 128x128 pixels, giving an upper bound on uncompressed content of about 32k (PNG upper bound is similar) |
23:54 |
erlehmann |
16k if you have a palette, vastly less if you use RLE |
23:55 |
erlehmann |
look, i believe that encode_png in minetest is a kneejerk reaction to people saying “we need maps” |
23:55 |
erlehmann |
from someone (hecks?) who did not think *too* long about the scenario |
23:55 |
erlehmann |
otherwise the API would look different |
23:55 |
erlehmann |
(and it probably would only write paletted images then) |
23:56 |
sfan5 |
nobody talked about maps lmao |
23:56 |
sfan5 |
it is amazing how everytime you open your mouth it's always some estimated half-truth |
23:56 |
sfan5 |
fuck you |
23:56 |
sfan5 |
i'm going to bed |
23:56 |
erlehmann |
well then i really don't know why it was made. it seems to be not faster than modlibs encoder and not better? |
23:56 |
erlehmann |
if you have some chatlog where you discuss this, enlighten me |
23:56 |
erlehmann |
or maybe someone else has |
23:57 |
erlehmann |
i really don't want to spread falsehoods, i just saw that it was really close to the maps discussion |
23:57 |
erlehmann |
so maybe i misremember it |
23:57 |
erlehmann |
welp, if someone else knows why it was made, please tell. i'll try to grep the logs. |
23:58 |
erlehmann |
and i really didn't want to upset you |
23:58 |
erlehmann |
oh, i saw, you authored it too |
23:58 |
erlehmann |
i'm sorry |
23:59 |
erlehmann |
maybe you can tell me some time later why you made it that way |