Time Nick Message 00:01 MTDiscord I've got a fully working (last I checked) rpi 2b, but I think shipping it from the other side of the pond would cost as much as just buying a new one 00:02 MTDiscord I also don't think that it'd necessarily play MT at all, the 2B was not powerful enough for much graphically iirc 00:02 MTDiscord that might have changed with driver improvements ofc 00:04 erlehmann how weak does a graphics chip have to be though 00:05 erlehmann i mean to not run minetest 00:10 MTDiscord I guess that depends on the game 00:15 Pexin doesnt matter. wont have enough ram. also the arch is quite different between 2 and 3 00:15 Pexin 2 i believe has same arch as zero 00:16 Pexin i have a zerow that i only use for snes/etc emulation. it's not even enough to stream most video 00:21 MTDiscord Yeah, my RPI 3B just barely runs minetest at about 4 fps 00:22 erlehmann oof 00:22 erlehmann and i thought my Thinpkad is underpowered 00:23 MTDiscord I think the 4B would serve you better 00:23 Pexin it "might" be possible to optimize MT for 3B+, I wouldn't know about that 00:23 Pexin still would probably be unpleasant 00:23 Pexin and still have ram limitation 00:23 rubenwardy I believe that the Pi 4 is the first version with an iGPU, previous versions use software emulation 00:24 MTDiscord List of settings to change: turn down the view range, disable shaders, disable smooth lighting... and anything else you can find. 00:24 MTDiscord Also, use a small texture pack such as the 8x texturepack 00:26 MTDiscord RE: RPI processors. rubenwardy: I suppose that would improve the performance quite a bit? 00:26 rubenwardy yeah, I've heard it performs very well on pi4 00:26 MTDiscord Great, I might have to get one of those here soon... 00:28 MTDiscord Is it worth it to get the extra RAM? 00:29 MTDiscord Maybe, if you can get one at all 00:29 MTDiscord Chip shortage and all that 00:30 MTDiscord Yeah, I noticed that, I was shopping just now and all of them are sold out at every store I checked. 00:31 MTDiscord Wow, the Zero 2 W is also completely sold out.' 02:37 MTDiscord Now that we have zstd in minetest, another real performance gain might be possible: dictionaries. They should allow faster compression and decompression times while also decreasing disk usage. I wanted to test this idea manually to see how much compression we could get, but I'm running into an issue with the dumped binary mapblocks. Specifically they have some junk tagged on at the end after the zstd compressed mapblock that is 02:37 MTDiscord messing with zstd decompression. Anyone here have a suggestion on how to force zstd to ignore the stuff after the compressed data like we do in src/MapBlock:Deserialize? 02:50 MTDiscord A better question: why the hell do we write the 4 byte length and some random more_count bytes at the end of each "compress"? https://github.com/minetest/minetest/blob/04bd253390cc6c67a555e4837e7e48d524fdf014/src/serialization.cpp#L321 03:05 MTDiscord Okay first question I may have an answer to: we use decompress stream, which expects junk afterwards, which we abuse 03:06 MTDiscord so I need to make a small utility program that does just that and outputs to a file 03:49 MTDiscord Wait a minute.... do we store compressed data backwards??? 03:49 MTDiscord Looking at the bytes, I should see a zstd frame header in HEX of FD 2F B5 28 03:50 MTDiscord I see that in these blocks, at the beginning, in reverse order... 03:50 MTDiscord Aha. we must be concatenating the version number to every block 03:50 MTDiscord 1d = 29 03:51 MTDiscord so... just gotta remove that... lua here I come 04:14 MTDiscord works! Now: looking at these blocks, they all have magic numbers to start them. I.E. in our case a wasted 4 bytes for every block. I generated about 40,000 blocks in 2 minutes of fast fly, so that would amount to 156 KB, of the total 15.5 MB, so a free 1% reduction. Mostly important for empty blocks (air). 04:15 MTDiscord next up: dictionaries... after bed time 05:35 MTDiscord is there an idiots guide to what each perlin setting does 05:46 MTDiscord no, minetest documentation is exclusively overcomplicated 07:07 ROllerozxa @fatalerror420 if you feel so strongly you maybe want to join #minetest-docs :) 07:19 ROllerozxa anyways I actually do have a raspberry pi 4B but unfortunately it's busy being a server 07:22 ROllerozxa however in terms of pi performance, back when I first got it I tried playing super tux kart on it and it ran fairly well on medium settings. dunno how well minetest would run though, never tried it 07:31 MTDiscord Test 07:49 celeron55 erlehmann: in all of the raspberry pis if you use a cheap phone charger you tend to get sd card corrruption in the long term 07:49 erlehmann oh, *that* is the reason 07:50 erlehmann i thought sd cards were just shitty storage anyway 07:50 erlehmann bc i had issues with them even in properly powered devices (that were not rpi) 07:50 celeron55 the rest of the pi can handle the sagging voltage but sd cards don't like it, afaik 07:51 erlehmann i see. good to know! 07:51 celeron55 well you do need to use a good card also, cheap ones are pretty much disposable items 08:13 sfan5 "why the hell do we write the 4 byte length and some random more_count bytes at the end of each "compress"?" <- you're looking at the ancient implementation of RLE compression, this code doesn't even run 10:47 MTDiscord I wouldn't bump mapblock versions just to strip off a 4 byte magic number. 1% seems like a micro-optimization to me. 10:58 celeron55 1% is clearly a centi-optimization. 0.0001% would be micro! 10:59 erlehmann technically correct, the best kind of correct 10:59 erlehmann is desour here with another name maybe? can not see in the list 11:46 MTDiscord Yes 1% is not worth it, but that plus dictionaries probably will be, but first I must test. 20:09 lhofhansl Anybody with some spare cycles to look at #11747? 20:09 ShadowBot https://github.com/minetest/minetest/issues/11747 -- Render shadows on entities. by x2048 20:12 lhofhansl Also, and more importantly, does anybody know how x2048 is doing? (I think she/he is from Russia or Ukraine) 20:24 erlehmann lhofhansl, i do not know x2048, but last connections i have logged come from 94.147.132.50, which is AS9158 telenor A/S in denmark 20:25 lhofhansl Ok thanks. 20:27 erlehmann i see why you are concerned though, last github activity seems from shortly before the war. i hope it is just coincidence. 20:28 erlehmann for future reference, i mean this comment https://github.com/minetest/minetest/pull/11696#issuecomment-1049237139 20:36 MTDiscord @x2048 people are burying you 20:43 x2048 Guys, I'm all fine. But I had to adjust my priorities because of what happens in Ukraine, yes. 20:48 lhofhansl Great! 20:48 MTDiscord good luck 20:49 x2048 savilli: Thank you 21:55 v-rob Ooh, we're using C++14 now 21:57 v-rob I do like make_unique 22:56 x2048 Planning to merge #11747 and always wanted to ask: Is it fine to merge anytime, just drop a line, or is it better to merge at certain times to have more coredevs online? 22:56 ShadowBot https://github.com/minetest/minetest/issues/11747 -- Render shadows on entities. by x2048 22:56 x2048 (In case any coredev is still online...) 23:36 MTDiscord has a self approve, and another approve, so satisfies two core dev approval, typically announce moging to merge x pr in y minutes in irc 23:39 x2048 It just feels wrong to announce "merging in Y minutes" at, say, 00:30 CET when no one is online anyway for a few hours. 23:40 MTDiscord sfan5 and rubenwardy may? be up this late, dunno about the rest 23:48 erlehmann this whole merging in X minutes thing seems really weird to me