| Time |
Nick |
Message |
| 00:00 |
MTDiscord |
<mistere_123> lagash, please note that I re-implemented the game as a mod a couple years after the game was published |
| 00:00 |
MTDiscord |
<mistere_123> because I want it on my minigame server |
| 00:01 |
MTDiscord |
<mistere_123> if you design your game well reimplementation is easy |
| 00:14 |
|
fluxionary_ joined #minetest |
| 03:00 |
|
CRISPR joined #minetest |
| 03:23 |
|
CRISPR joined #minetest |
| 03:49 |
|
fling joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:21 |
|
SFENCE joined #minetest |
| 05:59 |
|
whosit joined #minetest |
| 06:17 |
|
YuGiOhJCJ joined #minetest |
| 06:24 |
|
SFENCE joined #minetest |
| 06:44 |
|
Verticen joined #minetest |
| 08:03 |
|
Sharpman joined #minetest |
| 08:15 |
|
fling joined #minetest |
| 09:06 |
|
MacroFaxSax joined #minetest |
| 09:22 |
|
Warr1024 joined #minetest |
| 09:41 |
|
tarsovbak joined #minetest |
| 09:47 |
|
Warr1024 joined #minetest |
| 10:26 |
|
jaca122 joined #minetest |
| 10:41 |
|
CRISPR joined #minetest |
| 10:42 |
|
gregon joined #minetest |
| 11:49 |
|
ireallyhateirc joined #minetest |
| 12:23 |
MinetestBot |
[git] SmallJoker -> minetest/minetest: Revert "Fix collisions with long dtime, in particular with bouncing" … 4bb9c8c https://github.com/minetest/minetest/commit/4bb9c8c61b36b16720ead745d920d4a6ea5afe0e (2024-11-10T12:20:30Z) |
| 12:23 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Re-fix CAO mesh lighting with shaders disabled 122b2d7 https://github.com/minetest/minetest/commit/122b2d70d94bdd070bcb840e89d3b936f376f5ac (2024-11-10T12:21:19Z) |
| 12:25 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Update credits for 5.10.0 7557a28 https://github.com/minetest/minetest/commit/7557a287e53a796e61c2287fda9c72a5ac1f32c6 (2024-11-10T12:23:16Z) |
| 12:34 |
|
yezgromafic joined #minetest |
| 13:05 |
|
Desour joined #minetest |
| 13:32 |
|
fling joined #minetest |
| 13:32 |
|
YuGiOhJCJ joined #minetest |
| 14:03 |
|
TheSilentLink joined #minetest |
| 14:33 |
|
cx384 joined #minetest |
| 14:50 |
|
CRISPR joined #minetest |
| 15:00 |
|
CRISPR joined #minetest |
| 15:05 |
|
vampirefrog joined #minetest |
| 15:49 |
|
silverwolf73828 joined #minetest |
| 16:00 |
|
Talkless joined #minetest |
| 16:09 |
|
gregon joined #minetest |
| 16:10 |
|
Lunatrius joined #minetest |
| 16:16 |
|
erle_mobile joined #minetest |
| 16:17 |
erle_mobile |
luatic, i am impressed and delighted by you figuring it out https://github.com/minetest/minetest/pull/15402/ |
| 16:18 |
erle_mobile |
if this goes in the release, i'd be very happy. if it does not … how could i detect in a mod/game if servers and (WAY more important) clients have a version that fucks up the texture channels? |
| 16:19 |
erle_mobile |
on a server it might not matter too much, but i'd probably want to send a message to a client to either down- or up-grade (once it is merged) for such a serious regression. |
| 16:21 |
erle_mobile |
(i am looking at the logs, so feel free to respond once i quit) |
| 16:22 |
erle_mobile |
luatic alternatively i'd take a lesson from you and just kick clients that do not conform lol |
| 16:23 |
erle_mobile |
(i remember a patch from you that just handled the old dynamic media by kicking players … because otherwise the code might stall forever, right?) |
| 16:27 |
MTDiscord |
<luatic> erle_mobile: iirc the point about kicking players was that i wanted them to rejoin (or to update their minetest) to get the new media that way :P |
| 16:27 |
erle_mobile |
oh |
| 16:27 |
sfan5 |
it will not go in the release and you will be able to check the protocol version |
| 16:28 |
erle_mobile |
well it is a regression that i found in the rc and it has a fix, but i don't think anything i do is going to change anything when people tell me that |
| 16:31 |
erle_mobile |
so protocol version = client version? |
| 16:33 |
specing |
erle on mobile? What happened, firefox ate all your T60's RAM? |
| 16:33 |
erle_mobile |
at this point i want to point out that the changelog is incomplete |
| 16:33 |
erle_mobile |
specing travelign |
| 16:33 |
erle_mobile |
> (basic) shaders will eventually become a requirement. A warning is shown if they are disabled. |
| 16:33 |
specing |
anyone wanna pitch in to buy erle a newer ancient thinkpad?? |
| 16:33 |
erle_mobile |
“shaders are a requirement for the main menu, the game will crash with default settings if shaders are activated” |
| 16:34 |
erle_mobile |
“edit minetest.conf to start it regardless” |
| 16:35 |
erle_mobile |
(i want to point out that this was changed without a deprecation notice, but i am already aware that deprecation periods only ever mean something when you want them to mean something) |
| 16:36 |
erle_mobile |
“will crash […] if your hardware does not support opengl 2.x” |
| 16:36 |
sfan5 |
deprecation periods only apply to the API but nice try |
| 16:38 |
[ |
why would you make shaders a requirement? shaders are slow |
| 16:38 |
erle_mobile |
[ on your hardware |
| 16:39 |
erle_mobile |
you evidently have way worse hardware than the devs |
| 16:39 |
erle_mobile |
(like me) |
| 16:40 |
[ |
35 FPS with shaders compared to 41 FPS without shaders displaying exactly the same thing |
| 16:42 |
erle_mobile |
haha, i have <16 fps with shaders (unplayable) and >=30 fps without on the best x86 hardware i own |
| 16:42 |
erle_mobile |
[ face it, it literally does not matter for people who have gamer GPUs |
| 16:43 |
sfan5 |
it's funny how you keep equating (decent) shader support with gaming hardware, because it's not |
| 16:44 |
erle_mobile |
anyway, you can take “The priority is fixing the issues, performance, and general correctness.” out of the mission statement by now. |
| 16:44 |
specing |
sfan5: GL version is hardware API |
| 16:44 |
sfan5 |
it's not incorrect. you have just fallen out of the target audience. |
| 16:46 |
|
SFENCE joined #minetest |
| 16:46 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Work around Intel driver bug on Win 8.1 and older 8b27340 https://github.com/minetest/minetest/commit/8b27340b2eb30cd4efdbf50803af8b03170b22bd (2024-11-10T16:44:45Z) |
| 16:47 |
|
SFENCE_ joined #minetest |
| 16:47 |
erle_mobile |
target audience true is true |
| 16:47 |
erle_mobile |
“general correctness” thing is evidently not important if “color channels are messed up in the rc, and a fix exists, but it will not be merged” is true. |
| 16:48 |
sfan5 |
that just means dev's priorities are not the same as yours |
| 16:48 |
erle_mobile |
yes, which is why i say the mission statement should be changed |
| 16:49 |
sfan5 |
and add ", as decided by the development team."? |
| 16:49 |
Desour |
new mission statement: always please erle, and make them our dictator |
| 16:49 |
|
Lunatrius joined #minetest |
| 16:49 |
erle_mobile |
actually, yes. it's a long-standing observation that at least some devs are much more likely to work on e.g. netcode or fancy effects than on correctness |
| 16:49 |
erle_mobile |
or performance |
| 16:50 |
sfan5 |
that's pointless because it's implied |
| 16:50 |
erle_mobile |
and that both correctness and performance fall aside in refactorings |
| 16:50 |
erle_mobile |
(which is not true for A LOT of other projects, that e.g. reject refactorings or revert stuff without discussions if it causes regressions not previously agreed upon) |
| 16:52 |
erle_mobile |
well, if you say it's pointless, it's pointless to try and convince you. i remember the discussion about liskov substitutability, some people think a lot of stuff is implied, others don't. |
| 16:52 |
erle_mobile |
i think explicit is better than implicit, but that's something else |
| 16:53 |
erle_mobile |
regarding technical stuff: if i make a client where the rendering bug is fixed, how do i detect that server-side? |
| 16:53 |
erle_mobile |
do i just change the protocol number? |
| 16:53 |
erle_mobile |
or anything else? |
| 16:53 |
erle_mobile |
like, how is the protocol thing fork-friendly? |
| 16:53 |
sfan5 |
it's not and will never be |
| 16:54 |
|
Trifton joined #minetest |
| 16:54 |
erle_mobile |
so is there another mechanism i am not aware of, like a feature table for clients or so? |
| 16:54 |
sfan5 |
no |
| 16:54 |
erle_mobile |
so when is the next release after 5.10? |
| 16:54 |
erle_mobile |
(broadly?) |
| 16:55 |
sfan5 |
Feburary 2025 |
| 16:58 |
erle_mobile |
btw, when you do further 2d filtering changes in the future, try to test with unifont again. i figured out that all the other fonts i tried only look slightly blurry (difficult to notice on hidpi display), but unifont was the only one that generated really bad artifacts, probably because some glyphs go right to the edge. |
| 17:00 |
erle_mobile |
will the fix go in the next version then? |
| 17:00 |
sfan5 |
likely |
| 17:01 |
erle_mobile |
so what kind of regression that is found in an rc is fixed? does this boil down to “whatever the devs care about”? and why is there not another rc? |
| 17:01 |
erle_mobile |
the way i know it, people keep releasing rcs until one is declared a release |
| 17:02 |
erle_mobile |
and fix all regressions that are found |
| 17:02 |
erle_mobile |
but obviously you are not doing that, so what was the purpose of it? |
| 17:02 |
sfan5 |
to fix regressions we care about |
| 17:02 |
sfan5 |
I think your tga thing isn't even recent, several major releases old even |
| 17:03 |
cheapie |
I think it's also used by... one mod? Two if you count the test nodes? |
| 17:03 |
erle_mobile |
see that's *exactly* why i offered to maintain that part of the engine none of you care about (this was generally not responded to) |
| 17:04 |
sfan5 |
PRs are welcome and as you can see from the previous fix that has worked just fine, but it's still at our descretion how to prioritize things |
| 17:04 |
erle_mobile |
i know. i just wanted to know if you had *some* principles i can appeal to and evidently i can not. |
| 17:05 |
erle_mobile |
“not important enough” is not something that can be discussed away |
| 17:05 |
sfan5 |
yes it can, cheapie just gave an example of why we did not prioritize it |
| 17:06 |
cheapie |
AFAIK the one mod that uses it is so it can generate its own textures, which it really should be using the PNG encoder for anyway. |
| 17:06 |
erle_mobile |
btw, i think a much better way than making the main menu crash on old hardware would be to simply not show the clouds when no shaders. |
| 17:06 |
erle_mobile |
cheapie not this shit again |
| 17:06 |
sfan5 |
but personally I know from previous discussions we will not ever get to a consensus |
| 17:09 |
|
Trifton joined #minetest |
| 17:11 |
|
Trifton joined #minetest |
| 17:19 |
erle_mobile |
cheapie FYI the original reason why tga_encoder exists was mcl_maps (in mineclone2/mineclonia/mineclone5), in which it is used to generate in-game maps that are stored on each server, so they can not easily be upgraded. making these items takes a lot of-ingame time, they are a top-down snap-shot view of a 128×128 area. if you end up generating |
| 17:19 |
erle_mobile |
textures there are various reasons why you might want to use it, that come down mainly to: compat with minetest pre-5.5 (this mattered more in the past than now obv.), precise control over color format and features like colormap, filesize (depending on texture size), wanting textures that are easier to debug/edit. that last thing is the most |
| 17:19 |
erle_mobile |
important to me. |
| 17:21 |
erle_mobile |
if minetest.encode_png() had a similar API, i'd be in favor of it, but given the API it currently has and the general “this is one step better than the simplest thing that works” vibe i got from the code, i doubt it will have stuff like precise control over PNG features in a similar manner, ever. someone would need to care about that. |
| 17:21 |
erle_mobile |
and the tiny group of people who do is using something else, so … |
| 17:23 |
cheapie |
You can write a PNG file from the output of core.encode_png() AFAIK, conversion is just a case of using some TGA decoder to get the pixel data back and then feeding it to the encoder, so the only bit I can really see being different there is "precise control over color format and features like colormap" and I'm not really sure why this matters. |
| 17:23 |
erle_mobile |
see, this is why i wrote “not this shit again“ |
| 17:24 |
erle_mobile |
i don't have time for this right now. try to write a mod that uses a colormap or one that needs precise control about what textures it writes to load them later and argue then. |
| 17:25 |
|
Blockhead256 joined #minetest |
| 17:25 |
Blockhead256 |
ROllerozxa: would you be interested in adding some settings menus to your dynamic shadows mod? |
| 17:26 |
Blockhead256 |
since (as I just realised) it was moved to server-lua-side instead of client https://forum.luanti.org/viewtopic.php?p=440488&sid=d63cc839e55f5b392b5d324b8f6fad78#p440488 |
| 17:26 |
Blockhead256 |
or if I were to send a PR, would you merge it? |
| 17:27 |
erle_mobile |
cheapie if you do not care about the things i wrote, then you are, evidently, not the target group. not in a “i do not wish to support your use case” way, but in a “i have spent a lot of time to arrive at a solution that fits my (and some other people's) use cases, and for *some* reason everyone arguing against it has neither that same use |
| 17:27 |
erle_mobile |
cases nor a better solution at hand”. |
| 17:28 |
cheapie |
It sounds to me like the use case is "save a 128x128 image to show to the user later" - if it's more complex than that then I must be missing something here. |
| 17:28 |
erle_mobile |
yes |
| 17:30 |
Blockhead256 |
ROlleroxza: also I have no idea how you can send forum reports |
| 17:30 |
ROllerozxa |
Blockhead256: I must have missed something, what new shadow knobs have been added to the API? There's already a setting for shadow strength and the sibling mod volumetric_lighting can do the same for that graphical effect |
| 17:30 |
erle_mobile |
cheapie there are a bunch of topics where this tends to happen in software btw. – i see this often when people argue about build systems or font rendering or whatever is currently trending on hacker news that *looks* like it has a simple and obvious solution. |
| 17:31 |
ROllerozxa |
Blockhead256: The only thing that's broken about the report system is the form URL, if you fix it with inspect element then you can fix it and properly submit the form |
| 17:31 |
ROllerozxa |
one could make a userscript to do it but I have not done that yet |
| 17:32 |
cheapie |
Quite often it happens when there's some additional requirement imposed on the software that wasn't mentioned or wasn't obvious. I'm still waiting to find out what that is in this case. |
| 17:32 |
ROllerozxa |
duplicate /app.php/app.php/ or something iirc |
| 17:34 |
ROllerozxa |
it should really be fixed at the source but I like to be chaotic and report spam posts with it anyways 8) |
| 17:35 |
ROllerozxa |
hmm okay I see, it's about the bloom settings |
| 17:35 |
ROllerozxa |
(the forum link you sent just began loading for me haha) |
| 17:36 |
MTDiscord |
<theidealist> “ strikes again |
| 17:37 |
ROllerozxa |
previously I have done separate mods for each effect (shadows, saturation, volumetric lighting) but with each new thing that gets added I feel like it's unmaintainable to have it all in separate mods when you'd probably just want one mod that "gives you all the cool effects and stuff" (let's call it optifine hehe) |
| 17:37 |
ROllerozxa |
but I don't know. maybe I'll make a new mod for bloom settings but it might be getting a bit ridiculous at this point |
| 17:38 |
cheapie |
At this point I wish the engine just had an "I don't care if the game doesn't say it looks good, let me use X" setting for each of these. |
| 17:38 |
MTDiscord |
<theidealist> optifinetest |
| 17:38 |
erle_mobile |
cheapie for other “this looks obvious, but it might not be”, just look at every “i replaced all zlib code with zstd and it got worse” bug report, e.g. https://github.com/facebook/zstd/issues/2832 – this is absolutely normal. |
| 17:38 |
erle_mobile |
(generally, zstd is better, but in some scenarios it is not … if you hold it wrong, it is also not better obv.) |
| 17:39 |
cheapie |
Even uncompressed a 128*128 24bpp image is... what, 50kB? |
| 17:40 |
cheapie |
I guess it might be problematic if you're hosting a server over dialup (....OK, now I want to try that) |
| 17:41 |
erle_mobile |
ask me about this another time *once you have a use case* |
| 17:42 |
cheapie |
A use case for what, the PNG encoder? digiscreen has been using that for some time now, works great |
| 17:43 |
erle_mobile |
no, a use case for stuff like colormaps of various color formats, or maybe you think “i want to update this one pixel in this image, without re-encoding the entire thing” |
| 17:43 |
cheapie |
Yes, I'm still waiting to hear what your use cases are for these, as I can't think of any |
| 17:43 |
erle_mobile |
i am lucky, the xmaps code uses colormaps, but no alpha channel |
| 17:44 |
erle_mobile |
(so the mod is not broken by the regression) |
| 17:49 |
Blockhead256 |
@theidealist: *optifineuanti |
| 17:49 |
MinetestBot |
[git] Methro -> minetest/minetest: Translated using Weblate (Spanish) 62bee9f https://github.com/minetest/minetest/commit/62bee9f502aeca59daa960b16873341450b0b1ff (2024-11-10T17:15:44Z) |
| 17:49 |
MinetestBot |
[git] fran-carro hotmail.es -> minetest/minetest: Translated using Weblate (Spanish) 31c50c4 https://github.com/minetest/minetest/commit/31c50c470c9e39b7854c101db2152618476e0fa5 (2024-11-10T17:15:44Z) |
| 17:49 |
MinetestBot |
[git] Methro -> minetest/minetest: Translated using Weblate (Spanish) 0c61461 https://github.com/minetest/minetest/commit/0c61461b07d128a8723bd9ba56b42ef3b82fba8d (2024-11-10T17:15:44Z) |
| 17:49 |
MinetestBot |
[git] fran-carrohotmail.es -> minetest/minetest: Translated using Weblate (Spanish) aaf4877 https://github.com/minetest/minetest/commit/aaf487773093fcc5a5c763273591ff4774348d5a (2024-11-10T17:15:44Z) |
| 17:49 |
MinetestBot |
[git] (16 newer commits not shown) |
| 17:50 |
specing |
does Luanti support gimp .xcfs? |
| 17:50 |
erle_mobile |
cheapie please go read the code of some of the mods i wrote that generate bitmaps. i think it is much easier to understand that way why someone would want it. but as i said, it if YOU do not want it, you are simply not the target group. |
| 17:50 |
Blockhead256 |
accepted formats docs: https://github.com/minetest/minetest/blob/master/doc/lua_api.md#textures-sounds-media-models-locale |
| 17:51 |
sfan5 |
specing: no |
| 17:51 |
specing |
sfan5: sucks, pleasefix |
| 17:51 |
specing |
erle_mobile:^ |
| 17:51 |
erle_mobile |
? |
| 17:51 |
specing |
erle_mobile: add xcf support pls |
| 17:51 |
erle_mobile |
specing why? |
| 17:52 |
Blockhead256 |
why? because you're too lazy to export? |
| 17:52 |
erle_mobile |
specing also how much are you paying? |
| 17:52 |
specing |
Blockhead256: :P |
| 17:52 |
specing |
(no, Im making fun of erle_mobile's TGA arguing) |
| 17:52 |
|
grorp joined #minetest |
| 17:52 |
Desour |
cheapie: btw., would you like to post https://irc.minetest.net/minetest/2024-11-07#i_6214928 in the "post your videos" forum topic? I really enjoyed it! |
| 17:53 |
Blockhead256 |
ROllerozxa: thanks for considering it. Yes, so many options, so little end-user choice! |
| 17:53 |
Blockhead256 |
It's just not Minetest! |
| 17:53 |
cheapie |
Desour: There's a topic for that (on the five minutes per week the forum is up)? |
| 17:53 |
Desour |
yes! |
| 17:54 |
Desour |
and I wanted to give you a link to it, but the forum slowness is hindering me |
| 17:54 |
sfan5 |
specing: irrlicht actually used to support .psd in some form |
| 17:54 |
Blockhead256 |
firefox history tells me the videos thread is https://forum.luanti.org/viewtopic.php?t=8499&view=unread#unread |
| 17:54 |
cheapie |
Maybe I should put https://www.youtube.com/watch?v=oKm2epe0AzU there, then |
| 17:54 |
erle_mobile |
specing google CImageLoaderXCF and bribe both the author and the dev team with enough monies |
| 17:55 |
erle_mobile |
why is BMP still there btw given i attempted to the best of my ability to prove that it was not used historically? |
| 17:55 |
Desour |
finally: https://forum.minetest.net/viewtopic.php?t=8499&start=1125 |
| 17:56 |
Desour |
cheapie: yes, post all of them! :D |
| 17:56 |
grorp |
Blockhead25, cheapie: for shadows that problem was solved by adding a "shadow strength gamma" setting that's applied on top of the game-specified value iirc |
| 17:56 |
cheapie |
Or https://www.youtube.com/watch?v=3feqBJBonv4 but I don't think anyone really wants to watch an 83-minute video on one mod |
| 17:56 |
grorp |
perhaps one could do a similar thing for bloom |
| 17:56 |
sfan5 |
erle_mobile: #15413 |
| 17:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/15413 -- Remove BMP support |
| 17:56 |
erle_mobile |
grorp did you notice that the texture filtering thing fixed the font issues? |
| 17:56 |
grorp |
but in general fully server-controlled is at least preferable over fully client-controlled |
| 17:56 |
erle_mobile |
sfan5 thx |
| 17:56 |
Blockhead256 |
wow 1h23m of pure unadultered elevators? I'd expect to have to pay for that! |
| 17:58 |
Desour |
cheapie: it's nice ASMR |
| 17:58 |
Blockhead256 |
grorp: It's just kind of annoying shoving all of it into Lua and basically pushing it onto mod authors to give people the "DIY custom graphics" capabilities when it used to come standard. |
| 17:58 |
cheapie |
It was inspired by this video from The Other Game In Which You Mine And Craft™ https://www.youtube.com/watch?v=jSKjYJnBQkI |
| 17:58 |
Blockhead256 |
But understandable if you lean heavily into the "engine" mindset |
| 17:59 |
grorp |
erle_mobile: okay, that's nice I guess. though as appguru noted in https://github.com/minetest/minetest/pull/15385#issuecomment-2463416132, the texture filtering shouldn't cause that bug in the first place. |
| 18:06 |
MinetestBot |
[git] sfence -> minetest/minetest: Support generation of working Xcode project for signature purposes on… e55ba9c https://github.com/minetest/minetest/commit/e55ba9c390c845c6c60bcdcbaf05b17ed541eb61 (2024-11-10T18:06:52Z) |
| 18:07 |
erle_mobile |
grorp well, last time i debugged and annoyed people about entirely unnecessary filtering fuckups (i.e. reading the relevant standard or testing anything on an intel GPU would have prevented it), i was banned (though not necessarily for that reason). this makes me glad someone else fixes it, though i can't say i am happy about how the regression got |
| 18:07 |
erle_mobile |
introduced (“doesn't have any downsides”, ha-ha). |
| 18:08 |
erle_mobile |
anyways, font is readable again. you can see this in the two screenshots on https://github.com/minetest/minetest/pull/15402/ |
| 18:09 |
grorp |
!tell erle indeed that sentence is funny |
| 18:09 |
MinetestBot |
grorp: I'll pass that on when erle is around |
| 18:09 |
MinetestBot |
[git] rollerozxa -> minetest/minetest: Add Fastlane metadata for F-Droid (#15411) a983b72 https://github.com/minetest/minetest/commit/a983b72713ef4ca66394a374ddd9ec9acbc50e53 (2024-11-10T18:08:08Z) |
| 18:14 |
grorp |
!tell erle however I found your communication style on these issues very unpleasant and I'm glad you were banned for a while |
| 18:14 |
MinetestBot |
grorp: I'll pass that on when erle is around |
| 18:15 |
specing |
erle is an excellent QA person |
| 18:18 |
|
Thermoriax joined #minetest |
| 18:19 |
grorp |
maybe "unpleasant" is the wrong word in this context, more like "unhelpful" or "rude" |
| 18:24 |
specing |
if you don't want erle, I'll gladly have them do QA on my projects :) |
| 18:26 |
MTDiscord |
<jordan4ibanez> And he won't give us back the lost meme |
| 18:34 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Bump version to 5.10.0 568f7a8 https://github.com/minetest/minetest/commit/568f7a8e8fb457c7b7bcfd3211c7f3f0481ed2e7 (2024-11-10T18:17:53Z) |
| 18:34 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Continue with 5.11.0-dev 8503d8d https://github.com/minetest/minetest/commit/8503d8de5ec536f3d6a0cbc7eca24bcc36b21ef3 (2024-11-10T18:17:56Z) |
| 18:48 |
|
SFENCE_arch joined #minetest |
| 18:50 |
|
fling joined #minetest |
| 18:51 |
MTDiscord |
<zmv7> stable-5 branch update when? 👉👈 |
| 18:53 |
sfan5 |
after proper release |
| 19:08 |
|
Trifton joined #minetest |
| 19:29 |
|
grorp left #minetest |
| 19:48 |
|
Glaedr joined #minetest |
| 19:52 |
MTDiscord |
<jordan4ibanez> Google at the moment with this project |
| 19:52 |
MTDiscord |
<jordan4ibanez> https://tenor.com/view/127hater-spongebob-gif-24427141 |
| 19:57 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Revert "Disable SDL2 for 5.10.0 (#15284)" a5e3fca https://github.com/minetest/minetest/commit/a5e3fca40c8feb74c91cafca1aef1423e5375bb6 (2024-11-10T19:56:09Z) |
| 20:01 |
|
erle joined #minetest |
| 20:01 |
MinetestBot |
erle: Nov-10 18:09 UTC <grorp> indeed that sentence is funny |
| 20:01 |
MinetestBot |
erle: Nov-10 18:14 UTC <grorp> however I found your communication style on these issues very unpleasant and I'm glad you were banned for a while |
| 20:02 |
|
erle joined #minetest |
| 20:13 |
erle |
!tell grorp i'll take “unpleasant” or “rude”. but what did you consider “unhelpful”? i found a regression, identified the commit(s), the reason (wrong assumptions about filtering) and managed to convince people that they were wrong. what more could i have done? |
| 20:13 |
MinetestBot |
erle: I'll pass that on when grorp is around |
| 20:14 |
|
Sharpman joined #minetest |
| 20:32 |
|
SwissalpS joined #minetest |
| 20:33 |
|
cx384 left #minetest |
| 20:41 |
|
down200 joined #minetest |
| 20:42 |
|
SFENCE joined #minetest |
| 20:49 |
|
down200 joined #minetest |
| 21:06 |
|
SFENCE joined #minetest |
| 21:12 |
|
SwissalpS joined #minetest |
| 21:16 |
MTDiscord |
<_devsh_> I might have a nugget of information that may upset you. If you have a GPU produced within the last 15 years, whatever you think is fixed function in your GL 2.1 implementation is actually a shader in the driver. This is why I don't buy simpleton profiling like this, you're measuring something but you don't know what you're measuring. The perf diff is probably the uniform setting in irrlicht |
| 21:17 |
MTDiscord |
<_devsh_> Use vTune or any other actual profiler that gives a flame graph and it will show up |
| 21:20 |
|
SFENCE joined #minetest |
| 21:22 |
erle |
_devsh_ why should this be upsetting? |
| 21:27 |
MTDiscord |
<_devsh_> Because the mantra of this person seems to be "shaders == slow" |
| 21:29 |
erle |
they kinda are, if your hardware is old/weak enough. mesa even chose to expose only opengl 1.4 instead of opengl 2.1 on some intel embedded cards, IIRC because advertising higher support made chrome take a slower code path. |
| 21:29 |
MTDiscord |
<_devsh_> https://knowyourmeme.com/memes/wait-its-all-ohio-always-has-been |
| 21:29 |
erle |
_devsh_ so how can i tell the thing to be *faster*? |
| 21:30 |
MTDiscord |
<_devsh_> VTune |
| 21:30 |
MTDiscord |
<_devsh_> You're probably spending a lot of time in glUniform or glGetUniformLocation |
| 21:30 |
cheapie |
The more I hear about this stuff the more inclined I am to start experimenting with older graphics APIs and maybe eventually work my way up to building an alternative Luanti client that uses like D3D6 or something. |
| 21:31 |
cheapie |
It's sounded like a fun project for quite a while now, it's just still way over my head at the moment :P |
| 21:31 |
MTDiscord |
<_devsh_> I'd be surprised if you get your hands on the d3d6 docs in complete form |
| 21:31 |
cheapie |
Doesn't have to be that exact API, just "something like that" |
| 21:32 |
MTDiscord |
<_devsh_> If you wanna do something painful and retro looking do a software rasterizer |
| 21:32 |
erle |
cheapie regarding these things, i was once told by some GPU-adjacent hacker that a future-proof way to make stuff would be to target the oldest opengl standard you want to support, them use libraries (which ones?) for higher standards to support it, because some of those libs do the job better than the driver thingy. |
| 21:33 |
MTDiscord |
<_devsh_> You have to understand that d3d6-11 doesn't existed anymore |
| 21:33 |
MTDiscord |
<_devsh_> It's all layers upon layers of emulation in the new APIs |
| 21:33 |
erle |
jwz once ported xscreensaver to the iphone. xscreensaver was written against opengl 1.3 – but the iphone does not support that. |
| 21:33 |
cheapie |
The target platform would be something like Windows 98. I don't care about it working well on newer stuff, those can just use the normal Luanti client. |
| 21:34 |
erle |
so what jwz did was implement most of the opengl 1.3 API in terms of opengl ES 1.1 |
| 21:34 |
erle |
https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ |
| 21:34 |
erle |
haha |
| 21:34 |
erle |
he is definitely more capable and more rude than i ever could be |
| 21:34 |
erle |
> I wrote this because you are all idiots. |
| 21:34 |
erle |
:D |
| 21:34 |
MTDiscord |
<_devsh_> Samsung phones don't have a native gles driver anymore, it's just ANGPe |
| 21:35 |
MTDiscord |
<_devsh_> ANGLE |
| 21:35 |
sfan5 |
via vulkan? |
| 21:35 |
MTDiscord |
<_devsh_> Meaning GLEs implemented in Vulkan |
| 21:35 |
sfan5 |
I see |
| 21:35 |
MTDiscord |
<exe_virus> Right, GPUs are a cluster. Hence why I believe we're targeting 3.3? |
| 21:36 |
MTDiscord |
<_devsh_> You should target gles 3.0 |
| 21:36 |
cheapie |
FWIW ClassiCube does the same sort of block-building game thing, and when I tried it it ran great on Windows 98SE with a K6-IIIE+ and Radeon 7200... so if that's apparently doable then something capable of connecting to a Luanti server should be too, even if it would be quite limited. |
| 21:36 |
MTDiscord |
<_devsh_> Let me copy paste what I wrote to rubenwardy so irc people see |
| 21:36 |
MTDiscord |
<exe_virus> All android friendos support gles 3.0? |
| 21:37 |
cheapie |
To be clear I'm not saying that someone should go try to get Win9x support merged, but rather I think doing it /as a separate project/ would be doable. |
| 21:37 |
MTDiscord |
<_devsh_> my take is that GL->Vk is a waste of effort unless its accompanied by a paradigm shift in the architecture to get the benefits if you want Vulkan for the sake of Vulkan (Renderdoc, Nsight, debuggable shaders, Vulkan Middleware interop), take your GL renderer, cross-grade it to GLES 3.0 then launder it through ANGLE and you get Vulkan, even Vulkan you can interop with. |
| 21:37 |
MTDiscord |
<_devsh_> https://discord.com/channels/369122544273588224/1262173865610711040/1305204427711578173 |
| 21:37 |
erle |
cheapie IIRC the irrlicht author still tested some stuff on windows 98 WAY past its lifetime so probably all you would have to do is fix the software renderer |
| 21:38 |
MTDiscord |
<_devsh_> not to mention that if you constrain yourself to GLES 3.0, this makes you easily work with WebGL 2.0 |
| 21:38 |
MTDiscord |
<_devsh_> so you can cover Win32, Linux, Android, iOS, Mac, and Web (safari, firefox, chromium) with just one Graphics API, one renderer, one set of shaders, and leave all the compatibility and heavy lifting of targetting multiple APIs to ANGLE |
| 21:38 |
cheapie |
erle: It wouldn't necessarily have to use Irrlicht but that would probably make it easier |
| 21:38 |
erle |
yeah and drops support for even more hardware |
| 21:38 |
erle |
or am i understanding this wrong? |
| 21:38 |
MTDiscord |
<_devsh_> furthermore the thing is actually debuggable (with Renderdoc, Nsight, PIX, Xcode Metal, AMD tooling) on all platforms |
| 21:39 |
erle |
_devsh_ have a demo app? |
| 21:39 |
erle |
“angle” is not very google-able |
| 21:39 |
MTDiscord |
<_devsh_> You could actually use tools like civilized people https://www.youtube.com/watch?v=Fja4lT508cA |
| 21:39 |
erle |
https://github.com/google/angle this one? |
| 21:39 |
MTDiscord |
<_devsh_> Yes that one |
| 21:39 |
MTDiscord |
<_devsh_> You compile it and you get a fake gles 3.0 lib |
| 21:40 |
erle |
oh that must be the thing that the person mentioned |
| 21:40 |
erle |
or one of those things |
| 21:40 |
erle |
the one i talked to |
| 21:40 |
MTDiscord |
<_devsh_> if you're feeling extra adventurous / long term, I'd recommend WebGPU instead of WebGL because then you can at least use Compute Shaders, and possibly descriptor indexing in the near future |
| 21:41 |
sfan5 |
@exe_virus if you're curious here are stats over all people who use the android app https://0x0.st/XDCy.png |
| 21:41 |
sfan5 |
(*installed from play store, because it collects these stats for us) |
| 21:41 |
MTDiscord |
<_devsh_> If they don't have vulkan 1.3 they're not longer getting android updates |
| 21:41 |
MTDiscord |
<_devsh_> But yes everyone has gles 3.0 at least |
| 21:41 |
MTDiscord |
<_devsh_> Except the 1% |
| 21:41 |
sfan5 |
in my experience anything never than vulkan 1.1 is hit or miss on android |
| 21:42 |
MTDiscord |
<_devsh_> Yes vulkan android drivers not fun |
| 21:42 |
MTDiscord |
<_devsh_> Android drivers not fun period |
| 21:42 |
MTDiscord |
<_devsh_> Btw at least renderdoc also works on android |
| 21:42 |
sfan5 |
https://0x0.st/XDCv.png same table for vk |
| 21:43 |
MTDiscord |
<_devsh_> With gles 3.0 you can renderdoc an app running on android over usb/WiFi |
| 21:44 |
MTDiscord |
<_devsh_> Btw gles 3.0 kinda compiles straight to WebGL 2.0 with Emscripten |
| 21:44 |
MTDiscord |
<_devsh_> And sdl2 has a wasm version |
| 21:44 |
MTDiscord |
<_devsh_> https://github.com/Devsh-Graphics-Programming/GPU-With-C-Sharp-Angular-WASM |
| 21:45 |
MTDiscord |
<_devsh_> If you manage to compile all your 3rdparty libs to WASM, you can have a web client |
| 21:45 |
sfan5 |
someone already did that actually |
| 21:45 |
MTDiscord |
<_devsh_> All on the same stack |
| 21:45 |
MTDiscord |
<_devsh_> One version of gles to rule them all |
| 21:46 |
MTDiscord |
<_devsh_> One set of pipelines, one set of shaders |
| 21:46 |
erle |
cheapie if you want to create an old-school cool client, make it a roguelike |
| 21:46 |
MTDiscord |
<_devsh_> Btw you can renderdoc WebGL running in chrome 😄 |
| 21:46 |
erle |
nodecore rogue when? :D |
| 21:49 |
MTDiscord |
<_devsh_> Also for the love of God, if you're profiling something use milliseconds and if you're profiling anything on the GPU use time elapsed queries |
| 21:51 |
MTDiscord |
<_devsh_> https://www.khronos.org/opengl/wiki/Query_Object |
| 21:51 |
MTDiscord |
<_devsh_> https://registry.khronos.org/OpenGL/extensions/EXT/EXT_disjoint_timer_query.txt |
| 21:51 |
MTDiscord |
<_devsh_> https://developer.mozilla.org/en-US/docs/Web/API/WebGLQuery |
| 21:52 |
MTDiscord |
<_devsh_> Also plug in your charge and lock your clocks (MHz) if you have the abily to do so |
| 21:52 |
MTDiscord |
<exe_virus> Good to know, 481 devices affected is not the end of the world. And by the time we get around to it, the number would be lower. |
| 21:53 |
MTDiscord |
<_devsh_> Do you even have the data about when they installed it and last time they played? |
| 21:53 |
MTDiscord |
<exe_virus> Gles 3.0 does look to be acceptable if we were to go that route |
| 21:53 |
MTDiscord |
<exe_virus> No, assume like we're worried about 3 persons. |
| 21:53 |
MTDiscord |
<exe_virus> Maybe 12 |
| 21:53 |
MTDiscord |
<_devsh_> Gles 3.0 is literally dx10 |
| 21:53 |
MTDiscord |
<_devsh_> 2009 feature levels |
| 21:53 |
MTDiscord |
<exe_virus> That's not that old haha, but that's just me |
| 21:54 |
MTDiscord |
<exe_virus> And I'm under 30 |
| 21:54 |
MTDiscord |
<_devsh_> If this is the reason you have decision paralysis then you deserve to get whatever is coming |
| 21:54 |
MTDiscord |
<_devsh_> 2008/2007 is when I started using irrlicht |
| 21:55 |
MTDiscord |
<_devsh_> I would encourage you to jump to webgpu though |
| 21:57 |
|
CRISPR joined #minetest |
| 21:58 |
MTDiscord |
<_devsh_> By ditching another 3% you get to gles 3.1 which Iirc is the minimum level required for GLES to be a full webgpu backend |
| 22:00 |
MTDiscord |
<_devsh_> Because compute shaders go brrrrrr |
| 22:01 |
MTDiscord |
<_devsh_> Quick overview why gles 3.1 >>>>>>>>>>>>>>>>>> gles 3.0 https://discord.com/channels/369122544273588224/369137254641303560/1305221882559070352 |
| 22:02 |
MTDiscord |
<luatic> devsh: note that the IRC people can't see that |
| 22:02 |
MTDiscord |
<_devsh_> I know but I'm on phone and copy pasting all that is infeasible |
| 22:03 |
MTDiscord |
<luatic> sure, but maybe write a quick summary for the IRC people or something |
| 22:03 |
MTDiscord |
<_devsh_> Btw you asked me about bindless textures, webgpu is the only way. Gles will not get a version 3.3, and neither will get a 4.7 |
| 22:03 |
MTDiscord |
<luatic> aw |
| 22:03 |
MTDiscord |
<_devsh_> My thumbs will fall off, if you at PC you can be a star and copy paste |
| 22:04 |
MTDiscord |
<luatic> in a "normal person API" you do this with a bunch of back-to-back compute shaders that use atomic integer operations to build append and consume buffers in SSBOs (or just BDA in Vulkan) then a DrawIndirect at the end in "lets use an obsolete API equivalent of feature set offered by DirectX 15 years ago in 2009" world, you do unholy abuse |
| 22:05 |
MTDiscord |
<luatic> (i will spare the IRC users the gory details of said abuse) |
| 22:06 |
MTDiscord |
<luatic> (context of the above comments by devsh (which in hindsight i should have quoted): compute shaders let you do batching with the help of the GPU) |
| 22:08 |
MTDiscord |
<_devsh_> At the end of the day it doesn't matter whether you go gles or webgpu, what's important is that you'll be running over Vulkan |
| 22:08 |
MTDiscord |
<_devsh_> The biggest advantage is that whenever someone complains about a graphics bug you can adopt a "renderdoc capture/gfxreconstruct frame trace or I'm closing the issue" policy on GH, reproducible rendering |
| 22:09 |
MTDiscord |
<_devsh_> You can even CI that shit properly (renderdoc has a python API) |
| 22:10 |
MTDiscord |
<_devsh_> "batching" is a misnomer but yes doom eternal and dragon age inquisition (on console) draw everything with one drawcall |
| 22:15 |
|
SFENCE joined #minetest |
| 22:33 |
|
SFENCE joined #minetest |
| 22:38 |
MTDiscord |
<exe_virus> Okay, our visiting expert recommendedation: At least gles 3.0 For benefit of profiling with ANGLE At least gles 3.1 if we want some features that would give rendering performance improvements. Per sfan: 3.0 looses 1% (481) android devices. 3.1 looses 4% total, another 1,101 devices. Depending on timelines, both can make sense as potential targets for the next 10-15 year graphics pipeline. |
| 22:41 |
MTDiscord |
<_devsh_> What's the meaning of the 10-15 years? |
| 22:42 |
MTDiscord |
<exe_virus> We likely will invest a lot into a gles 3.0 or 3.1 shader setup. Based on our dev timelines, the next time we get around to upgrading and enough hardware has been obsoleted.... That's the next time we'll be working on a full graphics pipeline rework and upgrade to new feature sets |
| 22:43 |
MTDiscord |
<exe_virus> Ironically you said gles 3.0 is 2009. That's 15 years ago. Only make sense |
| 22:50 |
|
ireallyhateirc joined #minetest |
| 22:51 |
MTDiscord |
<_devsh_> Brush up your gles irrlicht backend |
| 22:52 |
MTDiscord |
<_devsh_> Compile angle, and you can have renderdoc by the end of the month |
| 22:52 |
MTDiscord |
<exe_virus> Yeah agree that's not bad at all |
| 22:52 |
MTDiscord |
<_devsh_> You can have nsight |
| 22:52 |
MTDiscord |
<_devsh_> That's a real profiler |
| 22:53 |
MTDiscord |
<exe_virus> Is nsight better than renderdoc? |
| 22:53 |
MTDiscord |
<exe_virus> Idk I don't do GPU yet, too overworked in CPU land in my day job |
| 22:53 |
MTDiscord |
<_devsh_> Renderdoc is not a profilerz it's a debugger |
| 22:54 |
MTDiscord |
<_devsh_> Nsight will actually show you the time taken |
| 22:54 |
MTDiscord |
<_devsh_> And what's the bottleneck |
| 22:55 |
MTDiscord |
<luatic> why can't i have renderdoc right now |
| 22:56 |
MTDiscord |
<luatic> angle supports gles 2.0 fully |
| 22:57 |
MTDiscord |
<_devsh_> Try it |
| 22:57 |
MTDiscord |
<_devsh_> If you make it use the vulkan backend you'll also get source level debugging in shaders |
| 22:58 |
MTDiscord |
<_devsh_> Mind you, you won't see gles calls, only the Vulkan ones |
| 22:58 |
MTDiscord |
<_devsh_> So if you want to optimise you'll be optimising how to make angle generate vulkan more efficiently |
| 22:58 |
MTDiscord |
<_devsh_> And first thing that will show up is uniforms |
| 22:59 |
MTDiscord |
<_devsh_> And shader switching |
| 23:00 |
MTDiscord |
<_devsh_> Anyway this is why I suggest WebGPU over gles |
| 23:01 |
MTDiscord |
<_devsh_> Will make more sense long term |
| 23:01 |
MTDiscord |
<_devsh_> Also gfx-rs/wgpu (one of the webgpu implementations) has a gles 3.0 backend for now |
| 23:09 |
|
SFENCE joined #minetest |
| 23:29 |
|
SFENCE joined #minetest |
| 23:32 |
|
panwolfram joined #minetest |
| 23:46 |
MTDiscord |
<_devsh_> It's not conformant though, I think compute shaders, storage buffers and images are WebGPU baseline features so for that you need true gles 3.1 |
| 23:47 |
[ |
gles 3.0 does not work on my phone (pinephone) |
| 23:47 |
[ |
if opengl 2.1 and gles 2.0 are both dropped then it won't run on my thinkpad x200 either |
| 23:48 |
[ |
pinephone is only 4 years old |
| 23:48 |
|
SFENCE joined #minetest |
| 23:50 |
MTDiscord |
<_devsh_> It should be a crime to put Mali-400 MP2 in a phone almost a decade after it was released |
| 23:50 |
MTDiscord |
<_devsh_> What's the GPU in your x200? |
| 23:51 |
[ |
GMA 4500 MHD |
| 23:51 |
MTDiscord |
<_devsh_> My God |
| 23:52 |
MTDiscord |
<_devsh_> iGPU from 16 years ago |
| 23:54 |
MTDiscord |
<_devsh_> Do you take donations? |
| 23:54 |
MTDiscord |
<_devsh_> I'm sure I have nicer hardware someone could just send you |
| 23:55 |
ireallyhateirc |
Mali-400 GPUs have reverse-engineered firmware https://docs.mesa3d.org/drivers/lima.html |
| 23:55 |
specing |
I also use GMA 4500 XHD (or MHD?) |
| 23:56 |
ireallyhateirc |
there are probably some more recent chips that use Panfrost, but I don't really track that: https://docs.mesa3d.org/drivers/panfrost.html |
| 23:57 |
ireallyhateirc |
so it may make sense from software freedom perspective |
| 23:57 |
MTDiscord |
<_devsh_> AFAIK all intel and AMD GPUs have open source drivers |
| 23:57 |
MTDiscord |
<_devsh_> On Linux that is |
| 23:58 |
ireallyhateirc |
drivers is one thing, firmware is another |
| 23:58 |
MTDiscord |
<luatic> why do you expect open source firmware to begin with? |
| 23:58 |
MTDiscord |
<_devsh_> I have no clue, at this point buy a FPGA and write a software rasterizer in verilog |
