Time Nick Message 08:03 [MTMatrix] function on_place convert's callable function to cycle? How make on_use same behavior? 11:18 MTDiscord localhost: sorry, but i can't make sense of your message 11:31 [MTMatrix] Okay, how make "full_punch_interval" when player activates on_place event? 11:32 [MTMatrix] This is for #minetest, please ask there. It's not the first time someone tells you that 11:33 [MTMatrix] eh... sorry, just here more faster answer :D 16:30 MTDiscord 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 i was about to ask the same 16:36 MTDiscord :) 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 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] As you wish but I'm not gonna make the PR 16:46 [MTMatrix] 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] 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 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: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] 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] 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 erle because i think i might see things you would ignore, that's all. 16:57 MTDiscord 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 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 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 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 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 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 erle: yes, I did, of course. 17:11 MTDiscord 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] Lol 17:21 [MTMatrix] What a fucking joke 17:21 erle what's the joke here? 17:21 erle no breakage, no problems 17:21 [MTMatrix] You're the problem 17:22 erle oh my 17:24 ROllerozxa ouch 17:25 MTDiscord NodeCore uses air_equivalent pretty extensively. I wasn't aware it was undocumented; it seemed pretty self-documenting to me. 17:26 MTDiscord "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 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 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 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 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 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 What do people here think about this? https://github.com/minetest/minetest/commit/1a81267e886e374d65c34d275682457916f0fb16 17:31 MTDiscord 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 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 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 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 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] 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] 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 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] 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 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] 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 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] thanks erle with the passive-aggressive comments, I'm sure they'll help the discussion 17:49 MTDiscord 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 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 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 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 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 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] *some undocumented stuff 17:54 MTDiscord 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 MTDiscord 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] You can't just deprecate it without offering a solution 17:57 MTDiscord 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 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] TGA will be removed eventually, it's also documented 17:58 erle wait what why 17:58 MTDiscord 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] sfan told me to 17:59 [MTMatrix] 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 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] ...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] 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 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 Cool, so don't have it again here 18:04 MTDiscord we've had one discussion, yes. what about second discussion? 18:04 erle luatic lol 18:05 [MTMatrix] 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 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] 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] (side note: issue bot doesn't work on Matrix) 18:08 celeron55 well that one has a different subject 18:08 [MTMatrix] proof 18:08 [MTMatrix] 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] 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 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 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 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 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 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 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: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 [MTMatrix] 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] 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] 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] *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] 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:38 [MTMatrix] 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] 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] for reference on what TS is: https://en.wikipedia.org/wiki/MPEG_transport_stream 19:45 [MTMatrix] it probably is, yeah 19:46 [MTMatrix] (replying to erle re: hmmm, is this basically [...]) 19:46 [MTMatrix] (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 [MTMatrix] 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] 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 Are you talking about premultiplied alpha vs non-premultiplied? 20:13 [MTMatrix] 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] ..channel while still being small size for the usual use case (texturing, overlaying, etc) 20:15 MTDiscord lebruhgamer: sorry but that's misinformation 20:15 [MTMatrix] 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 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 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 yeah 20:18 MTDiscord it's definitely not a PNG issue per se