Time Nick Message 08:20 [MTMatrix] Reminder to vote for the new name 08:35 sfan5 Blocky McBlockface 09:54 MTDiscord Mine n Test 09:55 MTDiscord The slogan: Code, mine, crash, repeat 11:37 MTDiscord I was thinking through ways we could speed up AABB math in general for us. I have two ideas, curious other's thoughts: 1. SIMD/NEON 2. One large bounding box for entities/node box nodes, that represents the maximum extent, and only check that one box before diving through all the AABBs of a given object 12:23 MTDiscord If SIMD/NEON: Google/highway is a solid cross platform option. If bounding box method: that's just standard coding. 14:41 MTDiscord C++ compilers should automatically vectorize with the appropriate compile flags; the code "just" needs to be written in such a way that the compiler knows that vectorization is admissible. 15:45 MTDiscord New name? 15:45 MTDiscord @Lars in 2024, compilers are still pretty bad at vectorization, let alone loop optimizations 16:36 nekobit https://files.catbox.moe/yo8jkl.png 16:36 nekobit what is content.id? 16:36 nekobit the function im rewriting doesn't seem used within pkgmgr.cpp anyway 16:36 nekobit ah, its used elsewhere 17:38 MTDiscord nekobit: I don't expect compilers to magically do all the work, but if you serve it to them on a silver platter, I imagine they should be able to emit the proper instructions. I just threw together a trivial example (vector addition): https://godbolt.org/z/af8v4zzen. As you can see, it uses SIMD. 17:41 MTDiscord In other words, if the logic is written in exactly the right way, I don't necessarily see a need to drag in a dependency like google/highway. While it may have advantages, it is certainly not obvious that this would be the way to go. 18:28 MTDiscord There was a simple case where if you set a loop to loop by 2 and then set a variable at an index to a value, simd wouldnt kick in 18:28 MTDiscord its pretty simple to replicate 19:10 MTDiscord You can manually vectorize if needed. 19:11 MTDiscord Like dropping down to ASM but still slightly more abstracted. 20:48 nekobit So, was looking at adding the settings button the pause menu 20:48 nekobit It would appear certainly that the menu is all lua though... 20:48 nekobit wonder if maybe i could call it from C++ instead of rewriting it? 20:50 nekobit or, preferably, move the pause menu to Lua instead 20:59 nekobit I am pretty sure i found a memleak, unless drop() somehow calls the destructor 21:05 sfan5 that's exactly what drop does 21:47 MTDiscord lol 22:06 nekobit Well, it looks like a C++ rewrite of settings might be easier, since the mainmenu Lua is deloaded in the game 22:11 MTDiscord just have client modding be enabled? I hope it would be ok for that to be enabled for builtin no matter what the server says 22:11 nekobit rollerozxa: Yes but there's no Lua stack I can work with 22:13 nekobit at least in game.cpp, which is where the pause stuff is at 22:14 MTDiscord ah. hm, for my proof of concept I had the whole pause menu reimplemented in lua, which was done more or less how the CSM death menu is used when client modding is enabled rather than the one in C++ 22:15 nekobit Did you call the lua from C++ though? 22:15 nekobit or was it all lua? 22:16 nekobit showDeathFormspec is also c++ 22:16 MTDiscord yes, I called a lua callback from C++. look at the code for the death screen which should be somewhere nearby 22:17 nekobit the death screen isn't doing that 22:19 MTDiscord https://github.com/minetest/minetest/blob/fb6ceb2664949372a871b15be853e11a0c3f5aee/src/client/game.cpp#L2882 22:20 nekobit yeah i saw that 22:20 nekobit but its still handled in c++ otherwise 22:21 MTDiscord yes but when client modding is enabled it will call lua 22:22 MTDiscord so this is what you would want to do to get the settings dialog up 22:22 MTDiscord with the inplication being that client modding will always be enabled for builtin from now on, hopefully 22:25 nekobit Ahh, that's where the Lua stuff is 22:28 nekobit Awesome. Multiple inheritence. Great code everyone. 22:28 Mantar lol 23:04 nekobit rollerozxa: well, i've had zilch luck in getting Lua to work well. I don't think the efforts are worth it. Its probably easier to just rewrite the settings in C++, considering its only 700 loc and the majority of that is just formspec stuff and core calls (which just wrap c++ calls anyway) 23:05 nekobit i think i had drikn too much maybe so i could be just stupid 23:07 nekobit One thing im stumped on is that all the gui/...cpp files aren't formspecs. They are actual irrlicht calls 23:07 MTDiscord formspecs is just a wrapper over irrlicht gui 23:08 nekobit I figured as such, but to make my port cleaner i'd just rather use formspec, however, with the way things are modeled, it seems difficult to do consistently 23:16 nekobit wsor4035: Do you think rewriting a formspec menu into just raw irrlicht calls would be difficult? 23:16 nekobit From what I see, they seem pretty similar 23:18 MTDiscord probably not, dunno why would would want to however 23:22 MTDiscord *one would 23:23 nekobit well im not seeing how i would use a GUIModelMenu to do this