| Time |
Nick |
Message |
| 00:11 |
|
AliasAlreadyTake joined #minetest-dev |
| 00:42 |
erlehmann |
i have once again gotten into a state where cmake can not do a full rebuild. can anyone tell me how to get cmake to do that? |
| 00:46 |
sfan5 |
"can not do a rebuild" = ? |
| 00:47 |
sfan5 |
either way find . -name '*.o' -delete probably goes a long way |
| 00:50 |
erlehmann |
thx |
| 01:01 |
|
Baytuch_2 joined #minetest-dev |
| 01:05 |
MTDiscord |
<josiah_wi> Delete the build dir when that happens. If you aren't building out of source then you should be. |
| 01:08 |
erlehmann |
josiah_wi i am trying to understand *why* it happens |
| 01:14 |
MTDiscord |
<josiah_wi> I can walk you through debugging it sometime, but it might not be a quick thing to do. |
| 01:19 |
MTDiscord |
<josiah_wi> What's the symptom? Does it crash during the configure step? If it crashes during configuration it's probably a Minetest bug. If it's a non-existence dependency problem it's a CMake limitation. |
| 01:22 |
|
Sokomine joined #minetest-dev |
| 01:59 |
|
olliy joined #minetest-dev |
| 02:26 |
|
v-rob joined #minetest-dev |
| 03:23 |
|
v-rob joined #minetest-dev |
| 04:19 |
MTDiscord |
<MisterE> Minetest 5.5 crashes on android from f-droid |
| 04:19 |
MTDiscord |
<MisterE> https://cdn.discordapp.com/attachments/747163566800633906/944810365391372439/screen-20220219-231654.mp4 |
| 04:20 |
MTDiscord |
<MisterE> Looks like we need a 5.5.1 android release lol |
| 04:21 |
MTDiscord |
<Jonathon> its already known that 5.5 crashes on some android devices |
| 04:21 |
MTDiscord |
<Jonathon> pretty sure ruben stopped the role out on gplay due to high number of issues |
| 04:23 |
rubenwardy |
f-droid also doesn't have 5.5 |
| 04:24 |
MTDiscord |
<Jonathon> also that |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:07 |
|
tekakutli joined #minetest-dev |
| 07:20 |
|
calcul0n joined #minetest-dev |
| 08:20 |
|
tekakutli joined #minetest-dev |
| 08:41 |
|
calcul0n joined #minetest-dev |
| 09:39 |
|
Fixer joined #minetest-dev |
| 10:55 |
|
YuGiOhJCJ joined #minetest-dev |
| 11:07 |
|
proller joined #minetest-dev |
| 11:35 |
|
HuguesRoss joined #minetest-dev |
| 12:11 |
erlehmann |
hey, I wanna speed up media loading time by a lot by making the cache a tiny bit smarter. where can i save a bit of additional data ideally? |
| 12:17 |
|
tekakutli joined #minetest-dev |
| 13:30 |
|
tekakutli joined #minetest-dev |
| 13:31 |
|
troller joined #minetest-dev |
| 14:05 |
|
troller joined #minetest-dev |
| 14:15 |
|
olliy joined #minetest-dev |
| 15:44 |
|
troller joined #minetest-dev |
| 16:15 |
erlehmann |
rubenwardy the rumble CSM works really fine. do you see a possibility to move such functionaility to minetest proper? basically, talk websockets on localhost if a config option is enabled? |
| 16:16 |
rubenwardy |
Sounds like a security risk when CSM isn't even supported |
| 16:16 |
rubenwardy |
I would like engine support for rumble |
| 16:16 |
erlehmann |
oh, what i'm saying is that *the engine* should do it |
| 16:16 |
rubenwardy |
When we introduce better support for controllers |
| 16:16 |
erlehmann |
why wait? |
| 16:17 |
erlehmann |
i mean curl is already available |
| 16:17 |
rubenwardy |
How we do controllers is likely to effect this |
| 16:17 |
erlehmann |
i do not understand in what ways. |
| 16:19 |
erlehmann |
to be clear: right now, damage is hooked. i.e. you get x damage, you will get a vibration of x seconds length for x/20 of the maximum strength of what the motor gives. it stops at death (or so is the idea). |
| 16:20 |
erlehmann |
i have no idea right now where a controller comes into play |
| 16:20 |
erlehmann |
i mean, i thought about hooking the item use on tnt, to have a short and strong vibration when it explodes |
| 16:20 |
erlehmann |
but that is controller-independent |
| 16:20 |
erlehmann |
also the user might be out of the blast radius |
| 16:21 |
erlehmann |
it would also encourage griefing ^^ |
| 16:21 |
erlehmann |
if you can give me an idea about controllers i can see if i want to work on it |
| 16:22 |
erlehmann |
but to me this is strictly *feedback* and not *control* |
| 16:48 |
|
Taoki joined #minetest-dev |
| 16:58 |
|
Yad_ joined #minetest-dev |
| 17:23 |
|
Baytuch joined #minetest-dev |
| 17:26 |
|
appguru joined #minetest-dev |
| 17:27 |
erlehmann |
as promised, i have made more test nodes for devtest |
| 17:27 |
erlehmann |
and i may have found a png handling error :) |
| 17:28 |
erlehmann |
https://mister-muffin.de/p/j9jE.png |
| 17:28 |
erlehmann |
the textures should all look the same (except for the numbers) but do not |
| 17:30 |
erlehmann |
i have tested this in 5.4.1 (because of the build error), but anyways, it can also be used to diagnose individual monitor gamma errors |
| 17:30 |
erlehmann |
so it's useful even if the png handling has been fixed |
| 17:45 |
|
kilbith joined #minetest-dev |
| 17:57 |
erlehmann |
HuguesRoss here, more devtest nodes! (i plan to use these to find more bugs) https://github.com/minetest/minetest/pull/12089 |
| 18:05 |
ROllerozxa |
re: png handling error, what's the difference between the textures in the screenshot? I can't notice it... >.> |
| 18:05 |
ROllerozxa |
i.e. the handling error |
| 18:17 |
erlehmann |
ROllerozxa leftmost textures have a bigger dark bar |
| 18:17 |
erlehmann |
ROllerozxa look at the bottom left 0.4 texture and at the 1.0 texture right of it |
| 18:18 |
erlehmann |
ROllerozxa you see it now? there should be a gradient |
| 18:18 |
ROllerozxa |
ohh, I see now |
| 18:19 |
ROllerozxa |
is that some sort of bit depth issue? |
| 18:19 |
erlehmann |
no, gamma correction failure |
| 18:19 |
erlehmann |
gamma correction is probably wrongly or not at all applied to at least some textures |
| 18:20 |
erlehmann |
i have not debugged it |
| 18:20 |
erlehmann |
i only noticed the issue |
| 18:20 |
erlehmann |
and decided to make a set of test nodes |
| 18:20 |
erlehmann |
for further debugging |
| 18:32 |
|
Baytuch joined #minetest-dev |
| 18:42 |
MTDiscord |
<luatic> ROllerozxa: it can't be a bit depth issue as the gradient is otherwise working fine |
| 19:47 |
erlehmann |
luatic ROllerozxa how do these look for you http://www.schaik.com/pngsuite2011/pngsuite_gam_png.html |
| 19:49 |
ROllerozxa |
like, in my web browser? |
| 19:50 |
erlehmann |
yes |
| 19:50 |
erlehmann |
funnily enough, the 0.4 picture in the middle row looks *different* in gimp |
| 19:50 |
erlehmann |
in gimp it is just a gradient that is darker |
| 19:51 |
erlehmann |
(it should not be darker though) |
| 19:51 |
erlehmann |
but what i want to say: in gimp, the thing has a gradient |
| 19:51 |
erlehmann |
and it is darker than in the webbrowser and darker than in minetest for me |
| 19:51 |
ROllerozxa |
ok so in firefox I see the same issue on the 0.4 gradients as is seen in minetest |
| 19:52 |
erlehmann |
and in chrome? |
| 19:52 |
erlehmann |
ROllerozxa https://superuser.com/questions/579216/why-does-this-png-image-display-differently-in-chrome-firefox-than-in-safari-a |
| 19:53 |
erlehmann |
ahahaha |
| 19:53 |
erlehmann |
ich should probably make some test textures like that |
| 19:53 |
erlehmann |
that look different depending if gamma is broken |
| 19:54 |
ROllerozxa |
looks the same in chromium |
| 19:55 |
erlehmann |
ROllerozxa try in gimp then |
| 19:55 |
erlehmann |
https://hsivonen.fi/png-gamma/ |
| 19:58 |
ROllerozxa |
...god, why does image formats have to be so damn complicated, why can't PNG just be a zlibbed stream of RGB bytes |
| 19:58 |
ROllerozxa |
anyways it looks the same in GIMP, but it actually looks different in Dolphin's image preview thing |
| 19:58 |
ROllerozxa |
in there the gradient looks proper |
| 19:59 |
|
erlehmann joined #minetest-dev |
| 20:14 |
|
twrightsman[m] joined #minetest-dev |
| 20:43 |
|
YuGiOhJCJ joined #minetest-dev |
| 21:56 |
erlehmann |
on commit 25e25f6e120e1bbf3fb6ebddbb43a2cb467b07d4 (x2048/alpha_blend_indexed), my framerate goes from about 30 to 13 when i look at specific pages in the devtest chest of everything |
| 21:56 |
erlehmann |
(i have it capped at 30) |
| 21:56 |
erlehmann |
this is weird |
| 21:57 |
erlehmann |
30 fps in inventory page 2 https://mister-muffin.de/p/TAWv.png |
| 21:57 |
sfan5 |
it's not weird if it splits transparent stuff into more vertcies |
| 21:58 |
sfan5 |
vertices* |
| 21:58 |
erlehmann |
15 fps in inventory page 3 https://mister-muffin.de/p/6EqG.png |
| 21:59 |
erlehmann |
sfan5 it does not seem like viewing a hand full of nodes in the inventory should be able to cause such a performance drop |
| 21:59 |
erlehmann |
especially because so far i have not been able to reproduce this looking at glass towers behind other glass towers in the world |
| 22:00 |
sfan5 |
if you have hardware that barely keeps up as-is then this may be "expected" behaviour |
| 22:03 |
erlehmann |
wdym |
| 22:03 |
erlehmann |
i see no high cpu load |
| 22:03 |
sfan5 |
gpu???? |
| 22:03 |
erlehmann |
the gpu has not struggled drawing inventory before. or has it? |
| 22:03 |
erlehmann |
is it drawing the nodes itself? |
| 22:03 |
erlehmann |
i really do not understand why it happens in inventory |
| 22:04 |
erlehmann |
maybe you can give me some arrangement of nodes that should render really badly |
| 22:04 |
erlehmann |
but glass behind glass behind glass is not doing it |
| 22:04 |
sfan5 |
of course it's rendering the nodes, the inventory isn't made of pictures |
| 22:04 |
erlehmann |
or i am not placing enough of it |
| 22:04 |
MTDiscord |
<luatic> nodes are rendered, textures can simply be drawn?= |
| 22:04 |
sfan5 |
you should try those nodes on page three of the chest |
| 22:04 |
erlehmann |
ok |
| 22:04 |
MTDiscord |
<luatic> could it be that MT does one drawcall per inventory item? |
| 22:05 |
MTDiscord |
<luatic> because there's still no way - even on ancient handware - that a couple tris should bring stuff down to 15 FPS |
| 22:05 |
sfan5 |
sometimes a couple tris is more like 400 per item |
| 22:05 |
sfan5 |
who knows |
| 22:06 |
MTDiscord |
<luatic> let's calc: 4*8 = 32 slots; assume all nodes - one node has 6 faces a 2 tris - which means 32 * 12 < 400 tris. |
| 22:06 |
MTDiscord |
<luatic> this is nothing |
| 22:06 |
MTDiscord |
<luatic> pretty sure this is some kind of drawcall limitation |
| 22:10 |
MTDiscord |
<luatic> on an entirely different note: the "breaking" part of the breaking world limits PR seems sketchy to me. I understand that compat with 5.x can't be reasonably kept (although erlehmann argues otherwise) - but if a PR refuses to fix the wireshark dissector it breaks if compiled with the flag, that's not fine I think. It also simply casts to the old types in many places and even continues using them in some other places so I doubt that it |
| 22:10 |
MTDiscord |
doesn't break there. |
| 22:10 |
celeron55 |
what are the fpses without the branch in question, i mean does the branch have anything to do with this? |
| 22:11 |
erlehmann |
celeron55 i wonder. i will recompile. |
| 22:11 |
erlehmann |
sfan5 i have not managed to get anything below 17 fps and the 17 fps seem to be a bug (being underwater looking directly at the face of a fancy leave node tanks the frame rate and causes weird z fighing issues) |
| 22:12 |
erlehmann |
leaves |
| 22:12 |
erlehmann |
i think inventory is cursed and will investigate |
| 22:12 |
erlehmann |
regarding barely keeping up, i placed a bunch of water and got the framerate down to 25fps |
| 22:12 |
erlehmann |
maybe i should look at an ocean some time |
| 22:13 |
erlehmann |
framerate only dropped when i was a) in water b) looking at water behind water if their was air in between |
| 22:14 |
MTDiscord |
<luatic> sfan5: regarding basic_debug vs. debug: I called it just "debug" because (1) flags aren't privs and (2) this basically controls all HUD debug info unless overridden by the priv |
| 22:14 |
celeron55 |
the point of the branch is to do extra processing to get transparent stuff like water to be rendered in the correct order (according to the camera's position) |
| 22:14 |
erlehmann |
luatic very confusing |
| 22:14 |
celeron55 |
so... there will be extra processing |
| 22:14 |
celeron55 |
which means less fps |
| 22:15 |
erlehmann |
celeron55 yeah in the world, but not in the inventory |
| 22:15 |
erlehmann |
just in case the extra fps drop makes the game unplayable, where is the simple leaves option to turn it off? |
| 22:15 |
celeron55 |
yes, the inventory doesn't make much sense |
| 22:15 |
celeron55 |
anyway, it could affect it |
| 22:15 |
erlehmann |
or is it like particles, where only cheat clients have a performance option? |
| 22:15 |
erlehmann |
i'll investigate, as i said |
| 22:16 |
celeron55 |
if i'm not mistaken the inventory nodes are drawn as mapblocks so they go through some of the same machinery |
| 22:16 |
celeron55 |
i've forgotten how it works though |
| 22:21 |
celeron55 |
i think it uses client/hud.cpp's drawItemStack() |
| 22:23 |
celeron55 |
i'm probably completely wrong and mixing this up with the wielded item rendering or something |
| 22:24 |
sfan5 |
nah that's correct |
| 22:24 |
sfan5 |
it uses the same mesh that is also used for wield items |
| 22:24 |
sfan5 |
an exception is items with an inventory image: that is drawn as 2D in the inventory (but not in the wieldmesh obviously) |
| 22:25 |
celeron55 |
inb4 erlehmann will add a prerendered inventory image for every node in every game |
| 22:25 |
celeron55 |
it's something i would do if i was targeting the gm945 and a centrino duo |
| 22:26 |
sfan5 |
you may remember that Minetest used to do this |
| 22:26 |
celeron55 |
yes, it did it automatically when loading a game |
| 22:26 |
celeron55 |
and people hated how slow it was |
| 22:27 |
celeron55 |
something about irrlicht's render to texture made it super slow |
| 22:27 |
celeron55 |
i guess it should have rendered many nodes onto a texture and then cut the textures out |
| 22:29 |
MTDiscord |
<luatic> I implemented this too, but using a lazy-loading texture modifier |
| 22:29 |
proller |
https://github.com/minetest/minetest/pull/11910 |
| 22:30 |
MTDiscord |
<luatic> proller: as I have already said before, I'm pretty sure that this breaks too much |
| 22:30 |
proller |
it breaks nothing |
| 22:30 |
MTDiscord |
<luatic> "on an entirely different note: the "breaking" part of the breaking world limits PR seems sketchy to me. I understand that compat with 5.x can't be reasonably kept (although erlehmann argues otherwise) - but if a PR refuses to fix the wireshark dissector it breaks if compiled with the flag, that's not fine I think. It also simply casts to the old types in many places and even continues using them in some other places so I doubt that it |
| 22:30 |
MTDiscord |
doesn't break there." |
| 22:31 |
MTDiscord |
<luatic> it obviously breaks the wireshark dissector (if compiling with the flag) and you have admitted to that? |
| 22:31 |
proller |
do not compile with this flag |
| 22:31 |
proller |
i can remove this flag for you |
| 22:31 |
MTDiscord |
<luatic> so your "solution" is to either leave effectively dead code or a broken flag in there? |
| 22:32 |
proller |
it just type rename |
| 22:33 |
MTDiscord |
<luatic> I'd say you should make it one huge, atomic PR that works, does something (extending world limits) and doesn't break stuff. The entire "part" stuff seems wrong to me. |
| 22:33 |
MTDiscord |
<luatic> I guess I get why you're salami-slicing your PR (to reduce PR size and increase chance for merge?) but merging any of these PRs on it's own seems pretty pointless |
| 22:34 |
MTDiscord |
<luatic> It also is more than "just a type rename" BTW as you have to (down)cast in many places. |
| 22:34 |
proller |
its impossible to make all this task fully working in one pr |
| 22:35 |
proller |
it will be never merged and it will have conflicts with any other pr |
| 22:36 |
proller |
celeron55, may be you can say something? |
| 22:37 |
|
appguru1 joined #minetest-dev |
| 22:40 |
celeron55 |
the PR does make sense to me, but i don't have time to actually review it |
| 22:40 |
celeron55 |
btw, why isn't it called fpos_t and v3fpos_t? |
| 22:40 |
celeron55 |
is that already reserved for something |
| 22:41 |
proller |
o = object |
| 22:41 |
sfan5 |
_t are reserved types in C |
| 22:41 |
sfan5 |
idk if you're referring to that though |
| 22:41 |
MTDiscord |
<luatic> sfan5: renamed to basic debug (although I consider this to be somehow clear from the HUD flag context), you can revert should you ultimately consider just "debug" cleaner |
| 22:41 |
proller |
i can rename types to anything |
| 22:42 |
celeron55 |
i mean when compared to opos_t and v3opos_t |
| 22:42 |
MTDiscord |
<luatic> the naming is odd IMO |
| 22:42 |
MTDiscord |
<luatic> I have already pointed this out, but this way it should be ocoord and v3ocoord |
| 22:42 |
MTDiscord |
<luatic> v3ocoord = opos then |
| 22:43 |
proller |
_t was proposed by nrz |
| 22:44 |
proller |
need to name 3 types: |
| 22:45 |
proller |
node (now pos_t v3pos_t) |
| 22:45 |
proller |
block (bpos_t v3bpos_t) |
| 22:46 |
proller |
object (opos_t v3opos_t) |
| 22:46 |
proller |
just say how it should be |
| 22:46 |
MTDiscord |
<luatic> block = mapblock? |
| 22:46 |
proller |
yes, = node/16 |
| 22:47 |
proller |
also it can be easily renamed in ny moment later |
| 22:57 |
twrightsman[m] |
Is the long-term plan to keep Minetest's Irrlicht fork separate? I ask because I'm making a plan to update Debian's Minetest package to 5.5 and need to figure out if a separate `libirrlichtmt` package is needed |
| 23:01 |
MTDiscord |
<luatic> How would it not be kept separate? irrlichtmt got many file formats etc. irrlicht still supports ripped out, so I doubt that irrlichtmt will ever be merged with irrlicht again |
| 23:02 |
|
Baytuch joined #minetest-dev |
| 23:05 |
|
Yad joined #minetest-dev |
| 23:09 |
twrightsman[m] |
luatic: great, thank you |
| 23:26 |
|
erlehmann joined #minetest-dev |
| 23:32 |
erlehmann |
twrightsman[m], irrlichtmt is basically irrlicht with large parts of it deleted, then some things added. are you trying to figure out if you can maintain it as a patchset on top of normal irrlicht or why the question? |
| 23:34 |
twrightsman[m] |
erlehmann If IrrlichtMt had any plans to eventually merge back upstream then I likely wouldn't bother making a separate package for it in Debian; I wasn't familiar with the scope of the delta so that's also why I asked |
| 23:34 |
erlehmann |
twrightsman[m] given the unwillingness of mt devs to even upstream patches to irrlicht, i also doubt that anything will ever go back. you'll have a bunch of difficulties with the version history though, |
| 23:35 |
erlehmann |
well, basically there is a commit that deletes like 200k lines or so. |
| 23:35 |
twrightsman[m] |
erlehmann I see; well then in any case it seems like a separate package is warranted |
| 23:36 |
erlehmann |
hmm, can i query you? |
| 23:37 |
twrightsman[m] |
What do you mean? |
| 23:37 |
erlehmann |
do you get private messages with your matrix thing? |
| 23:38 |
erlehmann |
or are you here all the time |
| 23:38 |
twrightsman[m] |
DMs seem to work |
| 23:40 |
|
tekakutli joined #minetest-dev |
