| Time |
Nick |
Message |
| 00:30 |
|
Sharpman joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 08:20 |
[MTMatrix] |
<Zughy> Reminder to vote for the new name |
| 08:35 |
sfan5 |
Blocky McBlockface |
| 09:54 |
MTDiscord |
<jordan4ibanez> Mine n Test |
| 09:55 |
MTDiscord |
<jordan4ibanez> The slogan: Code, mine, crash, repeat |
| 11:18 |
|
Sharpman joined #minetest-dev |
| 11:23 |
|
swift110-mobile joined #minetest-dev |
| 11:37 |
MTDiscord |
<exe_virus> 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 |
<exe_virus> If SIMD/NEON: Google/highway is a solid cross platform option. If bounding box method: that's just standard coding. |
| 13:13 |
|
basxto joined #minetest-dev |
| 14:41 |
MTDiscord |
<luatic> 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:42 |
|
fluxionary_ joined #minetest-dev |
| 15:45 |
MTDiscord |
<ipeeonwomenbecauseithinkitsfunny> New name? |
| 15:45 |
MTDiscord |
<ipeeonwomenbecauseithinkitsfunny> @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:18 |
|
JCM joined #minetest-dev |
| 17:24 |
|
JCM joined #minetest-dev |
| 17:31 |
|
SFENCE joined #minetest-dev |
| 17:31 |
|
JCM joined #minetest-dev |
| 17:38 |
MTDiscord |
<luatic> 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 |
<luatic> 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. |
| 17:48 |
|
JCM joined #minetest-dev |
| 17:48 |
|
fluxionary joined #minetest-dev |
| 18:22 |
|
JCM joined #minetest-dev |
| 18:28 |
MTDiscord |
<ipeeonwomenbecauseithinkitsfunny> 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 |
<ipeeonwomenbecauseithinkitsfunny> its pretty simple to replicate |
| 19:00 |
|
JCM joined #minetest-dev |
| 19:08 |
|
JCM joined #minetest-dev |
| 19:10 |
MTDiscord |
<josiah_wi> You can manually vectorize if needed. |
| 19:11 |
MTDiscord |
<josiah_wi> Like dropping down to ASM but still slightly more abstracted. |
| 19:15 |
|
JCM joined #minetest-dev |
| 19:19 |
|
JCM joined #minetest-dev |
| 19:22 |
|
JCM joined #minetest-dev |
| 19:27 |
|
JCM joined #minetest-dev |
| 19:36 |
|
fluxionary joined #minetest-dev |
| 19:36 |
|
JCM joined #minetest-dev |
| 19:53 |
|
JCM joined #minetest-dev |
| 20:33 |
|
JCM joined #minetest-dev |
| 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:06 |
|
JCM joined #minetest-dev |
| 21:37 |
|
JCM joined #minetest-dev |
| 21:47 |
MTDiscord |
<theidealist> lol |
| 22:03 |
|
JCM joined #minetest-dev |
| 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 |
<rollerozxa> 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 |
|
JCM joined #minetest-dev |
| 22:13 |
nekobit |
at least in game.cpp, which is where the pause stuff is at |
| 22:14 |
MTDiscord |
<rollerozxa> 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 |
<rollerozxa> 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 |
<rollerozxa> 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 |
<rollerozxa> yes but when client modding is enabled it will call lua |
| 22:22 |
MTDiscord |
<rollerozxa> so this is what you would want to do to get the settings dialog up |
| 22:22 |
MTDiscord |
<rollerozxa> 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 |
| 22:33 |
|
panwolfram joined #minetest-dev |
| 22:47 |
|
JCM joined #minetest-dev |
| 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 |
|
Eragon joined #minetest-dev |
| 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 |
<wsor4035> 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 |
<wsor4035> probably not, dunno why would would want to however |
| 23:21 |
|
JCM joined #minetest-dev |
| 23:22 |
MTDiscord |
<wsor4035> *one would |
| 23:23 |
nekobit |
well im not seeing how i would use a GUIModelMenu to do this |
| 23:55 |
|
JCM joined #minetest-dev |
