| Time |
Nick |
Message |
| 00:23 |
|
lhofhansl joined #minetest-dev |
| 00:23 |
lhofhansl |
When would the meeting be? |
| 01:04 |
|
homthack joined #minetest-dev |
| 01:20 |
rubenwardy |
usually 7pm UTC |
| 01:20 |
rubenwardy |
ish |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:37 |
|
Icedream joined #minetest-dev |
| 05:59 |
|
Seirdy joined #minetest-dev |
| 06:19 |
|
fluxflux joined #minetest-dev |
| 07:49 |
specing |
Why is the shout privilege called shout and not talk? |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:07 |
|
Beton joined #minetest-dev |
| 09:28 |
|
calcul0n joined #minetest-dev |
| 10:03 |
|
appguru joined #minetest-dev |
| 10:13 |
|
calcul0n_ joined #minetest-dev |
| 10:26 |
|
proller joined #minetest-dev |
| 10:34 |
rubenwardy |
\o/ |
| 10:35 |
MTDiscord |
<appguru> revoking shout should disable uppercase letters |
| 10:35 |
rubenwardy |
lol https://rwdy.uk/TXkDP.png |
| 10:36 |
rubenwardy |
looks like "shout" is used by other games when they have local and global communication |
| 10:36 |
rubenwardy |
like, a global communication is a shout |
| 11:57 |
|
Fixer joined #minetest-dev |
| 12:21 |
|
appguru joined #minetest-dev |
| 12:22 |
|
appguru joined #minetest-dev |
| 12:39 |
|
lisac joined #minetest-dev |
| 13:00 |
rubenwardy |
#10085 is ready for review again |
| 13:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/10085 -- Use JSON for favorites, move server list code to Lua by rubenwardy |
| 13:00 |
rubenwardy |
I was bitten by Lua's dynamic typing |
| 13:09 |
rubenwardy |
merging #10579 in 15 |
| 13:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/10579 -- Add open user data button to main menu by rubenwardy |
| 13:11 |
Krock |
huh? but "30000" should be read in as a nuber |
| 13:12 |
rubenwardy |
it is tonumber()'d now |
| 13:13 |
Krock |
alright. will test that soon (TM) |
| 13:13 |
rubenwardy |
perhaps it should be tonumbered at a different point |
| 13:14 |
rubenwardy |
hmm, it might need to be, because there's more comparison in tab_online |
| 13:16 |
rubenwardy |
not sure how this ever worked |
| 13:18 |
Krock |
that's a very convincing sentence regarding your PR |
| 13:19 |
rubenwardy |
how the code before this ever worked |
| 13:19 |
rubenwardy |
it's comparing a string port to the number port in the serverlist |
| 13:19 |
Krock |
imcplicit Lua conversion |
| 13:20 |
rubenwardy |
but it didn't coerce for my if-statement |
| 13:20 |
Krock |
the ugliest part in Lua aside the missing "continue" and 1-based indices |
| 13:20 |
Krock |
are you sure it's a raw number, and not \r or \n terminated? |
| 13:21 |
rubenwardy |
it's directly from a field |
| 13:21 |
rubenwardy |
well, if this didn't work, the only side affect would be that server names/descriptions wouldn't update in the favourites after joining again |
| 13:22 |
rubenwardy |
actually no, it's storing name/desc after all |
| 13:22 |
rubenwardy |
so this would cause servers to be displayed without descriptions if they're not currently online |
| 13:22 |
rubenwardy |
because it's not being stored in favourite |
| 13:22 |
rubenwardy |
this may be what's already happening |
| 13:23 |
rubenwardy |
yeah, this is a bug that no one noticed |
| 13:23 |
Krock |
either that or it's one of the 1000 issues |
| 13:24 |
Krock |
"with select Minetest staff" -> "with selected Minetest staff" ? |
| 13:24 |
rubenwardy |
yeah that reads better |
| 13:25 |
Krock |
at least to my knowledge former is exclusively used as a verb, latter as adjective |
| 13:27 |
MTDiscord |
<appguru> Krock: no |
| 13:27 |
rubenwardy |
they both work |
| 13:27 |
MTDiscord |
<appguru> "1" ~= 1 in Lua |
| 13:28 |
Krock |
but 1 == "1" |
| 13:28 |
Krock |
err no |
| 13:28 |
MTDiscord |
<appguru> no |
| 13:28 |
rubenwardy |
both false |
| 13:28 |
MTDiscord |
<appguru> Only concatenation and addition (probably also subtraction etc.?) coerce |
| 13:28 |
rubenwardy |
and also function use |
| 13:28 |
MTDiscord |
<appguru> function use? |
| 13:29 |
rubenwardy |
like, passing a number to a function that expects a string |
| 13:29 |
rubenwardy |
C function specifically |
| 13:29 |
MTDiscord |
<appguru> ah that |
| 13:29 |
MTDiscord |
<appguru> I meant inside Lua |
| 13:29 |
MTDiscord |
<appguru> but yup, other arithmetic ops coerce as well |
| 14:05 |
|
Wuzzy joined #minetest-dev |
| 15:33 |
|
turtleman joined #minetest-dev |
| 17:58 |
Krock |
Meeting in an hour - let's see who's got time. |
| 17:59 |
rubenwardy |
we didn't post in the org |
| 18:25 |
|
Wuzzy joined #minetest-dev |
| 18:30 |
Krock |
ah right. forgot that again |
| 18:36 |
|
Wuzzy joined #minetest-dev |
| 18:46 |
|
fluxflux joined #minetest-dev |
| 18:56 |
|
systwi joined #minetest-dev |
| 19:00 |
|
T4im joined #minetest-dev |
| 19:11 |
Krock |
Looks like only rubenwardy would be ready. THen let's move it to next week with a proper announcement? |
| 19:12 |
rubenwardy |
yeah |
| 19:13 |
sfan5 |
i'd be here too |
| 19:13 |
|
fluxflux joined #minetest-dev |
| 19:13 |
sfan5 |
what would we be discussing anyway? |
| 19:19 |
Krock |
I had concept discussions in mind, and those with one approval |
| 19:19 |
Krock |
perhaps also checking with you whether the texture alpha stuff can be solved somewhen |
| 19:19 |
Krock |
( https://dev.minetest.net/Meetings ) |
| 19:20 |
|
turtleman joined #minetest-dev |
| 19:21 |
|
lhofhansl joined #minetest-dev |
| 19:22 |
lhofhansl |
I'm around now. |
| 19:22 |
sfan5 |
regarding that, I pretty much just need to find some time for it |
| 19:23 |
Krock |
yes, I see. buys times. |
| 19:23 |
Krock |
*busy |
| 19:23 |
Krock |
oh cool. 4 devs is a good amount to start |
| 19:24 |
Krock |
> 5.3.1 or 5.4.0 release date? |
| 19:25 |
Krock |
No patch release, just 5.4.0 in January. that's what I heard earlier |
| 19:25 |
lhofhansl |
Sounds good. There's a lot of new and improved stuff. |
| 19:25 |
|
numzero joined #minetest-dev |
| 19:26 |
Krock |
still a few open issues, though. https://github.com/minetest/minetest/milestone/17 |
| 19:26 |
Krock |
but most of those are nice-to-have |
| 19:27 |
|
T4im joined #minetest-dev |
| 19:27 |
lhofhansl |
Re: one approval. There's #10714, which I am a bit concerned about since it would triple the # of blocks that the client would forcefully keep in its cache. |
| 19:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/10714 -- Keep mapblocks in memory if they're in range by hecktest |
| 19:28 |
Krock |
of how much memory are we talking there in average? |
| 19:28 |
Krock |
I mean, mapblocks are a few kilobytes in raw state |
| 19:28 |
lhofhansl |
Actually not sure how big a block (including mesh) is. |
| 19:29 |
Krock |
it will only cause issues on devices with little RAM, such as mobile |
| 19:29 |
Krock |
if even. |
| 19:29 |
lhofhansl |
These blocks would stay in the cache for 10 minutes anyway. So what this does it keeps the sphere of blocks in memory (if they were looked at) beyond that. |
| 19:30 |
lhofhansl |
So that after 10 minutes the blocks would not have to be reloaded. It's not a bad change. |
| 19:30 |
|
absurb joined #minetest-dev |
| 19:30 |
Krock |
especially when travelling around a certain area |
| 19:30 |
Krock |
should also lower server traffic a bit, though I doubt it would make much of a difference for them |
| 19:30 |
lhofhansl |
it seems I'm the only one concerned so let's get that in. Technically it's totally fine. |
| 19:31 |
Krock |
right, also the max cached mapblocks can be configured, hence no problem |
| 19:31 |
Krock |
assuming that limit works reliably |
| 19:32 |
lhofhansl |
well... The sphere will always be in the cache even when reduce the number of blocks you want to cache ... that's the concern. |
| 19:32 |
|
T4im joined #minetest-dev |
| 19:32 |
lhofhansl |
before that it was only the view cone that was forced into the cache beyond its configured size |
| 19:33 |
lhofhansl |
that's only a problem with large viewing_ranges, though. |
| 19:35 |
Krock |
exactly, and using large viewing ranges means exponential growth of memory consumption |
| 19:38 |
Krock |
lhofhansl: do you have any opinion on #10515? |
| 19:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/10515 -- Fix base64 validation and add minetest.is_valid_base64() by appgurueu |
| 19:38 |
lhofhansl |
so when setting the block send distance to 32 (needed for a viewing_range of 500) you'd force 137k to stay in the cache, even when many of them might be invisible from where the client is looking is right now. But that's the only concern I have. |
| 19:39 |
lhofhansl |
Looking. |
| 19:40 |
lhofhansl |
What's wrong with testing a valid string by checking for nil returned from decode? |
| 19:40 |
lhofhansl |
But no problem with it in concept. |
| 19:41 |
Krock |
pretty sure time will tell - or rather players - whether this new caching works for them, or whether the memory footprint is too high |
| 19:42 |
Krock |
yes. that's my concern. IMO it does not need another function, if another one is already capable doing it for almost the same speed |
| 19:45 |
lhofhansl |
There's also a bug fix in there, right? |
| 19:46 |
Krock |
not quite. the current base64 decoding function does its own checks as well |
| 19:47 |
Krock |
the base64 validation function is currently only used as a quick & dirty check |
| 19:47 |
|
calcul0n joined #minetest-dev |
| 19:51 |
lhofhansl |
#10663 is ready it seems |
| 19:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/10663 -- Cleanup shader generation code by numberZero |
| 19:52 |
Krock |
oh great. yes. will merge that in 5 minutes |
| 19:52 |
Krock |
clang failed due to a random setup issue... |
| 19:52 |
lhofhansl |
Yep |
| 19:53 |
lhofhansl |
I do not know enough about #10643 and #10624 to say anything useful |
| 19:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/10643 -- Fix falling node rotation of wallmounted nodebox/mesh by Wuzzy2 |
| 19:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/10624 -- Fix some more joystick issues by m42uko |
| 19:54 |
Krock |
former needs fixing |
| 19:54 |
m42uko |
If you have any questions aout 10624, I'm available. |
| 19:54 |
m42uko |
Fix will be there n 15mins or so |
| 19:55 |
lhofhansl |
#10363 seems fine. |
| 19:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/10363 -- [MainMenu] Add clear button and icon for search one. by Andrey2470T |
| 19:55 |
Krock |
no questions from my side because I don't know much about controllers eithr |
| 19:55 |
lhofhansl |
(same here :( ) |
| 19:56 |
Krock |
merging (1) |
| 19:57 |
lhofhansl |
10624 looks like it won't break anything else. So assuming you tested it, I'm fine with it being merged. |
| 19:58 |
Krock |
about the falling node PR. this has low error potential, and Wuzzy knows best how it should look like. I did a quick & dirty check and it seemed OK |
| 19:58 |
sfan5 |
10624 still needs a fix then I can give it my approval too |
| 19:58 |
|
T4im joined #minetest-dev |
| 19:58 |
Krock |
indeed. depends on sfan5's review |
| 19:59 |
Krock |
about main menu. seems fine. trivial too. |
| 20:00 |
Krock |
testing it quickly... |
| 20:00 |
sfan5 |
10643 looks good too |
| 20:01 |
Krock |
10363 works |
| 20:02 |
Krock |
sfan5: in this case I'll add the second approval there |
| 20:03 |
Krock |
something that bothers me is #10555 |
| 20:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/10555 -- Mapgen settings in a game's minetest.conf get ignored |
| 20:03 |
Krock |
how important is that? how many people configure their params before creating a new world? |
| 20:04 |
Krock |
also, shall the simple setDefaults PR be merged first, or rather the entire Settings re-structing PR? |
| 20:04 |
sfan5 |
the menu itself does that |
| 20:04 |
sfan5 |
but the issue title says it's about a minetest.conf from a game |
| 20:05 |
Krock |
oh. I skipped that during reading. it's used rarely but should be fixed then |
| 20:05 |
lhofhansl |
restructuring the entire settings needs more discussion. For example I think that all the various distance configuration should sit together near each other. |
| 20:06 |
lhofhansl |
(that is: client, server, and mapgen setting for distance) |
| 20:06 |
Krock |
are you talking about the defaultsettings.cpp line order/settingtypes line order? |
| 20:06 |
lhofhansl |
settingtypes |
| 20:07 |
Krock |
okay. yes, that can be done too, independently. issue here is within the core which does not apply the correct mapgen settings |
| 20:07 |
lhofhansl |
(I closed the "make sense of the distance settings" issue, because it seems I was the only one who cared) |
| 20:07 |
lhofhansl |
Oh yeah, different issues. |
| 20:08 |
lhofhansl |
Oh... Ordering between game minetest.conf and global minetest.conf... Is that what you meant? |
| 20:08 |
Krock |
regular players don't care about the raw settingtypes format as long they can find it in the search bar, and those who look up the raw file usually know what to look for |
| 20:08 |
Krock |
exactly |
| 20:09 |
Krock |
currently it's a combination of set, override & reset |
| 20:09 |
Krock |
.. of g_settings |
| 20:09 |
lhofhansl |
I think a game local minetest.conf is powerful and if it's not working we should definitely fix it. |
| 20:10 |
lhofhansl |
what *is* the right order? (1) default, (2) global, (3) game? |
| 20:10 |
Krock |
question is whether #10640 should be taken & improved, or whether #10661 should be tested well |
| 20:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/10640 -- Make overrideDefaults override defaults with other defaults also by pyrollo |
| 20:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/10661 -- [MANUAL SQUASH] Settings: Proper priority hierarchy by SmallJoker |
| 20:10 |
Krock |
default -> game -> global -> map settings |
| 20:11 |
lhofhansl |
shouldn't the game setting override the global settings? |
| 20:11 |
Krock |
no, because then you couldn't customize the newly generated world params |
| 20:12 |
Krock |
that's the current mindset. one might argue that games have priority |
| 20:13 |
lhofhansl |
hmm... That's an interesting one. Perhaps it's a UI problem, if you could modify the game settings it would be OK, right? (although then not what the game intended) |
| 20:13 |
lhofhansl |
If a game does not specify specific settings then the global settings would override, right? |
| 20:14 |
Krock |
currently the global settings override the game settings, yes. if none of both is defined, it falls back to the dedfaultsettings.cpp values |
| 20:16 |
lhofhansl |
Ok... I clearly haven't thought about this enough :) |
| 20:17 |
Krock |
I hope my PR can clear those confusions and the bugs with it. Though it will require quite some testing because it's a fundamental change |
| 20:19 |
Krock |
alright. a real meeting will be announced much earlier. Sorry for the somewhat spontaneous request |
| 20:19 |
lhofhansl |
all good. |
| 20:20 |
lhofhansl |
I need to head out soon'ish. Are we having some direct discussion as well? |
| 20:20 |
Krock |
updating the wiki page just to have a bit of an overview of the progress for the next release |
| 20:20 |
numzero |
Krock: am I right a global setting will override game setting? |
| 20:20 |
Krock |
lhofhansl: no, it's just here |
| 20:20 |
Krock |
numzero: that's how it works right now, yes. |
| 20:21 |
numzero |
oh, okay. anyway I have two questions |
| 20:21 |
lhofhansl |
sorry... I meant direction discussion :) |
| 20:21 |
lhofhansl |
Like #10461 |
| 20:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/10461 -- Roadmap Brainstorm |
| 20:21 |
Krock |
I believe we already had that a few months ago, and most of the opinions are written down there |
| 20:22 |
Krock |
no strong opinion from my side. just caring about bugfixes and features here and there |
| 20:22 |
numzero |
is it possible from the UI 1) to unset a global setting (so that it won’t override anything), 2) to set a global setting to its default not unsetting it (to override game setting with that default)? |
| 20:23 |
Krock |
1) remove the setting (there's a reset button IIRC) |
| 20:23 |
Krock |
2) could be implemented easily |
| 20:23 |
Krock |
... but does not exist yet |
| 20:24 |
lhofhansl |
A new thing I've been spending time is increasing the useful rendering distance. Both client (the atlasing or batching hecks wants to do - hopefully) and the server side improvements I have been working on. |
| 20:24 |
numzero |
there is a “restore default” button; it’s unclear whether it does 1) or 2) |
| 20:24 |
Krock |
it removes the setting, causing it to fall back to defaults, which is either defaultsettings or the game settings, depending on what's defined |
| 20:24 |
lhofhansl |
Do we want to consider #10709 for 5.4.0? Or wait? |
| 20:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/10709 -- Allow map save to compress blocks asynchronously. by lhofhansl |
| 20:25 |
Krock |
right off my top I don't know how to reword that to make things clear |
| 20:25 |
Krock |
tbh I'd prefer to wait |
| 20:25 |
lhofhansl |
NP |
| 20:25 |
sfan5 |
I have no idea when 5.4.0 is going to be released anyway |
| 20:25 |
sfan5 |
so hard to say anything now |
| 20:25 |
Krock |
5.4.0 has already waited for a while now, and this PR is best merged right after its release to do testing on real-world applications |
| 20:26 |
Krock |
it all comes down to how quickly those mailestone issues are addressed, probably. |
| 20:26 |
Krock |
though the alpha texture and settings issue are tricky ones |
| 20:26 |
lhofhansl |
Yeah. Probably better. I really hope hecks finds time to work on the client stuff. Then together with this (and similar changes) MT can handle greater viewing_ranges. |
| 20:27 |
rubenwardy |
it's probably best to leave 5.4 for the new year |
| 20:27 |
Krock |
rubenwardy: January |
| 20:28 |
lhofhansl |
so 10640 is a significant change... Not sure how I would create confidence in it, since you'd have to test so many permuations. |
| 20:28 |
lhofhansl |
permutations |
| 20:28 |
m42uko |
(sorry to interrupt) sfan5, just pushed an update to 10624. Can you please test again whether this fixes your deadzone problems. |
| 20:29 |
lhofhansl |
please interrupt :) |
| 20:30 |
Krock |
right. testing the flags is a pain |
| 20:30 |
Krock |
perhaps I could add a unittest for these two cases which are sane checks |
| 20:31 |
lhofhansl |
One way - assuming you're reasonably confident - is to put it into 5.4.0. And then fix any potential fallout in 5.4.1. |
| 20:32 |
lhofhansl |
I need to run unfortunately. |
| 20:32 |
Krock |
the irc logs will be there for you. cya. |
| 20:32 |
|
troller joined #minetest-dev |
| 20:33 |
Krock |
fact is that it needs fixing. I'm pretty sure it's the same, long chain of bugfixes & regressions which started as a bugfix |
| 20:36 |
sfan5 |
m42uko: yes it's fixed now |
| 20:36 |
m42uko |
Great :) |
| 20:41 |
sfan5 |
the default deadzone is still too low to avoid triggering accidental walking on my controller but ¯\_(ツ)_/¯ |
| 20:43 |
|
v-rob joined #minetest-dev |
| 20:43 |
v-rob |
Just saw the meeting notification; I suppose I missed it? |
| 20:44 |
sfan5 |
sorta, the announcement came late too |
| 20:44 |
sfan5 |
most are still here though so if you have something to discuss after reading the log go ahead |
| 20:44 |
|
Fixer_ joined #minetest-dev |
| 20:44 |
m42uko |
sfan5, true^^ I'll see whether I can come up with some solution to automatically detecting all of this over Christmas. |
| 20:45 |
sfan5 |
is it controller dependent? |
| 20:45 |
sfan5 |
I don't see how one would estimate the correct values otherwise |
| 20:45 |
m42uko |
yea it is |
| 20:46 |
m42uko |
There are databases cataloging controllers and their parameters (including deadzones). SDL2 has this one for example: https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt |
| 20:46 |
v-rob |
I wish we could use SDL's input system instead of Irrlicht's... |
| 20:47 |
sfan5 |
oof |
| 20:48 |
m42uko |
Are there any current efforts on replacing large parts of Irrlicht in MT? I thougth I read about that somewhere but not sure whether it was just gossip |
| 20:49 |
rubenwardy |
not really |
| 20:49 |
rubenwardy |
it's a monstrous task |
| 20:49 |
rubenwardy |
I wonder if Irrlicht would allow us to use SDL alongside it |
| 20:50 |
rubenwardy |
:D |
| 20:50 |
rubenwardy |
Doubt |
| 20:50 |
v-rob |
I think I've seen that |
| 20:50 |
sfan5 |
controller support seems quite decoupled so that isn't entirely unrealistic |
| 20:50 |
numzero |
v_rob: IrrLicht-on-SDL? |
| 20:50 |
rubenwardy |
SDL would need access to the window to receive events |
| 20:50 |
sfan5 |
we may have to switch to our own fork of irrlicht anyway, https://github.com/minetest/irrlicht is already prepared for that |
| 20:50 |
sfan5 |
rubenwardy: yeah but from what I've seen controllers don't work that way |
| 20:50 |
rubenwardy |
so either Irrlicht or SDL would need to use the window created by the other |
| 20:50 |
rubenwardy |
oh really, maybe |
| 20:51 |
sfan5 |
you open the controller and just read the stuff |
| 20:51 |
rubenwardy |
I guess it uses joystick/event a lot |
| 20:51 |
v-rob |
Irrlicht has a way to use a custom window |
| 20:51 |
v-rob |
In createDevice or something like that |
| 20:51 |
sfan5 |
you can't really share the window |
| 20:54 |
sfan5 |
merging #10363, #10624 in 5m |
| 20:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/10363 -- [MainMenu] Add clear button and icon for search one. by Andrey2470T |
| 20:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/10624 -- Fix some more joystick issues by m42uko |
| 20:54 |
numzero |
sfan5: after switching to own IrrLicht fork it will be possible to improve it gradually to make something usable, instead of replacing the whole thing at once |
| 20:54 |
sfan5 |
yes |
| 20:54 |
sfan5 |
we'll also be able to fix stuff like the mac shift click thing |
| 20:54 |
sfan5 |
or some bone brokenness(?) |
| 20:55 |
numzero |
or lack of non-indexed rendering? |
| 20:56 |
numzero |
I dream of custom vertex formats |
| 20:56 |
numzero |
oh, and more texture formats ofc |
| 20:56 |
numzero |
integral and 3D textures have many uses |
| 20:56 |
sfan5 |
those are more work, but doable ofc if we can modify Irrlichts source for our needs |
| 20:57 |
sfan5 |
do you remember where it was missing indexed rendering btw? |
| 20:57 |
numzero |
texture formats aren’t a problem |
| 20:57 |
numzero |
vertex formats are ofc |
| 20:57 |
numzero |
IrrLicht misses *non*-indexed rendering |
| 20:58 |
numzero |
i.e. one has to specify indices even if these are sequential |
| 20:58 |
sfan5 |
oh now I get it |
| 20:58 |
sfan5 |
that wastes gpu bandwidth, I guess? |
| 20:58 |
numzero |
gpu bus bandwidth |
| 20:58 |
numzero |
and synchronization |
| 20:59 |
numzero |
and works terribly with primitive types not supported natively, like quads or triangle-fan on some backends |
| 21:00 |
numzero |
these could be drawn trivially as triangle list with engine-supplied indices, but not if the user specified his own indices as no GPU supports two-level indexing |
| 21:03 |
numzero |
(the problem was reported to be extreme on OpenGL-on-METAL, and native OpenGL is planned to be removed from that OS) |
| 21:04 |
v-rob |
Just curious, but what have people proposed as a replacement for Irrlicht? |
| 21:05 |
rubenwardy |
\o/ |
| 21:05 |
rubenwardy |
if we had the skills, then SDL+OpenGL/Vulkan |
| 21:06 |
v-rob |
What precisely is Vulkan? |
| 21:06 |
v-rob |
I've heard of it, but know little about it |
| 21:06 |
rubenwardy |
no idea, it's trendy though |
| 21:06 |
celeron55 |
vulkan is a thing where you write your own opengl |
| 21:06 |
rubenwardy |
lol |
| 21:07 |
rubenwardy |
OpenGL has a lot of clutter, and is deprecated on MacOS/iOS |
| 21:07 |
v-rob |
Deprecated? Wow. What do they use instead? |
| 21:07 |
v-rob |
Direct3d? :P |
| 21:07 |
sfan5 |
a thing called "Metal" |
| 21:07 |
numzero |
they use METAL |
| 21:07 |
numzero |
their own invention |
| 21:08 |
numzero |
similar to Vulkan but proprietary |
| 21:08 |
v-rob |
So much for cross-platform compatibility |
| 21:08 |
numzero |
oh yeah |
| 21:08 |
numzero |
even MS keeps OpenGL AFAIK |
| 21:09 |
v-rob |
Yeah |
| 21:09 |
sfan5 |
windows only implements opengl 1.4 unless you install drivers |
| 21:09 |
v-rob |
What's the support for Vulkan everywhere then? |
| 21:11 |
sfan5 |
you mean on which platforms its supported? |
| 21:11 |
v-rob |
Yes |
| 21:12 |
sfan5 |
windows, linux, android |
| 21:12 |
sfan5 |
some game consoles maybe(??) |
| 21:12 |
rubenwardy |
macos with some thirdparty code |
| 21:12 |
rubenwardy |
like, I think it translates to metal |
| 21:13 |
v-rob |
In other words, to replace Irrlicht with one of these, it's OpenGL (shaky) or Vulkan or bust |
| 21:13 |
v-rob |
And people wonder why we still use Irrlicht... |
| 21:13 |
rubenwardy |
there's also BFX or something |
| 21:13 |
|
Giov4 joined #minetest-dev |
| 21:13 |
rubenwardy |
https://github.com/bkaradzic/bgfx |
| 21:14 |
sfan5 |
you wouldn't replace Irrlicht with OpenGL, one's an engine the other just the api |
| 21:14 |
sfan5 |
API wise you can keep relying on OpenGL and tell people with platforms that don't support it that it's their fault |
| 21:14 |
sfan5 |
Vulkan is a nice to have because it's modern and stuff |
| 21:15 |
v-rob |
I know, but people have suggested plain Vulkan |
| 21:15 |
sfan5 |
eh yea that's not a good idea |
| 21:15 |
numzero |
Vulkan is not supposed to be used plain |
| 21:15 |
rubenwardy |
I suggested SDL + (OpenGL or Vulkan) |
| 21:15 |
rubenwardy |
SDL as a window opener and input library |
| 21:15 |
numzero |
it’s more like a GPU access API which one needs to wrap into an engine suitting his needs |
| 21:16 |
rubenwardy |
We struggle to find anyone to do graphics programming for Irrlicht, OpenGL is a whole other level of workload |
| 21:16 |
sfan5 |
how is that different from sdl + opengl? |
| 21:16 |
sfan5 |
do you want to implement a scene graph and everything else from scratch? |
| 21:16 |
numzero |
rubenwardy: graphics programming for raw OpenGL is somewhat easier that that for IrrLicht |
| 21:17 |
m42uko |
In terms of game engines, I think godot is still on the rise in the open source community. But I haven't looked at it in a while, and I have no idea on what a migration could look like. |
| 21:17 |
numzero |
and way more productive |
| 21:17 |
rubenwardy |
It's not really possible to port to Godot |
| 21:17 |
rubenwardy |
unless we had Minetest as a massive C++ plugin |
| 21:17 |
v-rob |
Honestly, it sounds much nicer to use our own fork of Irrlicht |
| 21:18 |
sfan5 |
we could and it's not even that much work to hook it up |
| 21:18 |
rubenwardy |
in any case, I think Irrlicht has propagated way too much into the codebase and cutting it back might be an idea at times |
| 21:19 |
sfan5 |
just there hasn't been a stron enough reason yet |
| 21:19 |
m42uko |
Ah okay, so godot is still a pain when used with C++ ^^ |
| 21:19 |
rubenwardy |
yeah |
| 21:19 |
rubenwardy |
forking Irrlicht is the easiest option |
| 21:20 |
v-rob |
Hey, since when did we have a "Helpers" group on the forums? |
| 21:20 |
v-rob |
It's pink |
| 21:20 |
rubenwardy |
also, I think you should consider the life of Minetest and how long it would take to replace Irrlicht. We don't want to netscape it |
| 21:20 |
rubenwardy |
v-rob: today, they have permission to move topics |
| 21:20 |
v-rob |
Like moving mods from WIP to Releases? |
| 21:21 |
MTDiscord |
<appguru> "rubenwardy: graphics programming for raw OpenGL is somewhat easier that that for IrrLicht" I agree |
| 21:21 |
numzero |
btw we have `irrlicht_changes` already... |
| 21:21 |
v-rob |
Most of those changes are GUI/TTF |
| 21:21 |
numzero |
I mean, there is something to apply to the fresh fork immediately) |
| 21:21 |
sfan5 |
yeah you cant replace rendering or input like that |
| 21:21 |
rubenwardy |
> We don't want to netscape it |
| 21:21 |
rubenwardy |
I think it was netscape - they spent years without a release due to rewrites, and ended up becoming irrelevant |
| 21:22 |
v-rob |
Well, my hope is that the entire Irrlicht GUI will be removed from Minetest at some point |
| 21:22 |
numzero |
wasn’t netscape defeated by MS? |
| 21:22 |
rubenwardy |
partly because of the rewrites |
| 21:23 |
v-rob |
Yeah, but Netscape wasn't too much better than IE |
| 21:23 |
rubenwardy |
IE was good |
| 21:23 |
rubenwardy |
it became bad when MS stopped being competitive with it, and broke standards |
| 21:24 |
v-rob |
It had some very good non-standard ideas, like insertAdjacentElement (which became standard) |
| 21:24 |
rubenwardy |
or so an article I read says so. I was like 5 at the time |
| 21:26 |
v-rob |
They let it rot at IE 6. Didn't receive updates until after Firefox had started beating it |
| 21:30 |
v-rob |
BTW, anyone have any thoughts on my custom texture proof-of-concept? |
| 21:33 |
MTDiscord |
<appguru> Yeah |
| 21:33 |
MTDiscord |
<appguru> It's great |
| 21:34 |
MTDiscord |
<appguru> Although... We still need SSCSM :D |
| 21:35 |
MTDiscord |
<appguru> BTW are you still stuck on how to render lines? |
| 21:36 |
v-rob |
Yes; driver->draw2DLine doesn't reliably have thickness |
| 21:36 |
v-rob |
And there's no good filled polygon function as far as I can see |
| 21:37 |
MTDiscord |
<appguru> I was thinking maybe use shaders for this? |
| 21:37 |
v-rob |
Then it would only work on OpenGL, right? |
| 21:37 |
MTDiscord |
<appguru> Yeah |
| 21:37 |
MTDiscord |
<appguru> But TBF the other drivers are fairly unusable |
| 21:38 |
v-rob |
Actually, for a software renderer, Burningsvideo is fairly nice |
| 21:39 |
MTDiscord |
<appguru> Indeed |
| 21:39 |
v-rob |
Plain "software" is a nightmare. (You can cheat with it by seeing underground) |
| 21:39 |
MTDiscord |
<appguru> It is buggy though |
| 21:39 |
celeron55 |
burningsvideo is irrlicht's party trick |
| 21:39 |
celeron55 |
it's amazing but still useless 8) |
| 21:40 |
MTDiscord |
<appguru> hehe |
| 21:40 |
MTDiscord |
<appguru> I agree |
| 21:40 |
v-rob |
Regardless, if shaders don't work on OpenGl ES, it's a no-go |
| 21:40 |
v-rob |
I don't know if they do or not |
| 21:40 |
MTDiscord |
<appguru> IIRC shaders work on ES (was there a PR for that?) |
| 21:41 |
Krock |
yes they did work |
| 21:42 |
Krock |
or no? I thought numzero wrote a PR to implement that a while ago |
| 21:43 |
MTDiscord |
<appguru> imma see real quick |
| 21:43 |
numzero |
they were broken again recently |
| 21:43 |
numzero |
https://github.com/minetest/minetest/pull/9247#issuecomment-745609396 |
| 21:47 |
|
troller joined #minetest-dev |
| 21:50 |
rubenwardy |
I used burningsvideo in CI to render formspec images |
| 21:50 |
rubenwardy |
although, some way of doing OpenGL in software probably would have been better |
| 21:51 |
rubenwardy |
the CI server didn't have a GPU or even an iGPU, apparently |
| 21:51 |
rubenwardy |
probably just disabled |
| 21:51 |
MTDiscord |
<appguru> OpenGL is not made for software |
| 21:51 |
rubenwardy |
or server chip |
| 21:51 |
MTDiscord |
<appguru> Using an abstraction like Irrlicht makes perfect sense |
| 21:51 |
rubenwardy |
it doesn't need to be real time |
| 21:52 |
rubenwardy |
I believe older RPis do software OpenGL (ES) |
| 21:52 |
rubenwardy |
actually idk |
| 21:53 |
rubenwardy |
burnings rendered something, but what it rendered was wrong |
| 21:53 |
MTDiscord |
<appguru> I'm just saying software allows different optimization techniques to be used |
| 21:53 |
MTDiscord |
<appguru> "burnings rendered something, but what it rendered was wrong" there seem to be scaling issues with software drivers |
| 21:53 |
rubenwardy |
in CI I don't care so much about optimisation |
| 21:54 |
rubenwardy |
that PR has been shelved, anyway |
| 21:54 |
v-rob |
Got to head out. |
| 21:54 |
rubenwardy |
o/ |
| 21:55 |
MTDiscord |
<appguru> o/ |
| 21:58 |
|
hecks joined #minetest-dev |
| 22:02 |
numzero |
OpenGL *was* designed for software |
| 22:02 |
numzero |
initially |
| 22:03 |
numzero |
and the version IrrLicht uses is... well... not far from that initial version |
| 22:04 |
numzero |
also, Mesa started as *software* OpenGL implementation |
| 22:04 |
numzero |
it may still support software rendering |
| 22:07 |
numzero |
heh, it seems to support OpenGL 4.6 in software |
| 22:07 |
numzero |
https://mesamatrix.net/ |
| 23:19 |
pgimeno |
> <Krock> exactly, and using large viewing ranges means exponential growth of memory consumption |
| 23:19 |
pgimeno |
^ why exponential and not cubic? |
