| Time |
Nick |
Message |
| 00:27 |
|
Alias2 joined #minetest-dev |
| 01:43 |
|
jordan4ibanez joined #minetest-dev |
| 01:58 |
|
v-rob joined #minetest-dev |
| 02:29 |
|
v-rob joined #minetest-dev |
| 03:21 |
MTDiscord |
<exe_virus> Use msys |
| 03:28 |
|
queria joined #minetest-dev |
| 03:31 |
|
v-rob joined #minetest-dev |
| 03:33 |
|
queria joined #minetest-dev |
| 04:08 |
MTDiscord |
<josiah_wi> ExeVirus, it's the mingw CI build. :| |
| 04:18 |
erlehmann |
sfan5 you closed this, but i am pretty sure that this is not a GPU driver bug. rather, i think that 512 instructions is the minimum (many cards have more) https://github.com/minetest/minetest/issues/12035#issuecomment-1027306600 |
| 04:20 |
erlehmann |
e.g. you are guaranteed 512 instructions for your shader in OpenGL 2.0, i am not sure about this. |
| 04:22 |
erlehmann |
wtf is OpenGL 2.0a https://en.wikipedia.org/wiki/High-level_shader_language#Pixel_shader_comparison |
| 04:22 |
erlehmann |
oh, hlsl vs glsl |
| 04:22 |
erlehmann |
i should sleep |
| 04:24 |
erlehmann |
https://stackoverflow.com/questions/2617957/glsl-maximum-number-of-instructions/5601884#5601884 |
| 04:24 |
erlehmann |
> 512 instruction slots for vertex and pixel shaders on OpenGL 2.x (SM3) capable hardware |
| 04:25 |
erlehmann |
maybe there are different limits for OGLES |
| 04:25 |
erlehmann |
anyway it seems like a good idea to stay under the limit maybe? |
| 04:26 |
erlehmann |
https://github.com/hrydgard/ppsspp/issues/1816#issuecomment-517872311 |
| 04:27 |
|
v-rob joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:37 |
|
Yad joined #minetest-dev |
| 05:38 |
|
jordan4ibanez_ joined #minetest-dev |
| 05:43 |
|
jordan4ibanez__ joined #minetest-dev |
| 06:49 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:05 |
|
appguru joined #minetest-dev |
| 07:12 |
sfan5 |
erlehmann: I (and I hope nobody else) is going to spend any time moving shader things around to make some underpowered hardware work |
| 07:13 |
erlehmann |
uh i do not understand, you are or you aren't? |
| 07:14 |
erlehmann |
i mean, from context i guess you aren't. but i can't parse the sentence. |
| 07:14 |
sfan5 |
+am not |
| 07:14 |
erlehmann |
ok |
| 07:14 |
erlehmann |
thx |
| 07:26 |
erlehmann |
there is one problem though; i can't find the OGLES2 limits right now, but the spec for GLSL ES says that it the limits are determined by the conformance tests, and the mali gpu is conformant. |
| 07:27 |
erlehmann |
or at least so says the vendor https://en.wikipedia.org/wiki/Mali-400_MP |
| 07:27 |
erlehmann |
> world’s first OpenGL ES 2.0 conformant multi core GPU |
| 07:27 |
erlehmann |
so i'm pretty sure you can't say that you are doing OGLES2 if an OGLES2 conformant thing doesn't work with it |
| 07:32 |
erlehmann |
regardless, a better error message may make sense here. i.e. blacklisting the mali GPU. |
| 07:49 |
sfan5 |
@josiah_wi nothing to do with mingw, it just expects to be able to set various libraries directly. these same options are also documented in the readme |
| 07:56 |
|
calcul0n_ joined #minetest-dev |
| 10:08 |
|
appguru joined #minetest-dev |
| 10:23 |
Baytuch |
Good evening |
| 10:31 |
MTDiscord |
<Sublayer plank> good day |
| 11:24 |
|
olliy joined #minetest-dev |
| 11:27 |
|
HuguesRoss joined #minetest-dev |
| 11:53 |
MTDiscord |
<Jonathon> @Josiah |
| 12:33 |
|
proller joined #minetest-dev |
| 13:23 |
MTDiscord |
<josiah_wi> sfan5, I tried to support that, I don't understand yet why my fix doesn't work. I added those variables to the PATHS to search; am I missing something? |
| 14:02 |
|
appguru joined #minetest-dev |
| 14:19 |
|
ShadowBot joined #minetest-dev |
| 14:44 |
|
appguru1 joined #minetest-dev |
| 14:49 |
|
Fixer joined #minetest-dev |
| 15:27 |
sfan5 |
not sure what exactly PATHS does but note that the variables contain exact file paths, not folders to search |
| 15:42 |
|
SOMBRIO joined #minetest-dev |
| 16:10 |
|
v-rob joined #minetest-dev |
| 16:20 |
|
Taoki joined #minetest-dev |
| 17:11 |
|
v-rob joined #minetest-dev |
| 17:13 |
|
Fixer joined #minetest-dev |
| 18:03 |
|
fluxionary joined #minetest-dev |
| 18:25 |
MTDiscord |
<luatic> https://forum.minetest.net/viewtopic.php?f=6&t=27616 - is anybody able to confirm this? |
| 18:25 |
|
Wuzzy joined #minetest-dev |
| 18:26 |
MTDiscord |
<Jonathon> cant confirm, but it was brought up in the past |
| 18:30 |
fluxionary |
is there a way to get wireshark to re-assemble "split" packets and parse what's in them? (using the minetest plugin) |
| 18:31 |
Wuzzy |
Is it normal that minetest.set_mapgen_setting does not actually set the mapgen setting after launch? |
| 18:32 |
Wuzzy |
Try this test code in a test mod and start MTG: minetest.set_mapgen_setting("mgv6_spflags", "nomudflow,nosnowbiomes,notrees,nojungles") |
| 18:32 |
MTDiscord |
<Jonathon> its per world, not global |
| 18:32 |
Wuzzy |
no. |
| 18:32 |
Wuzzy |
it does literally nothing |
| 18:32 |
Wuzzy |
not even per-world |
| 18:32 |
rubenwardy |
you need to pass `true` to override |
| 18:32 |
rubenwardy |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L5306 |
| 18:33 |
rubenwardy |
according to the docs |
| 18:33 |
Wuzzy |
but this doesn't make sense. it's a NEW world oO |
| 18:33 |
rubenwardy |
I think 5.5.0 writes those settings directly to the file |
| 18:33 |
rubenwardy |
this override param is weird |
| 18:33 |
rubenwardy |
set mapgen setting should set it... |
| 18:34 |
Wuzzy |
by that logic, the only way to call this function correctly for ANY mapgen setting is to set overrride_meta to true... *shrug* |
| 18:34 |
Wuzzy |
this is strange |
| 18:34 |
Wuzzy |
also, won't override_meta force the mapgen setting on existing worlds as well? |
| 18:34 |
Wuzzy |
what if i change the mapgen setting in future? This will lead to map breakage |
| 18:34 |
Wuzzy |
right? |
| 18:35 |
Wuzzy |
but ok, I can set override_meta anyway, my game is still in alpha, so who cares? ? |
| 18:35 |
Wuzzy |
it "works" but it feels wrong :/ |
| 18:35 |
Wuzzy |
I feel like the docs only tell half of the story. there is somehing missing |
| 19:18 |
Krock |
will merge #12037, #12025, #12046 and #12029 in 10 minute |
| 19:19 |
Krock |
shadowbot do be dead sometimes |
| 19:20 |
Krock |
Wuzzy: yes, that API sucks but it used to be similar if not identical in earlier MT versions |
| 19:21 |
Wuzzy |
at least i deployed a hotfix now |
| 19:21 |
erlehmann |
wasn't there a change for the world creation dialog bc setting it in one game set it for other games? |
| 19:22 |
erlehmann |
i forgot how it was handled, but given how refactorings or fixes sometimes touch related stuff for convenience, i'd look there first |
| 19:23 |
rubenwardy |
Already mentioned, erlehmann |
| 19:24 |
erlehmann |
Krock 12037 is something we have waited for a long time in mineclonia. lots of games do this wrong! thank |
| 19:24 |
rubenwardy |
Oh, in #minetest |
| 19:25 |
Krock |
erlehmann: then propose patches to fix those games. it's not minetest's job |
| 19:26 |
sfan5 |
commented on 12037 with a suggestion |
| 19:26 |
Krock |
did too |
| 19:27 |
erlehmann |
Krock imo engine should warn in this case in debug builds, bc otherwise ppl do not realize that they have insanely wasteful globalsteps set up. what do you think? |
| 19:28 |
Krock |
that's the profiler's task |
| 19:28 |
Krock |
merging the 3 other PRs |
| 19:28 |
erlehmann |
oh, i did not konw the profiler can warn you about doing no-ops! let's continue it in #minetest then |
| 19:29 |
rubenwardy |
Disagree, the engine should track changes and batch updates |
| 19:29 |
rubenwardy |
More of a problem with object properties |
| 19:29 |
Krock |
done |
| 19:30 |
Krock |
I'd rather opt for incremental updates |
| 19:30 |
Krock |
as for HUD flags there's no point due to low data |
| 19:31 |
rubenwardy |
That's can be done nicely with batch updates |
| 19:31 |
rubenwardy |
Send a package with a series of opcodes and values. Opcode=0 sets object id, other opcodes set properties |
| 19:31 |
rubenwardy |
*packet |
| 19:32 |
sfan5 |
question is how much more work is that |
| 19:33 |
erlehmann |
Krock we have actually debugged this in mineclonia and the amount of packets is the problem, not the payload https://git.minetest.land/Mineclonia/Mineclonia/issues/111 |
| 19:33 |
sfan5 |
not necessary to implement but to maintain e.g. if you want to add a new one |
| 19:33 |
Krock |
yes I know |
| 19:33 |
Krock |
too many packets may clutter the queue |
| 19:34 |
erlehmann |
now that i see it: https://github.com/minetest/minetest/issues/11459 can prob be closed if you merge #12037 ig |
| 19:34 |
Krock |
no |
| 19:34 |
Krock |
this is about HUD elements, and not flags |
| 19:35 |
|
Yad joined #minetest-dev |
| 19:36 |
erlehmann |
oh sorry then |
| 19:37 |
rubenwardy |
The add a new one, you'd extend the switch. You'd only send opcodes to clients that support it |
| 19:37 |
rubenwardy |
Are object property updates multicast? |
| 19:37 |
rubenwardy |
because you'd need to send per-client. Or at least per protocol version |
| 19:38 |
rubenwardy |
otherwise you'd need someway of encoding length |
| 19:39 |
Krock |
yes, multicast because it contains collision box and selection box information |
| 19:39 |
MTDiscord |
<Jonathon> the problem i have with not sending flags/properties/etc if the same is sometimes its necessary to work around broken parts of the engine |
| 19:39 |
Krock |
and all other visuals |
| 19:39 |
rubenwardy |
I don't see why that requires multicast |
| 19:39 |
erlehmann |
just so i understand it: right now, what is preventing the engine from just not sending anything if an object property is set but it already has that same value? that someone might not be in range and then come in range or something? |
| 19:39 |
rubenwardy |
by multicast, I mean the same packet content sent to subscribed players |
| 19:39 |
rubenwardy |
rather than a packet per player |
| 19:39 |
erlehmann |
Jonathon which kind of broken parts? they should have to be fixed first |
| 19:39 |
Krock |
rubenwardy: if one updates, all clients must be aware of it |
| 19:40 |
rubenwardy |
you can do that as a packet per player, rather than a multicast |
| 19:40 |
Krock |
https://github.com/minetest/minetest/blob/master/src/object_properties.cpp#L119 |
| 19:40 |
rubenwardy |
but you can lose some performance - but you gain performance with batching and incremental updates |
| 19:40 |
Krock |
except that there's currently no way of marking this stuff as dirty |
| 19:40 |
rubenwardy |
yeah that would be needed |
| 19:41 |
erlehmann |
ohhh, i get it. damn. |
| 19:41 |
Krock |
1 bit per parameter.. this would be feasible |
| 19:41 |
rubenwardy |
yeah, a bitset |
| 19:42 |
Krock |
although it may get out of hand very quickly. int128 needed, if not more to be future-proof |
| 19:42 |
rubenwardy |
doesn't need to be future proof, as it's not part of the network |
| 19:42 |
rubenwardy |
just use std::bitset |
| 19:42 |
Krock |
it is literally the network |
| 19:42 |
rubenwardy |
you don't need to send modified bit flags |
| 19:42 |
erlehmann |
well if you are not sending anything bc nothing is dirty, nothing is part of the network? |
| 19:42 |
Krock |
how would you let the clients know of updated fields? |
| 19:43 |
Krock |
there must be a scheme to it |
| 19:43 |
rubenwardy |
<+rubenwardy> Send a packet with a series of opcodes and values. Opcode=0 sets object id, other opcodes set properties |
| 19:43 |
Krock |
it's exactly that |
| 19:43 |
Krock |
except that you've got bitfields rather than opcodes |
| 19:43 |
rubenwardy |
enum class ObjectPropertyId { OBJECT_ID=0, VISUAL_SIZE=1, TEXTURE=2 } |
| 19:43 |
rubenwardy |
you don't want bitfields, that's wasteful |
| 19:43 |
sfan5 |
bitfields are a better design if you often set multiple at once |
| 19:43 |
Krock |
not if stuff updates in bulk |
| 19:44 |
rubenwardy |
right |
| 19:44 |
erlehmann |
i guess it's time to gather some realworld data on how object property network spam actually looks like |
| 19:45 |
erlehmann |
any way i can assist there? |
| 19:45 |
Krock |
in this case it's less spam, and more data amount |
| 19:45 |
rubenwardy |
for bitfields to be worth it, you need to send more than 16 changed fields on average |
| 19:46 |
rubenwardy |
assuming 16 byte (128bit) bitset vs 1 byte opcode |
| 19:46 |
Krock |
there'c approx. 40 frields currently |
| 19:46 |
erlehmann |
someone who knows go could prob use the anon5 lib to make a proxy to measure this tbh |
| 19:46 |
Krock |
*fields |
| 19:47 |
sfan5 |
you can easily make some tradeoffs and do one bitfield per 8 properties |
| 19:47 |
Krock |
that's definitely not me who would do that. also wireshark could do that too |
| 19:47 |
erlehmann |
https://github.com/anon55555/mt |
| 19:47 |
sfan5 |
in which case a bitfield is always equally or more efficient even at 1 op |
| 19:47 |
erlehmann |
Krock i believe the dissector is not up to the task rn or is it? |
| 19:48 |
Krock |
erlehmann: not quite, but for packet sizes and occurrences it should suffice |
| 19:50 |
|
v-rob joined #minetest-dev |
| 19:53 |
erlehmann |
Krock i am *very* sceptical of having an opinion in the bitfield vs opcode debate without some actual data on the issue – and given that packet spam has not been solved in years, there seems to be no hurry. i'll read up a bit on dissectors now. |
| 20:23 |
|
behalebabo joined #minetest-dev |
| 20:33 |
|
x2048 joined #minetest-dev |
| 20:48 |
MTDiscord |
<josiah_wi> sfan5, thank you very much, that explains what the issue is. |
| 20:55 |
|
v-rob joined #minetest-dev |
| 21:29 |
|
SOMBRIO joined #minetest-dev |
| 21:34 |
|
v-rob joined #minetest-dev |
| 21:50 |
|
jordan4ibanez joined #minetest-dev |
| 21:58 |
|
x2048 joined #minetest-dev |
| 22:45 |
|
v-rob joined #minetest-dev |
| 22:58 |
MTDiscord |
<luatic> Don't object properties have the same issue of unnecessary resending? |
| 23:14 |
|
proller joined #minetest-dev |
