Time Nick Message 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:05 MTDiscord 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 I can walk you through debugging it sometime, but it might not be a quick thing to do. 01:19 MTDiscord 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. 04:19 MTDiscord Minetest 5.5 crashes on android from f-droid 04:19 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/944810365391372439/screen-20220219-231654.mp4 04:20 MTDiscord Looks like we need a 5.5.1 android release lol 04:21 MTDiscord its already known that 5.5 crashes on some android devices 04:21 MTDiscord 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 also that 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? 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* 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: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:42 MTDiscord 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 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 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 could it be that MT does one drawcall per inventory item? 22:05 MTDiscord 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 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 this is nothing 22:06 MTDiscord pretty sure this is some kind of drawcall limitation 22:10 MTDiscord 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 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 I implemented this too, but using a lazy-loading texture modifier 22:29 proller https://github.com/minetest/minetest/pull/11910 22:30 MTDiscord 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 "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 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 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 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 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 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: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 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 the naming is odd IMO 22:42 MTDiscord I have already pointed this out, but this way it should be ocoord and v3ocoord 22:42 MTDiscord 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 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 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:09 twrightsman[m] luatic: great, thank you 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