| Time |
Nick |
Message |
| 01:01 |
|
Can0xfBows joined #minetest |
| 02:23 |
|
SwissalpS joined #minetest |
| 02:31 |
|
CRISPR joined #minetest |
| 02:32 |
|
SwissalpS joined #minetest |
| 03:12 |
|
v-rob_ joined #minetest |
| 03:28 |
|
SwissalpS joined #minetest |
| 03:33 |
|
fling_ joined #minetest |
| 03:43 |
|
amfl2 joined #minetest |
| 03:45 |
|
CRISPR joined #minetest |
| 04:23 |
|
yezgromafic joined #minetest |
| 04:31 |
|
SFENCE_arch joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:01 |
|
CRISPR joined #minetest |
| 05:10 |
|
v-rob_ joined #minetest |
| 05:17 |
|
mdhughes joined #minetest |
| 06:29 |
|
SFENCE_arch joined #minetest |
| 06:36 |
|
YuGiOhJCJ joined #minetest |
| 06:53 |
|
TomTom joined #minetest |
| 07:05 |
swift110-mobile |
Hey |
| 07:20 |
|
mrkubax10 joined #minetest |
| 07:30 |
|
bdju joined #minetest |
| 09:26 |
|
MacroFaxSax joined #minetest |
| 09:32 |
|
___nick___ joined #minetest |
| 09:34 |
|
gregon joined #minetest |
| 09:40 |
|
bdju joined #minetest |
| 09:47 |
|
gregon joined #minetest |
| 09:56 |
|
bdju joined #minetest |
| 10:18 |
MinetestBot |
[git] grorp -> minetest/minetest: Revert "2D rendering: Enable bilinear filter for downscaling textures… bafc477 https://github.com/minetest/minetest/commit/bafc4779199a0544303290efa7be82ba1be9d5ee (2024-11-08T10:17:15Z) |
| 10:20 |
|
tarsovbak joined #minetest |
| 10:26 |
|
___nick___ joined #minetest |
| 10:31 |
|
___nick___ joined #minetest |
| 10:34 |
|
gregon joined #minetest |
| 10:48 |
|
pgimeno left #minetest |
| 11:15 |
|
fluxionary joined #minetest |
| 11:39 |
|
SwissalpS joined #minetest |
| 11:50 |
|
ireallyhateirc joined #minetest |
| 12:14 |
|
mdhughes joined #minetest |
| 12:15 |
MTDiscord |
<warr1024> Not sure what "bilinear downscaling" means here, but as long as we don't lose the NNAA software prefilter this shouldn't actually make a difference... |
| 12:21 |
|
Baytuch_2 joined #minetest |
| 12:26 |
|
SpaceManiac joined #minetest |
| 13:15 |
|
Desour joined #minetest |
| 14:46 |
|
sinvet joined #minetest |
| 14:57 |
|
sinvet joined #minetest |
| 15:10 |
|
sinvet joined #minetest |
| 15:31 |
|
ireallyhateirc joined #minetest |
| 15:32 |
|
v-rob_ joined #minetest |
| 15:38 |
|
erstazi_ joined #minetest |
| 15:44 |
|
erstazi joined #minetest |
| 16:01 |
|
MacroFaxSax joined #minetest |
| 16:06 |
|
SFENCE_arch joined #minetest |
| 16:06 |
|
SFENCE joined #minetest |
| 16:58 |
|
v-rob_ joined #minetest |
| 17:23 |
|
erle joined #minetest |
| 17:24 |
erle |
thanks luatic and sfan5 for accepting that transparency patch! |
| 17:28 |
|
Desour joined #minetest |
| 18:10 |
|
Glaedr joined #minetest |
| 18:11 |
|
sinvet joined #minetest |
| 18:23 |
|
v-rob_ joined #minetest |
| 19:21 |
|
TheSilentLink joined #minetest |
| 19:26 |
|
sinvet joined #minetest |
| 19:26 |
|
___nick___ joined #minetest |
| 19:31 |
|
___nick___ joined #minetest |
| 19:33 |
|
Trifton joined #minetest |
| 19:41 |
|
Trifton_ joined #minetest |
| 19:44 |
|
SFENCE joined #minetest |
| 19:45 |
MinetestBot |
[git] grorp -> minetest/minetest: Fix ECF_D32 support in ogles2 video driver fced6ff https://github.com/minetest/minetest/commit/fced6ff2401dfb0504064ee164bc625eac49c4b9 (2024-11-08T19:43:24Z) |
| 19:45 |
MinetestBot |
[git] grorp -> minetest/minetest: ogles 2 driver: Delete some dead code 50b7523 https://github.com/minetest/minetest/commit/50b75233364c89235ec2f8f77fb54767a228e395 (2024-11-08T19:43:24Z) |
| 19:49 |
erle |
i will have another small regression fix within the hour (and no, nothing with shaders, a simple color channel toss-up, it should be entirely uncontroversial) |
| 20:01 |
specing |
is it 2erle to unban erle? |
| 20:03 |
erle |
you still trying to force the “2erle” meme lol |
| 20:13 |
specing |
it forces itself |
| 20:13 |
specing |
its so good |
| 20:13 |
|
SFENCE joined #minetest |
| 20:21 |
|
SFENCE joined #minetest |
| 20:29 |
|
jaca122 joined #minetest |
| 20:55 |
|
SFENCE joined #minetest |
| 21:07 |
erle |
it seems that the bilinear downscaling fix fixed the font rendering issues i had with unifont! |
| 21:08 |
erle |
thanks grorp |
| 21:27 |
|
SFENCE joined #minetest |
| 21:30 |
erle |
i was too optimistic lol |
| 21:30 |
erle |
but i have the fix |
| 21:34 |
erle |
specing behold |
| 21:37 |
erle |
luatic sfan5 celeron55 i have a simple correctness patch. before anyone asks, yes, this is a fix for a regression. due to the way irrlichtmt was merged (and me being inactive for a long time) i can not tell you when it last worked though. however, unless there are any endianness issues, this is probably the last correctness patch necessary for the TGA decoder for quite a while (as my test nodes are all rendered correctly with it applied on both x86 and x86_64). |
| 21:37 |
erle |
http://daten.dieweltistgarnichtso.net/src/0001-Fix-regressions-in-rendering-TGA-type-1-files-with-c.patch |
| 21:39 |
erle |
(i can tell you that this broke at some point between 5.4.1 and 5.10-rc1 though, but i guess that's not very useful information.) |
| 21:40 |
erle |
this is my test nodes in luanti 5.10-rc1 https://mister-muffin.de/p/P7NL.png |
| 21:41 |
erle |
this is my test nodes with both patches applied (the transparency fix you already applied and the one i just posted) https://mister-muffin.de/p/eNiy.png |
| 21:41 |
specing |
sorry I'm currently not caring, please try later |
| 21:41 |
|
sparky4 joined #minetest |
| 21:41 |
erle |
specing just look at the damn screenshots you, you, lazy person! |
| 21:42 |
erle |
pretty obvious that the bottom left test node has a color conversion issue |
| 21:42 |
|
Talkless joined #minetest |
| 21:43 |
specing |
erle: speaking of lazy, where's luerle working with upstream irrlicht and considerably raised nodedef limits, 32bit coordinates and compatible with legacy luanti servers? |
| 21:43 |
specing |
oh and I'll take cherry on top, too |
| 21:43 |
erle |
specing nodedef limits? what bullshit are you modding? |
| 21:43 |
erle |
like, how are you running out of that? |
| 21:43 |
specing |
can't register more than 32k nodes? |
| 21:43 |
erle |
are you trying to run ALL MODS AT ONCE? |
| 21:44 |
specing |
why, that's a reasonable use case |
| 21:44 |
erle |
*somehow* i never had that |
| 21:44 |
erle |
so what black magic fuckery got you close to that limit? |
| 21:45 |
erle |
having lots of nodes and wanting microblocks? |
| 21:45 |
erle |
tell |
| 21:45 |
specing |
yes |
| 21:45 |
erle |
i strongly suggest to, i don't know, try to hire proller or so lol |
| 21:45 |
|
Verticen joined #minetest |
| 21:45 |
|
jaca122 joined #minetest |
| 21:46 |
specing |
you get additional points if you implement microblocks in a smarter way |
| 21:46 |
erle |
points |
| 21:46 |
erle |
what's dumb about microblocks? |
| 21:46 |
specing |
they take up nodedef space |
| 21:46 |
specing |
whereas they could be autodefined for all nodes, just like rotations |
| 21:46 |
erle |
well you could do the voxelmodel trick if you ever fixed the lots-of-models performance issue |
| 21:47 |
erle |
or if you simply don't have lots of them |
| 21:47 |
erle |
sorry, the only node rendering thing i got into at some point was making waterlogged nodes |
| 21:47 |
erle |
turns out rendering those is super easy |
| 21:47 |
erle |
but the problem is that they kiiiiinda need a liquid type? or maybe not? |
| 21:47 |
erle |
they can't be sources |
| 21:48 |
erle |
like conceptually, you either need a waterlogged node for every liquid |
| 21:48 |
erle |
which i think is a bit weird |
| 21:48 |
erle |
or you have a rendering type that makes a node waterloggable |
| 21:48 |
specing |
what's proller up to, these days |
| 21:48 |
erle |
but then the fluid definitions need to be stolen from adjoining fluids |
| 21:49 |
specing |
is there a fork that I don't know about |
| 21:49 |
erle |
i actually made that last thing once |
| 21:49 |
erle |
it worked pretty well, with the exception of … well, what if there are two fluids adjacent? |
| 21:49 |
erle |
what if my waterloggable fencepost is between water and lava? |
| 21:49 |
erle |
it will not have the logic to just turn into a fencepost-embedded-in-cobble |
| 21:51 |
erle |
also i don't want fenceposts-embedded-in-cobble in my world |
| 21:51 |
MTDiscord |
<luatic> so far the solution for liquidlogging i'm eyeing is to just have the nodedef say which liquid it's gonna be in, seems simplest to me and should work well enough if there are only a few liquids and liquidloggable nodes |
| 21:51 |
erle |
luatic actually, i think the neutral waterlogged node is nicer for modding |
| 21:52 |
erle |
otherwise you can't just add mods to a game that add new liquids and have them work with waterlogging |
| 21:52 |
erle |
like all these colored water mods or so |
| 21:53 |
erle |
luatic, have you seen the patch and the screenshots? i spent zero time on root cause analysis cause it does not matter, but the color channels are no longer switched around. |
| 21:55 |
erle |
also i am pretty sure i like boring “hey why is this thing messed up, oh so that is the fix” patches the most of all |
| 21:55 |
erle |
because you don't have to discuss if it is necessary. only sometimes if it is the right place/way to fix it. |
| 21:55 |
erle |
removes one source of drama |
| 21:56 |
MTDiscord |
<luatic> erle: i'll look at it in a moment |
| 21:56 |
erle |
thank you |
| 21:56 |
|
mdhughes_ joined #minetest |
| 21:59 |
erle |
luatic as soon as that patch is merged, everything TGA works to the best of my knowledge (modulo the yellow tint on 16bpp monochrome TGAs maybe? but i only generate 8bpp monochrome TGA AFAIK, so i do not have a test node for that) |
| 22:00 |
erle |
i would be surprised if 16bpp monochrome PNG work well |
| 22:00 |
|
silverwolf73828 joined #minetest |
| 22:02 |
MTDiscord |
<luatic> if someone is feeding 16bpp images to luanti i'd like to ask them: why, just why? |
| 22:03 |
|
chilledfrogs joined #minetest |
| 22:04 |
erle |
how are you doing slanted text in my irc client? o.0 |
| 22:04 |
erle |
𝐢𝐭 𝐢𝐬 𝐧𝐨𝐭 𝐮𝐧𝐢𝐜𝐨𝐝𝐞 𝐢 𝐠𝐮𝐞𝐬𝐬 |
| 22:04 |
|
SFENCE joined #minetest |
| 22:06 |
MTDiscord |
<luatic> if you're lucky your irc client supports markdown |
| 22:07 |
Mantar |
erle: that fix is interesting, I spotted a similar problem with color+transparency in PNG rendering since around 5.4, but I keep forgetting to open an issue for it |
| 22:07 |
MTDiscord |
<luatic> otherwise i would get it is the weird IRC escape code thing and the bridge converts it |
| 22:07 |
MTDiscord |
<luatic> guess* |
| 22:08 |
MTDiscord |
<luatic> erle: https://modern.ircdocs.horse/formatting#italics |
| 22:08 |
erle |
Mantar i think luatic has a PNG library. if it allows similar levels of control as tga_encoder, you might be able to render better test nodes than devtest has. |
| 22:08 |
Mantar |
oh and it looks like Hexchat supports it |
| 22:09 |
MTDiscord |
<luatic> erle: only the decoder is full fledged, the encoder is just basic ARGB8 |
| 22:09 |
Mantar |
I'm not encoding pngs, though just displaying them |
| 22:09 |
MTDiscord |
<luatic> it's an encoder as dumb as the one in luanti in fact, the simplest thing that works |
| 22:09 |
erle |
oh lol okay |
| 22:09 |
MTDiscord |
<luatic> Mantar: yeah, erle was suggesting using my library for generating test files but i was explaining why that unfortunately isn't an option. if you want to read a PNG, have a go though ;) |
| 22:09 |
erle |
so the “outperformed by tga.gz” ;) |
| 22:10 |
MTDiscord |
<luatic> yes. |
| 22:10 |
erle |
i seriously suggest to look into prefilters though |
| 22:10 |
erle |
just don't try heuristics |
| 22:10 |
erle |
just let the user control which one |
| 22:10 |
erle |
oh and colormapping |
| 22:11 |
erle |
i mean if you ever want a more flexible library |
| 22:11 |
erle |
ofc |
| 22:11 |
MTDiscord |
<luatic> yeah frankly it's not a priority of me atm, but maybe i'll do that when i make it into a proper pure lua png lib i guess |
| 22:12 |
MTDiscord |
<luatic> anyways i just tested your fix, it works |
| 22:13 |
erle |
are you going to make a PR? (as i mentioned already, this is a regression) |
| 22:14 |
MTDiscord |
<luatic> yes, i can't guarantee that the fix will be in 5.10 though. but i think it's simple so you should have a very good chance. |
| 22:16 |
erle |
well, no one can guarantee anything. but i spent some hours on this by now AND it's a regression in an RC so i'd appreciate it. |
| 22:16 |
erle |
will there be a second RC? |
| 22:16 |
erle |
i think some projects do RCs until no one finds any new bugs anymore |
| 22:17 |
erle |
this can get a bit silly, but it guarantees that any remaining bugs are either not new or not obvious |
| 22:17 |
erle |
(or hard to fix, i.e. no patches exist and you release anyway) |
| 22:17 |
MTDiscord |
<luatic> mhrm i'm not sure this is the cleanest way to fix this |
| 22:18 |
erle |
haha, i thought about this a lot |
| 22:18 |
MTDiscord |
<luatic> it looks to me like your code still relies on a little endian system by treating a u32 pointer as a u8 pointer |
| 22:18 |
erle |
well if that's broken, then a lot of color conversions are broken rn |
| 22:18 |
erle |
i noticed some color conversion functions had little/big-endian switches |
| 22:18 |
erle |
and i was not sure |
| 22:19 |
erle |
but given this used to work on x86 and x86_64 and right now does not, i wonder where it *does* work and if it was maybe refucktored on a big endian system? (which one?) |
| 22:20 |
MTDiscord |
<luatic> hmm there's something i don't get though |
| 22:20 |
erle |
tell |
| 22:20 |
MTDiscord |
<luatic> if we're switching twice that shouldn't matter, the old code should have been correct then, it can't be just that |
| 22:21 |
MTDiscord |
<luatic> i wonder whether dP == sP is possible and used, that would explain it, but not be quite the same behavior as permuting |
| 22:21 |
erle |
well, you can simply change the [0], [1], [2], [3] in reverse in the old code, so it is definitely permuted |
| 22:22 |
erle |
because then it is correct |
| 22:22 |
erle |
hmm |
| 22:22 |
erle |
unless i am mistaken somehow |
| 22:22 |
erle |
anyway, things like these were why i modified the function that i knew worked – the one without the alpha |
| 22:22 |
|
SFENCE joined #minetest |
| 22:22 |
erle |
and simply made it alpha-aware |
| 22:22 |
erle |
why these functions are coded so differently, i don't know |
| 22:24 |
MTDiscord |
<luatic> i'll try something real quick and if that works, we have to fix this elsewhere |
| 22:24 |
erle |
luatic if there was more time, i'd investigate this further. but right now, i want it to work more than want to know why it works, given that there is exactly one code path that has this issue. if you find a better way, please tell me. |
| 22:25 |
erle |
https://forum.minetest.net/viewtopic.php?p=440470#p440470 also i wrote on the forums about my patch so if you have a better one, maybe reply there too |
| 22:25 |
erle |
i have to go soon unfortunately |
| 22:25 |
erle |
i postponed my social life for like 3 hours to make/test this patch |
| 22:26 |
MTDiscord |
<luatic> thank you for that, i think i will find a more proper patch quickly now hopefully though |
| 22:26 |
erle |
if it turns out to be wrong, send me an address to send queer stickers to |
| 22:26 |
MTDiscord |
<luatic> it is not wrong, but it is at the wrong place |
| 22:26 |
ireallyhateirc |
social life? what's that |
| 22:26 |
erle |
in what way? |
| 22:26 |
MTDiscord |
<luatic> i justed tested *dB = *sB; in place of it and it works as well |
| 22:27 |
MTDiscord |
<luatic> we're already accidentally performing the BGRA -> ARGB conversion via endianness somewhere else (when reading?) i think |
| 22:27 |
erle |
mhhhh |
| 22:27 |
erle |
damn |
| 22:27 |
erle |
if there is more time, i'd just ping cutealien |
| 22:27 |
erle |
the irrlicht person |
| 22:28 |
erle |
luatic if that conversion is already accidentally done, how did this *ever* work? |
| 22:28 |
erle |
that's one of the funny stages of debugging you know |
| 22:28 |
erle |
“how could this code have worked in the first place, before it got broken” |
| 22:28 |
Mantar |
yes, all too well |
| 22:29 |
MTDiscord |
<luatic> erle: this is a sign thing in the end, so if something somewere else fucks it up again it's fine ;) |
| 22:29 |
erle |
luatic wdym “sign thing”? |
| 22:29 |
MTDiscord |
<luatic> endianness reverses byte order, the conversion function reverses byte order |
| 22:30 |
MTDiscord |
<luatic> it's a sign thing because in a calculation where you're messing up signs the same thing happens, if you mess it up an even number of times the mistakes cancel out |
| 22:30 |
erle |
oh like the imagemagick upside down flip thing |
| 22:31 |
MTDiscord |
<luatic> yes! |
| 22:31 |
erle |
just trigger the bug twice lol |
| 22:31 |
erle |
as with the first patch, i think that code was maybe, just maybe, refactored without being tested ;) |
| 22:32 |
erle |
well now that i have these test nodes, i can do that as soon as i have a big endian |
| 22:33 |
erle |
the thing is, x86 and arm do little endian, so it may have only worked on little endian in the first place at all? |
| 22:33 |
erle |
anyway, i have to go |
| 22:33 |
erle |
thanks for your help luatic |
| 22:33 |
MTDiscord |
<luatic> bye |
| 22:33 |
MTDiscord |
<luatic> the tga spec is.. crispy |
| 22:34 |
erle |
luatic which spec are you looking at? |
| 22:35 |
erle |
the funniest thing i noticed is that when you do this combinatorial explosion thing that i do and generate all permutations, some apps just display garbage |
| 22:35 |
erle |
but only for one permutation |
| 22:35 |
MTDiscord |
<luatic> https://www.dca.fee.unicamp.br/~martino/disciplinas/ea978/tgaffs.pdf |
| 22:36 |
erle |
like there is one combination of feature flags that makes GIMP show messed up pixels |
| 22:36 |
erle |
like, just one |
| 22:36 |
erle |
but i bet you can do that for a lot of file formats |
| 22:36 |
erle |
luatic also look at my tga_encoder branch if you want to know things about byte swapping |
| 22:36 |
MTDiscord |
<luatic> software is only as good as it has to be ;) |
| 22:36 |
MTDiscord |
<luatic> and often worse lol |
| 22:37 |
erle |
yeah, but it was different combinations for different versions of image viewers |
| 22:37 |
erle |
sorry i mean different tools |
| 22:39 |
erle |
luatic btw, mtpaint is a really nice and fast texture creation tool |
| 22:40 |
|
SFENCE joined #minetest |
| 22:43 |
erle |
luatic here is what i suspect, all of the color conversion functions that do not special case endianness only work on one endianness. true? |
| 22:43 |
MTDiscord |
<luatic> i don't think so |
| 22:44 |
erle |
hmmm |
| 22:44 |
MTDiscord |
<luatic> for example the BGRA to ARGB is just a byteswap. if endianness causes you two byteswap twice, once when reading and once when writing, that doesn't matter, it cancels out and you're still swapping an odd number of times. |
| 22:44 |
erle |
hmmm |
| 22:45 |
erle |
well tga files are stored little endian, right? |
| 22:45 |
MTDiscord |
<luatic> I think the problem is that we're converting BGR(A) to ARGB for TGA at all on little endian machines |
| 22:45 |
MTDiscord |
<luatic> erle: yes, and that causes problems when reading on big endian. there you would need to swap. |
| 22:46 |
MTDiscord |
<luatic> but conceptually this is a "read this thing correctly" and not a "TGA stores BGRA" thing. |
| 22:46 |
erle |
my proposal would be to take my patch and show it to cutealien, in an attempt to tease out the correct solution |
| 22:46 |
erle |
:D |
| 22:47 |
erle |
you know like the stackoverflow thing where you explain how to do things slightly wrong |
| 22:47 |
MTDiscord |
<luatic> the correct solution is pretty obvious to me |
| 22:47 |
erle |
and people WILL correct you |
| 22:47 |
erle |
tell! |
| 22:47 |
MTDiscord |
<luatic> on little endian, byteswap after reading. we might abuse the color conversion for that. |
| 22:47 |
MTDiscord |
<luatic> big endian* |
| 22:47 |
erle |
please write this again |
| 22:47 |
MTDiscord |
<luatic> on little endian, do nothing, or just add a 255 alpha channel. TGA is already ARGB as we expect. |
| 22:48 |
MTDiscord |
<luatic> adding the 255 alpha is for RGB |
| 22:48 |
erle |
so you can simplify that patch ig |
| 22:49 |
MTDiscord |
<luatic> hmm though actually |
| 22:49 |
MTDiscord |
<luatic> i can look at tga encoder as a reference, right? |
| 22:50 |
erle |
just to be clear, i think you are very clever and i have prioritized “it works” over “this is conceptually correct”. but i'd appreciate a sussy patch for a *clearly* wrong situation more than a non-sussy patch that comes too late to be in the release. |
| 22:50 |
erle |
luatic you can look at my tga encoder branch as a reference and at my tga decoder. |
| 22:50 |
erle |
i spent WAY too much time |
| 22:50 |
erle |
also you can look at mtpaint source code or gimp if you want |
| 22:50 |
erle |
just don't do imagemagick lol |
| 22:51 |
erle |
also idk if anything else than my code is very explicit about scanline order (i think a lot of software just chooses one scanline order for writing and does one or both for reading) |
| 22:51 |
erle |
like i think quake only does bottom-top IIRC |
| 22:52 |
erle |
anyway, good night and thanks for the help. sorry to nerdsnipe you! |
| 22:52 |
erle |
ttyl |
| 22:52 |
MTDiscord |
<luatic> good night |
| 22:59 |
|
SFENCE joined #minetest |
| 23:09 |
[ |
no irc client (that I know of) does markdown, it's mIRC colour codes |
| 23:21 |
MTDiscord |
<luatic> well i always wanted to do a client that does markdown but maybe that's just me. it's the mIRC formatting codes then. |
| 23:22 |
|
SFENCE joined #minetest |
| 23:32 |
|
panwolfram joined #minetest |
| 23:32 |
|
cation joined #minetest |
| 23:57 |
|
SFENCE joined #minetest |
