| Time |
Nick |
Message |
| 00:01 |
|
loggingbot_ joined #minetest-dev |
| 00:01 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 00:02 |
|
nrz joined #minetest-dev |
| 00:02 |
|
Warr1024 joined #minetest-dev |
| 00:03 |
|
fluxionary joined #minetest-dev |
| 00:04 |
|
Noisytoot joined #minetest-dev |
| 00:05 |
|
Krock joined #minetest-dev |
| 00:07 |
|
fluxionary joined #minetest-dev |
| 00:49 |
|
_yella_ joined #minetest-dev |
| 00:50 |
|
_yella_ joined #minetest-dev |
| 00:56 |
|
_yella_ joined #minetest-dev |
| 00:56 |
|
_yella_ joined #minetest-dev |
| 02:10 |
|
Alias joined #minetest-dev |
| 02:12 |
|
YuGiOhJCJ joined #minetest-dev |
| 03:17 |
|
fluxionary joined #minetest-dev |
| 03:27 |
|
BuckarooBanzai joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:02 |
|
calcul0n joined #minetest-dev |
| 06:11 |
|
freelikegnu joined #minetest-dev |
| 06:17 |
|
v-rob joined #minetest-dev |
| 07:52 |
|
tekakutli joined #minetest-dev |
| 08:03 |
[MTMatrix] |
<localhost> function on_place convert's callable function to cycle? How make on_use same behavior? |
| 09:41 |
|
calcul0n joined #minetest-dev |
| 11:18 |
MTDiscord |
<luatic> localhost: sorry, but i can't make sense of your message |
| 11:31 |
[MTMatrix] |
<localhost> Okay, how make "full_punch_interval" when player activates on_place event? |
| 11:32 |
[MTMatrix] |
<Zughy> This is for #minetest, please ask there. It's not the first time someone tells you that |
| 11:33 |
[MTMatrix] |
<localhost> eh... sorry, just here more faster answer :D |
| 13:11 |
|
appguru joined #minetest-dev |
| 14:52 |
|
Pexin joined #minetest-dev |
| 15:46 |
|
v-rob joined #minetest-dev |
| 16:30 |
MTDiscord |
<grorp> Merging #13790 and #13772 in 20 min |
| 16:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/13790 -- Remove undocumented and useless `air_equivalent` parameter by Zughy |
| 16:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/13772 -- Make the crosshair DPI-aware by grorp |
| 16:33 |
erle |
grorp wait, what's with “It appears to be used in some games and mods on ContentDB” from here? https://github.com/minetest/minetest/issues/13722#issuecomment-1667846289 |
| 16:33 |
erle |
i know it does not have any effect now (it was used to see if grass could grow under a block) |
| 16:34 |
erle |
but if i am not mistaken, this PR makes something truthy now falsy (i.e. nil) |
| 16:36 |
ROllerozxa |
hmm, looks like the zipgrep link expired |
| 16:36 |
erle |
please make a new one then |
| 16:36 |
MTDiscord |
<grorp> i was about to ask the same |
| 16:36 |
MTDiscord |
<grorp> :) |
| 16:36 |
erle |
i am pretty sure we can figure out if this is going to cause crashes or not |
| 16:36 |
erle |
but the author of the PR seems to not know what the property did, only that it is unused |
| 16:36 |
erle |
grorp ROllerozxa can you do the zipgrep thing? |
| 16:37 |
ROllerozxa |
I'll run a new zipgrep search rq |
| 16:37 |
erle |
thx thx |
| 16:38 |
erle |
ROllerozxa use this script on the resulting URL to get a permalink: http://news.dieweltistgarnichtso.net/bin/wayback-save |
| 16:39 |
ROllerozxa |
while the zipgrep is running, I do remember that nodecore does something with air_equivalent, so that should be tested and fixed if it will be removed |
| 16:39 |
ROllerozxa |
erle: ah neat, archiving from the terminal :) |
| 16:41 |
rubenwardy |
perhaps zipgrep should export the results as an upload |
| 16:41 |
ROllerozxa |
https://content.minetest.net/zipgrep/501df1d6-4355-4fd8-8afb-947ea023aa6e/ |
| 16:41 |
erle |
or you just do the archive.org dance like i do |
| 16:42 |
MTDiscord |
<grorp> Alright, I guess removing air_equivalent would break some stuff in NodeCore. |
| 16:43 |
ROllerozxa |
(and https://web.archive.org/web/20230911164208if_/https://content.minetest.net/zipgrep/501df1d6-4355-4fd8-8afb-947ea023aa6e/ for future reference) |
| 16:43 |
erle |
ROllerozxa, please post it to issue and PR |
| 16:43 |
erle |
zughy grorp now the postmortem question: did anyone of you care about this before i told you this? if so, why not? |
| 16:43 |
erle |
after all ROllerozxa did provide a zipgrep before. did it expire too fast? |
| 16:44 |
sfan5 |
it seems falling_item, pirenesi_redo,witches and nodecore would break due to this |
| 16:45 |
sfan5 |
if we want to be careful the field could be changed to so it throws a deprecation warning when accessed, then removed next release |
| 16:45 |
sfan5 |
s/would/could/ |
| 16:45 |
[MTMatrix] |
<Zughy> As you wish but I'm not gonna make the PR |
| 16:46 |
[MTMatrix] |
<Zughy> If people rely on undocumented legacy behaviour, it's not my fault |
| 16:47 |
erle |
okay, just a moment here |
| 16:47 |
sfan5 |
that was an idea, not a "we should do this" |
| 16:47 |
erle |
do you actually know why this property exists? |
| 16:48 |
erle |
chestertons fence does apply here: i see it is evidently useful to correctly handle air and ignore and so on. the engine internally uses light propagation for the grass-growing use case, but what would be the ”fix”? spoiler: hardcoding the names of air and ignore *might* not be it. |
| 16:49 |
[MTMatrix] |
<Zughy> Isn't that "airlike" job? |
| 16:49 |
erle |
i do not know. but evidently you did not research why anyone still relies on it before making the PR. |
| 16:50 |
erle |
it might all be legacy, but i don't see a clear case for ripping it out right now. |
| 16:51 |
MTDiscord |
<grorp> Documenting it might be less complicated than removing it. |
| 16:51 |
erle |
yeah |
| 16:52 |
erle |
it's not like these 2 lines hurt anyone |
| 16:52 |
ROllerozxa |
Zughy: that was my assumption too yes, but I realised that might be too broad if you only want to check for an "air equivalent" node, not just any invisible node |
| 16:52 |
sfan5 |
you would need to come up with an useful description and depending on what you come up with that might put existing mods in a bind because they suddenly have to declare their nodes air_equivalent to match the docs |
| 16:53 |
erle |
well, it definitely isn't light_propagates |
| 16:53 |
ROllerozxa |
I'd be interested to hear Warr1024: 's take on how nodecore uses it in more detail and if the airlike drawtype could be a replacement |
| 16:54 |
erle |
ROllerozxa i have strong doubts that this can be a drawtype thing |
| 16:54 |
erle |
the existing usage has nothing to do with drawtypes |
| 16:54 |
|
Desour joined #minetest-dev |
| 16:55 |
erle |
zughy did you make more PRs recently that ripped out, cut down, or deprecated stuff that just “seemed superfluous” because they were not used in the source code? it might be a good idea to look at them if that was not just a one-off and if you list them, i am willing to spend a bit of my time on it. |
| 16:56 |
[MTMatrix] |
<Zughy> Frankly I don't understand why we have to focus on these little things every time you pop up. We have, what? Two games that MIGHT break for an undocumented aspect, but we have to spend hours to discuss whether is safe or not to remove it instead of kindly asking these games (maintained by the same person) to remove those lines instead |
| 16:57 |
erle |
i *mostly* pop up in this way if i see needless breakage and want to prevent it |
| 16:57 |
[MTMatrix] |
<Zughy> We have a main menu that looks like shit and that scares people away but nooo, let's focus on this |
| 16:57 |
erle |
well, i am not preventing you focusing on the main menu. look, i offered my help, nothing more. |
| 16:57 |
|
fluxionary joined #minetest-dev |
| 16:57 |
erle |
because i think i might see things you would ignore, that's all. |
| 16:57 |
MTDiscord |
<grorp> Time to merge #13772, I guess :) |
| 16:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/13772 -- Make the crosshair DPI-aware by grorp |
| 16:57 |
erle |
and also i think breakage is bad unless you have a plan for it |
| 16:57 |
MTDiscord |
<grorp> I'm sorry for planning to merge the other PR so quickly. I didn't expect that removing two undocumented lines of code could cause any problems. |
| 16:58 |
erle |
grorp just do the zipgrep thing next time or ask someone |
| 16:58 |
erle |
if it had really not been used, the PR would not have been an issue |
| 16:58 |
erle |
(or, maybe … ? no idea reall) |
| 17:00 |
erle |
grorp a question for my understanding: how does the crosshair thing avoid the scaling problems the icons in the main menu have? |
| 17:01 |
ROllerozxa |
the built-in crosshair isn't a texture iirc |
| 17:01 |
ROllerozxa |
it can be overriden with one, but the default one is just drawn with lines |
| 17:01 |
erle |
so is object_crosshair.png scaled too or not? |
| 17:02 |
erle |
because if it is scaled, i don't see how it ensures that it is not distorted or blurred |
| 17:03 |
erle |
btw, i am pretty sure that torches can be air_equivalent and are not rendered airlike |
| 17:03 |
erle |
not sure if that makes sense |
| 17:04 |
MTDiscord |
<grorp> texture crosshairs will be scaled too if you have a "non-standard" DPI or hud_scaling. yes, that might cause some artifacts. like everywhere else in Minetest where textures are scaled. |
| 17:04 |
MTDiscord |
<grorp> A solution might be limiting scaling to integer multiples. |
| 17:04 |
erle |
grorp so the PR makes pixel-perfect crosshairs into (probably larger) non-pixel-perfect ones? |
| 17:04 |
ROllerozxa |
(also if anyone wants to run a zipgrep on CDB packages for anything in the future, then ask me, ruben or any other CDB staff and we can run a search for you) |
| 17:05 |
erle |
grorp i would *strongly* suggest to round your scaling to integer multiples for any provided PNG |
| 17:05 |
erle |
the main menu icon scaling is atrocious (and there is no good way around it AFAIK, i.e. no way of getting it right) |
| 17:06 |
MTDiscord |
<grorp> erle: on most setups, it shouldn't. on some setups, it will. |
| 17:06 |
erle |
i bet you have a retina display lol |
| 17:06 |
MTDiscord |
<grorp> no :) |
| 17:07 |
erle |
so did you test it with provided chrosshairs and made sure it did not blur them on *your* setup? |
| 17:07 |
ROllerozxa |
just throwing it out there, how difficult would it be to make the GUI use integer scaling? I know it's possible to make pixel fonts use integer scaling if you set up font_size_divisible_by properly |
| 17:07 |
erle |
ROllerozxa that is actually the solution that many other games use that have pixel-based textures. chiefly among them, openttd. |
| 17:08 |
erle |
ROllerozxa the solution for the icons requires a bit more nuance than that though. you basically have to figure out a size (probably a power of two) to which to pad them out and then scale them (hopefully only up). |
| 17:11 |
ROllerozxa |
yeah, minecraft does the same as openttd I assume, it scales the GUI in fixed steps assuming the window size is large enough for it |
| 17:11 |
MTDiscord |
<grorp> erle: yes, I did, of course. |
| 17:11 |
MTDiscord |
<grorp> Actually, integer-multiple scaling would be very easy to implement for the crosshair. For other stuff, not so. |
| 17:11 |
ROllerozxa |
obviously I know that the issue is that we're working with a GUI inherited from irrlicht that isn't designed for pixel perfect GUIs but flashy 00s ones with gradients and whatnot |
| 17:11 |
erle |
that has nothing to do with irrlicht and everything to do with not caring about pixel perfect rendering lol |
| 17:12 |
rubenwardy |
you can get pixel perfect scaling without integer-scaling by using 9-slice style techniques |
| 17:12 |
erle |
rubenwardy yeah but probably not for a crosshair png |
| 17:19 |
erle |
grorp since you did not merge #13790, would you unapprove it so it does not get merged accidentally? |
| 17:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/13790 -- Remove undocumented and useless `air_equivalent` parameter by Zughy |
| 17:21 |
[MTMatrix] |
<Zughy> Lol |
| 17:21 |
[MTMatrix] |
<Zughy> What a fucking joke |
| 17:21 |
erle |
what's the joke here? |
| 17:21 |
erle |
no breakage, no problems |
| 17:21 |
[MTMatrix] |
<Zughy> You're the problem |
| 17:22 |
erle |
oh my |
| 17:24 |
ROllerozxa |
ouch |
| 17:25 |
MTDiscord |
<warr1024> NodeCore uses air_equivalent pretty extensively. I wasn't aware it was undocumented; it seemed pretty self-documenting to me. |
| 17:26 |
MTDiscord |
<warr1024> "Airlike" is not a replacement; there are a number of things that use the same rendering method as air but are not actually equivalent to air. |
| 17:26 |
erle |
well, it used to be “documented” in the engine source code until it was no longer used for engine-internal purposes because light propagation was used instead |
| 17:26 |
MTDiscord |
<warr1024> To me, "air equivalent" means I can replace it with some other air equivalent and have it continue to behave as air. I use this for things that affect lighting, such as invisible light sources for dynamic light, or invisible shadows for particle clouds that block light. |
| 17:27 |
MTDiscord |
<warr1024> In principle I could (and maybe at some point should?) switch to using a group and just use the old flag to auto-fill heuristically, maybe, but the flag is what I'm using for now. |
| 17:28 |
erle |
IMO that seems like a pretty good case for documenting it instead of ripping it out |
| 17:28 |
MTDiscord |
<warr1024> You can't assume that airlike == air_equivalent at least because airlikes are used anywhere that the rendering for a node cannot be done using the mapblock mesh, e.g. when the node has a dynamic appearance or moves, and needs to be entity-rendered. |
| 17:29 |
MTDiscord |
<warr1024> Well, even if we ripped it out, we'd still have to document it, at least for a deprecation phase 😄 |
| 17:30 |
erle |
deprecating anything that has no clear replacement but is in use seems like a pretty pointless endeavour |
| 17:30 |
MTDiscord |
<warr1024> I'm okay with deprecating it, but please give me a heads up and a chance to migrate to the group-based thing 😅 |
| 17:30 |
erle |
Warr1024 what exactly would the group-based thing be? |
| 17:31 |
MTDiscord |
<grorp> What do people here think about this? https://github.com/minetest/minetest/commit/1a81267e886e374d65c34d275682457916f0fb16 |
| 17:31 |
MTDiscord |
<warr1024> I'll just make an air_equivalent type group instead of using a "primary" flag on the node def then. |
| 17:31 |
erle |
Warr1024 well but you'd also have to add that to :ignore and :air then ig |
| 17:31 |
erle |
i bet many people will forget about :ignore lol |
| 17:32 |
MTDiscord |
<warr1024> grorp: I'm generally not a fan of restricting things with an accessibility impact. Having a player stuck with either 1 or 2 when what they really want is 1.5 would be painful. Also, if a game provides a way-too-big replacement crosshair and somebody wants to scale it down to 0.25 on a small display, they'd be SOL. |
| 17:33 |
MTDiscord |
<warr1024> It'd be better if you could at least offer nearest-up-linear-down best-effort antialiasing, like the NNAA algorithm was supposed to offer for gui_scaling_filter. People who set a setting that gives them a blurry result will just have to accept the trade-off or change their setting. |
| 17:33 |
erle |
maybe there should just be a separate crosshair scaling option? |
| 17:33 |
erle |
warr1024 i think the problem here is that the ”setting” is their DPI |
| 17:34 |
erle |
then again, minetest is not exactly famous for respecting DPI settings well lol |
| 17:34 |
MTDiscord |
<warr1024> Heh, ideally, being able to fix the scaling of each individual GUI component would be nice, but at some point we may have to require that game/mod creators provide that rather than make the engine have to offer hundreds of knobs. |
| 17:35 |
erle |
well, as someone who likes pixel-perfect rendering i'd be pretty pissed if i had to stare at a blurry crosshair *without* being able to get rid of that |
| 17:35 |
erle |
but the 1.5 thing is valid. openttd actually does have an 1.5 scaling factor too i think. |
| 17:37 |
MTDiscord |
<warr1024> Ideally there would be some obvious way to get rid of the blur, e.g. just setting it to an integer yourself. I guess that depends on whether there's some DPI shenans mixed in with it, e.g. a multiplier that it's not obvious how to cancel out. |
| 17:39 |
erle |
well, the more i think about that proposal the more i think that ”dpi awareness” is probably the wrong way to fix it at least for png crosshairs. |
| 17:41 |
[MTMatrix] |
<Zughy> PR closed, I hope everyone is fine. That was supposed to be a silly PR to close one of the 1.1k issues we have, and to face scenarios like these push people away from contributing. sfan5 and wuzzy were both fine, it was basically screaming "supported by core dev", so I thought it was a safe bet; and yet this had to happen. I don't think this is a healthy way to do things |
| 17:43 |
[MTMatrix] |
<Zughy> problems should arise when the issue is opened, not when the solution (agreed by a core a dev and another member of the community + 2 approvals from other 2 core devs) is offered |
| 17:44 |
erle |
maybe the person offering the solution could have done the same as ROllerozxa or i did and did a zipgrep, asked warr1024 for their opinion or do “git log -p |grep air_equivalent |pager” |
| 17:45 |
MTDiscord |
<grorp> erle, Warr1024: Some kind of "DPI-awareness" is needed though, otherwise you have a tiny crosshair on Android. Hardcoding a bigger crosshair size on Android doesn't sound like a good idea to me. |
| 17:45 |
erle |
grorp i see |
| 17:45 |
[MTMatrix] |
<Zughy> as said before, I agree with Wuzzy: if something is undocumented and you're relying on it, it's not devs fault |
| 17:46 |
erle |
i don't care whose fault it is. i don't even care that you made this PR. i care about “does this introduce breakage and if so, is the breakage obviuosly and easy to fix” and the answers seem to be yes and no apparently. |
| 17:46 |
MTDiscord |
<warr1024> If it's deprecated NOW and removed in 5.8, that would be sufficient warning for me, I think. I don't think it would be too much work for me to migrate off of it. |
| 17:46 |
erle |
Warr1024 a deprecation needs an idea what to do instead though |
| 17:46 |
[MTMatrix] |
<Zughy> I'm not a big dev like you, people, but since I maintain a library too, if people start using functions in the code that I haven't exposed in the documentation, the fault is on them |
| 17:46 |
erle |
otherwise zughy is just going to deprecate everything that they don't think is needed |
| 17:46 |
ROllerozxa |
I mean I already made a comment on the issue when it first was opened that it was used by some packages on CDB, linking to the previous zipgrep result, I don't know how else I could have been more clear |
| 17:47 |
erle |
i think ROllerozxa was correct here and people just don't want to engage with “such a simple” change too much. |
| 17:47 |
MTDiscord |
<warr1024> Well, I know what to do instead. There are only a handful of engine things that supply air_equivalent, and I can just add the group to them. If mod content continues using the flag, then that's not necessarily a problem either, as the engine will simply not care about it and it becomes an "undocumented" feature that's NOT the engine's fault anymore. |
| 17:47 |
[MTMatrix] |
<Zughy> thanks erle with the passive-aggressive comments, I'm sure they'll help the discussion |
| 17:49 |
MTDiscord |
<warr1024> I dunno if it's a good idea to literally deprecate everything that a small group of people thinks is not needed, but it wouldn't be a bad idea to challenge existing assumptions and find out if things actually ARE being used. Especially stuff that's not hard to zipgrep on CDB. |
| 17:49 |
celeron55 |
the only actual problem here seems to be that the problems were hilighted properly only after it got to the PR phase instead of in the issue. if the PR was more than literally two lines i could understand the flamewar but now this all just seems silly |
| 17:50 |
erle |
celeron55 you see no problem with ROllerozxa literally saying “this is used” and everyone ignoring it? |
| 17:50 |
MTDiscord |
<warr1024> If retaining a feature smells arbitrary, then it would be nice to at least find out where we actually stand with it rather than just assuming that because it has existed in the past then somebody must have relied on it. |
| 17:50 |
erle |
yeah |
| 17:50 |
erle |
i mean i remember the TGA thing still. i don't want something like that again. |
| 17:51 |
MTDiscord |
<grorp> Warr1024: re NNAA: The crosshair is affected by gui_scaling_filter, btw. |
| 17:51 |
celeron55 |
erle: i think the issue as it is didn't give a go-ahead for making a PR |
| 17:51 |
MTDiscord |
<warr1024> All else considered, whether air_equivalent ends up being removed from the engine or not, I do plan on at least doing the "group thing" I mentioned earlier, since it makes it a lot easier for mods to specify behavior to the game without also colliding with other interpretations that other mods may have for flags inherited from elsewhere. If it does end up getting removed, it will make it a lot easier for me to handle that migration |
| 17:51 |
MTDiscord |
anyway. |
| 17:52 |
erle |
celeron55, my proposal would be to require zipgrep and a „what to do instead” suggestion for all deprecations, however small and insignificant they seem. |
| 17:52 |
erle |
otherwise this is going to happen again and again |
| 17:52 |
MTDiscord |
<warr1024> It's worth noting that zipgreps are not necessarily trivial to analyze. We were only lucky here because the name is quite distinctive. |
| 17:53 |
celeron55 |
i am not happy with the situation as-is though. if the field isn't removed, then it has to be documented |
| 17:53 |
erle |
Warr1024 that is true. for tga for example, no TGA files where on CDB, because it is almost exclusively used for dynamic textures. |
| 17:53 |
MTDiscord |
<warr1024> But yes, it would probably be good to have like a standard deprecation checklist of things to remember to check before proceeding. |
| 17:53 |
erle |
i want that checklist mostly because the problems seem to look the same |
| 17:53 |
sfan5 |
grorp: " Scale crosshair texture by integer-multiples only " sounds useful |
| 17:54 |
erle |
i mean ”ask the mod authors who use it most why they use it” could also be an item |
| 17:54 |
erle |
as far as i see, the current policy is “break some stuff, but announce it in the small-print months before and then blame the victims when their code breaks” |
| 17:54 |
ROllerozxa |
should that checklist be in the CONTRIBUTING.md perhaps? |
| 17:54 |
[MTMatrix] |
<Zughy> *some undocumented stuff |
| 17:54 |
MTDiscord |
<warr1024> Actually, it wouldn't be bad to mark something as deprecated at any time, i.e. tell people not to add new things relying on it. We can wait as long as we feel necessary before actually removing things. That would give us time to shake out people using it for things that can't be replaced. |
| 17:55 |
|
Desour joined #minetest-dev |
| 17:55 |
MTDiscord |
<warr1024> If we mark air_equivalent as deprecated right now in documentation, it would basically serve as a "white lie" because we're probably not ready to actually give a timeline for actual removal, but at least we can warn people not to make the problem worse. |
| 17:55 |
erle |
yeah, also it would be nice to have a “do not deprecate” list for stuff that comes up repeatedly |
| 17:56 |
[MTMatrix] |
<Zughy> You can't just deprecate it without offering a solution |
| 17:57 |
MTDiscord |
<warr1024> Yeah, actually, you can. You just say "don't use this. If you're using it, we're still looking for a solution, and if you have any ideas, please let us know." |
| 17:57 |
MTDiscord |
<warr1024> You can't actually set a deadline for removal without a solution, but you can sure as hell signal your intent to remove it without one. |
| 17:57 |
sfan5 |
unless someone defines what air_equivalent is supposed to mean the only solution is "we're removing this, if you used it please hardcode 'air' and 'ignore' or make up a group for your game" |
| 17:57 |
erle |
i am writing the thing with a ”do not deprecate” list by the way because i am pretty sure that “reasons why mods use TGA” and “reasons why stuff behaves exactly at it does at the map border” belongs on that list |
| 17:58 |
[MTMatrix] |
<Zughy> TGA will be removed eventually, it's also documented |
| 17:58 |
erle |
wait what why |
| 17:58 |
MTDiscord |
<warr1024> sfan5, I suspect that what air_equivalent is "supposed to" mean isn't actually definable at the engine level. It sounds like different content uses it for different stuff. |
| 17:58 |
erle |
zughy did you do that |
| 17:58 |
erle |
to annoy me |
| 17:58 |
erle |
surely you are joking |
| 17:59 |
[MTMatrix] |
<Zughy> sfan told me to |
| 17:59 |
[MTMatrix] |
<Zughy> I was only documenting file formats |
| 17:59 |
erle |
stop the cheap jokes at my expense. i'm not getting provoked into listing the reasons again. |
| 17:59 |
celeron55 |
if someone makes the PR to document air_equivalent as deprecated, i'm giving my +1 to that. but there are other options also that i'm giving my +1 to, i'm not going to dictate this |
| 18:00 |
erle |
zughy i don't like sfan5 but it is not nice to try to sow discord like that |
| 18:01 |
ROllerozxa |
Who said TGA is being removed??? |
| 18:01 |
MTDiscord |
<luatic> erle: it's not a hard "deprecation notice", but lua_api.md states: "Supported texture formats are PNG (.png), JPEG (.jpg), Bitmap (.bmp) and Targa (.tga). Since better alternatives exist, the latter two may be removed in the future." |
| 18:01 |
ROllerozxa |
this is not acceptable |
| 18:01 |
nrz |
this was said long time ago and never done, or rollbacked, for some reason |
| 18:01 |
erle |
ROllerozxa zughy said right now lol. and tried to pin it on sfan5 (who i believe is not that stupid to do that) |
| 18:01 |
[MTMatrix] |
<Zughy> ...I'm not provoking you https://github.com/minetest/minetest/pull/13711#discussion_r1282803255 |
| 18:01 |
erle |
oh |
| 18:02 |
erle |
> I don't want to ruin your simple PR with a big discussion but this has to be considered when documenting this for the first time. |
| 18:02 |
sfan5 |
not sure why the removal of tga is apparently controversial |
| 18:02 |
erle |
not this shit again |
| 18:02 |
ROllerozxa |
oh for fucks sake |
| 18:02 |
erle |
we already had this once |
| 18:02 |
[MTMatrix] |
<Zughy> lol |
| 18:02 |
rubenwardy |
please can we avoid triggering erle |
| 18:02 |
* celeron55 |
leaves to grab popcorn |
| 18:03 |
ROllerozxa |
please keep TGA |
| 18:04 |
MTDiscord |
<luatic> the stage is set, now the drama may commence! |
| 18:04 |
erle |
i hereby volunteer to maintain the TGA decoder code if that is any good. it's shorter than most mods that use it. |
| 18:04 |
sfan5 |
instead of having any kind of discussion now I suggest opening an issue with arguments to support it's non-removal |
| 18:04 |
erle |
we already HAD this |
| 18:04 |
MTDiscord |
<greenxenith> Cool, so don't have it again here |
| 18:04 |
MTDiscord |
<luatic> we've had one discussion, yes. what about second discussion? |
| 18:04 |
erle |
luatic lol |
| 18:05 |
[MTMatrix] |
<Zughy> sometimes I wish we could use this same energy to debate about, idk, 1 of the 305 bugs we have left open. But nope |
| 18:05 |
erle |
zughy i apologize (and take back the ”not that stupid” assertion, apparently i am stupid here for not believing you) |
| 18:05 |
MTDiscord |
<greenxenith> Put this nonsense in a github issue were bikeshedding belongs |
| 18:05 |
erle |
i think it is super fucking shitty to hide such a thing in a random documentation PR when it was clear that last time this was tried it was a bad idea and then ask for new arguments |
| 18:05 |
rubenwardy |
I suggest posting your tga rants here: https://rwdy.uk/2RFmM.png |
| 18:06 |
[MTMatrix] |
<Zughy> Minetest could sponsor it, in the end we received a €1000 donation two years ago |
| 18:07 |
erle |
sfan5 literally nothing changed since last time this was brought up except that it now breaks more mods than back then |
| 18:07 |
rubenwardy |
other options are tga.cool, tga-super.fans, tga.love |
| 18:07 |
sfan5 |
erle: put the arguments in an issue |
| 18:08 |
erle |
with what title? |
| 18:08 |
celeron55 |
the TGA non-deprecation issue is probably the best thing to do |
| 18:08 |
sfan5 |
I don't know? |
| 18:08 |
rubenwardy |
isn't the issue already here: #11613 |
| 18:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/11613 -- Re-add support for the TGA image file format |
| 18:08 |
[MTMatrix] |
<Zughy> (side note: issue bot doesn't work on Matrix) |
| 18:08 |
celeron55 |
well that one has a different subject |
| 18:08 |
[MTMatrix] |
<Zughy> proof |
| 18:08 |
[MTMatrix] |
<Zughy> https://matrix.org/_matrix/media/v1/download/matrix.org/VrJbJSRxYEtcqNBGKOHuZkmA |
| 18:09 |
rubenwardy |
most bots are coded to ignore messages from other bots (ie: service messages) |
| 18:09 |
[MTMatrix] |
<Zughy> that's pretty unpolite of them |
| 18:09 |
erle |
rubenwardy, it was not only the issue, it was also the PR that removed it. the suggestion back then was to use BMP instead (which to anyone familiar with file formats seems like a non-starter). |
| 18:09 |
sfan5 |
well I'd propose a new issue since that one was created in the context of a surprise removal without deprecation period |
| 18:09 |
rubenwardy |
yeah |
| 18:09 |
ROllerozxa |
erle: I suppose "undeprecate the TGA image format" would be a good title |
| 18:10 |
erle |
wait why can sfan5 just tell zughy to deprecate something without a technical justification but to undo that we need an issue? |
| 18:10 |
erle |
i mean i can open it |
| 18:11 |
erle |
but i don't see why this is acceptable given the last time sfan5 argued against it he was not exactly an expert on texture file formats |
| 18:11 |
MTDiscord |
<luatic> Zughy: It prevents infinite bot interaction loops. |
| 18:11 |
erle |
zughy IRC has an extra message type for “bots do not respond” actually to prevent bot loops |
| 18:12 |
sfan5 |
instead of complaining how unfair it is that coredevs can just do things while normal people have to open an issue you could better just open the issue |
| 18:12 |
ROllerozxa |
erle: open the issue please, I could open one myself but I think you have more precise knowledge about encoding TGA in comparison to PNG (in terms of speed and filesize) so I'd appreciate it if you could do that |
| 18:13 |
erle |
ROllerozxa i will eventually, but i just got a huge delivery of stuff from REWE, so i can not right now. |
| 18:14 |
|
Desour joined #minetest-dev |
| 18:14 |
ROllerozxa |
ohok |
| 18:15 |
erle |
and i don't think i can easily crib together a text that would convince people who don't want to read walls of text (you know who) |
| 18:15 |
erle |
anyway, off to putting stuff in the fridge |
| 18:23 |
MTDiscord |
<warr1024> I've almost only ever seen issues used for requesting changes, having a "commit to supporting format xyz for the foreseeable future" is a new use-case for issues I haven't seen before. If there are discussions that have already happened, have already reached conclusions, and we'd like to avoid rehashing them, that sounds like a good use... |
| 18:24 |
MTDiscord |
<warr1024> I actually maintain TODON'T lists for my larger or more popular projects that keep getting the same requests over and over and I get tired of having to rehash why. |
| 18:33 |
erle |
well in this case i don't have a good explanation for it, because the arguments were already had in the past |
| 18:34 |
erle |
sfan5 maybe you want to share your arguments *for* deprecation? |
| 18:34 |
erle |
(of something that is in use and has no good replacement) |
| 18:36 |
sfan5 |
it's in the documentation: "Since better alternatives exist, the latter two may be removed in the future." |
| 18:37 |
sfan5 |
that "no good replacement [exists]" is already a (currently unproven) claim by you |
| 18:37 |
sfan5 |
anything you want to elaborate on that should exactly go into the new issue and not here |
| 18:39 |
erle |
i will make the issue and try to be terse, but i already want to point out that the last time the vague ”better alternatives exist” thing was mentioned, it turned out to be a bunch of bollocks. |
| 18:39 |
erle |
so i would very much like to know *what* you have in mind, regardless of how it turns out |
| 18:41 |
sfan5 |
to elaborate on that: mods that have tga textures for some reason can easily convert theirs, mods that write tga at runtime can migrate to write_png |
| 18:41 |
erle |
oh, is the PNG writer not shit tier anymore? |
| 18:41 |
MTDiscord |
<warr1024> If the claims where bullocks then there should be counterclaims that explain how, which would be good to see in the issue. |
| 18:42 |
MTDiscord |
<warr1024> If the PNG writer really is shit tier then we should really consider fixing that entirely independently of whether we deprecate or continue support for TGA. |
| 18:43 |
erle |
Warr1024 i already figured out that you can't meaningfully improve it, for dynamic texture generation tga.z (a proposal i made in the past) beats every png optimizer i have run even. |
| 18:43 |
erle |
anyway, later |
| 18:44 |
sfan5 |
schrödingers png encoder is simultanously shit tier and also can't be meaningfully improved |
| 18:45 |
|
appguru joined #minetest-dev |
| 18:47 |
erle |
sfan5 if you are really interested in details and benchmarks and don't want to wait for the issue, i have a wall of text for you https://git.minetest.land/erlehmann/unicode_text/src/branch/main/README.rst#user-content-png-is-a-better-format-why-not-write-png-files |
| 18:49 |
erle |
TL;DR: no improvement for the PNG decoder can beat “tga.z” (a trivial engine enhancement) for filesize or encoding speed for dynamic textures |
| 18:50 |
sfan5 |
we're not adding another obscure format |
| 18:50 |
erle |
so if you wanted to spend any time on getting bitmaps rendered faster or smaller, the png encoder is simply the wrong part of the code |
| 18:50 |
erle |
DEFLATE in transit is a pretty old technique and can be done entirely transparent |
| 18:50 |
ROllerozxa |
please don't harp on about tga.z, it's not helping our case |
| 18:50 |
|
v-rob joined #minetest-dev |
| 18:50 |
[MTMatrix] |
<Zughy> the only format I need is .gltf |
| 18:51 |
rubenwardy |
100% |
| 18:51 |
rubenwardy |
well, +new |
| 18:51 |
erle |
well, it's not relevant to the ”deprecate or not” question, but it is relevant to “is the PNG encoder salvage-able in principle” and for dynamic textures, nope |
| 18:51 |
ROllerozxa |
erle: thinking in the context for your text encoder where it renders text to a texture, a RLE compressed TGA image will be smaller than an equivalent image in PNG format encoded with encode_png right? |
| 18:51 |
erle |
like, you can spend time on it and will always be worse than adding a simple call to deflate |
| 18:51 |
[MTMatrix] |
<Zughy> any news from JosiahWI? PR looks dead :( |
| 18:52 |
erle |
ROllerozxa i did not actually test any of that because the PNG encoder does not actually specify any format except full RGBA and i render to grayscale by default |
| 18:52 |
erle |
it does not matter |
| 18:54 |
erle |
look, i think when people who have no understanding of an issue have the capability to deprecate it without feelings i can't really “win” here. |
| 18:54 |
ROllerozxa |
no it does matter, because the PNG encoder does not support indexed images so the filesizes will be significantly larger than an equivalent TGA made with your encoder |
| 18:54 |
erle |
depends on the filesize probably |
| 18:54 |
erle |
i only looked at the checkerboard example and figured out that it's like 20 times the size it should be, but for dynamic textures you also keep in mind that you want them *fast* |
| 18:55 |
erle |
and few things are faster than dumping a header and then a single-pass pixel thing on disk |
| 18:56 |
erle |
anyway, i already know what would be required for a “proper” deprecation. duplicating the entire TGA decoder from the engine in lua, just so you can write RGBA PNGs without prefilter :( |
| 18:56 |
erle |
i'm not doing that |
| 18:57 |
sfan5 |
I will say in advance that 1. "write_png produces worse results than my tga encoder" is valid within reason, not if it saves you 1 KB on a 50 KB file 2. that is more of an argument for improving write_png than for keeping tga |
| 18:57 |
erle |
RIP all those maps from mcl_maps and xmaps! |
| 18:59 |
erle |
sfan5 file size is a red herring, i know that. but what's actually the drawback of keeping support for something that is well understood, tiny and has been used for years? |
| 18:59 |
erle |
i mean it's not like the code will suddenly require lots of changes |
| 19:01 |
[MTMatrix] |
<Zughy> is the fact I've been making games for years and I've never head of .TGA before Minetest (as well as .b3d and .x) a valid reason to consider it the contrary of "well understood"? |
| 19:02 |
[MTMatrix] |
<Zughy> *heard |
| 19:02 |
Krock |
I'd also consider it as a niche format |
| 19:03 |
erle |
if you never heard of it, you never did anything with VTF files (it's a steam thing) i assume. or with quake. or homeworld. |
| 19:03 |
sfan5 |
as with everything code needs maintenance, or if we switch to a new library for reading images we need to take tga into account, or if the code has a security issue it needs attention |
| 19:03 |
erle |
sfan5 i already volunteered for maintaining it |
| 19:04 |
erle |
just for perspective, on my computer lib/irrlichtmt/source/Irrlicht/CImageLoaderTGA.cpp is 238 lines |
| 19:09 |
sfan5 |
I'm not saying it's important or due to happen soon |
| 19:18 |
erle |
i just wanted to know if there was some maintenance burden that i could address so it no longer exists (as long as it is small enough) |
| 19:30 |
[MTMatrix] |
<lebruhgamer> TGA image file is used quite extensively in the animation and video industry because of the easiness of processing .. if you "have not heard" about it, it just meant you're not in the industry where it's mainly used |
| 19:33 |
|
olliy joined #minetest-dev |
| 19:38 |
[MTMatrix] |
<lebruhgamer> in fact it's also used for overlay purpose in broadcasting system used in live TV production, as it's very fast to render |
| 19:39 |
sfan5 |
that sounds implausible. once decoded every image format should be equal. |
| 19:42 |
[MTMatrix] |
<lebruhgamer> it's used in processing side, not on resulting side -- like the output will just be a TS |
| 19:42 |
erle |
lebruhgamer hmmm, is this basically the same reasoning why TGA in minetest is only used for dynamic textures and not much else? |
| 19:43 |
erle |
btw, can you query me? i have a technical question about TGA i never found an answer to. |
| 19:44 |
sfan5 |
anyway citations for why tga is not a niche format would also belong in the to-be-created issue |
| 19:44 |
[MTMatrix] |
<lebruhgamer> for reference on what TS is: https://en.wikipedia.org/wiki/MPEG_transport_stream |
| 19:45 |
[MTMatrix] |
<lebruhgamer> it probably is, yeah |
| 19:46 |
[MTMatrix] |
<lebruhgamer> (replying to erle re: hmmm, is this basically [...]) |
| 19:46 |
[MTMatrix] |
<lebruhgamer> (as it seemed like the reply is not reflected on IRC side) |
| 19:47 |
erle |
lebruhgamer, nope, you are not querying me right now. i'll just ask here then. people from 3D modeling, game development and (maybe movie?) space often claim TGA has better alpha channel support than PNG. what do they mean with that? |
| 19:47 |
erle |
i mean both support RGBA colors |
| 19:49 |
|
Desour joined #minetest-dev |
| 19:49 |
[MTMatrix] |
<lebruhgamer> that kinda asked a lot but there's people answering it already on reddit https://www.reddit.com/r/gamedev/comments/p00xwy/why_would_you_use_tga_files_for_texturing_instead/ |
| 19:49 |
[MTMatrix] |
<lebruhgamer> tldr; The difference between TGA and PNG is that TGA uses a fourth channel aside the usual RGB that contains a mask for the alpha values. While PNG uses the "missing" information inside the RGB to store the alpha. |
| 19:54 |
erle |
lebruhgamer i simply do not understand what this means in practical terms for blending etc. |
| 19:57 |
MTDiscord |
<warr1024> Are you talking about premultiplied alpha vs non-premultiplied? |
| 20:13 |
[MTMatrix] |
<lebruhgamer> TGA has RGBA channels. PNG has RGBA but the alpha channel is either stored as a separate channel (like TGA) or as a transparency amount. With extensive use of PNG compressions and "optimizer" that try to lower PNG file size, it actually crunch down the channel that the alpha will no longer be its own channel and no longer editable independently from RGB. TGA don't have that problem as it always had separate alpha chann |
| 20:14 |
[MTMatrix] |
<lebruhgamer> ..channel while still being small size for the usual use case (texturing, overlaying, etc) |
| 20:15 |
MTDiscord |
<luatic> lebruhgamer: sorry but that's misinformation |
| 20:15 |
[MTMatrix] |
<lebruhgamer> how so? |
| 20:15 |
sfan5 |
the terminology I know has planar and packed formats, can't really make sense of "it has a separate channel" |
| 20:16 |
MTDiscord |
<luatic> PNG alpha is not necessarily premultiplied. PNG can map a certain RGB color to alpha 0, but that doesn't have to be used. PNG can store arbitrary RGB + alpha 0 just like TGA. Crushers not respecting that is a crusher issue, not a PNG issue, and I definitely know crushers which keep the RGB even if alpha = 0. |
| 20:17 |
MTDiscord |
<luatic> lebruhgamer: In particular, the "While PNG uses the 'missing' information inside the RGB to store the alpha" quote is wrong. Again, PNG can do this, but it doesn't have to. |
| 20:18 |
erle |
i am beginning to think this part of the lore is just a photoshop bug or so |
| 20:18 |
MTDiscord |
<luatic> yeah |
| 20:18 |
MTDiscord |
<luatic> it's definitely not a PNG issue per se |
| 20:19 |
|
tekakutl` joined #minetest-dev |
| 20:40 |
|
v-rob joined #minetest-dev |
| 21:02 |
|
tekakutli joined #minetest-dev |
| 21:41 |
|
olliy1or joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:24 |
|
jonadab joined #minetest-dev |
| 23:52 |
|
v-rob joined #minetest-dev |
