| Time |
Nick |
Message |
| 00:12 |
|
Baytuch joined #minetest-dev |
| 00:44 |
|
Baytuch_2 joined #minetest-dev |
| 01:03 |
|
Baytuch_2 joined #minetest-dev |
| 01:13 |
|
Baytuch joined #minetest-dev |
| 01:35 |
|
Baytuch joined #minetest-dev |
| 01:45 |
|
Baytuch joined #minetest-dev |
| 01:56 |
|
Baytuch joined #minetest-dev |
| 02:08 |
|
Baytuch joined #minetest-dev |
| 02:32 |
|
kilbith joined #minetest-dev |
| 02:44 |
MTDiscord |
<Jordach> made an interesting discovery related to perlin noise in the engine |
| 02:53 |
MTDiscord |
<Jordach> 2d noise has near zero impact on speed |
| 02:54 |
MTDiscord |
<Jordach> the Z/X/Y loop to write to the C++ LVM takes approximately 4ms |
| 02:56 |
MTDiscord |
<Jordach> in my own mapgen |
| 02:57 |
MTDiscord |
<Jordach> 6 2d noise sources takes about ~6ms on my system |
| 02:57 |
MTDiscord |
<Jordach> adding 2-3 3d sources whacks that up nearly tenfold |
| 02:57 |
MTDiscord |
<Jordach> as in it has the effective weight of 6 2d noise sources |
| 02:59 |
MTDiscord |
<Jordach> taking closer to 20ms for just two of them |
| 03:55 |
|
tekakutli joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:18 |
|
kilbith joined #minetest-dev |
| 04:30 |
|
tekakutli joined #minetest-dev |
| 04:55 |
MTDiscord |
<MisterE> could you get a pseudo 3d noise by lerp - ing 3 2d noises, one for each plane? That would be 1/2 as expensinve then. |
| 05:23 |
|
calcul0n joined #minetest-dev |
| 05:38 |
|
Baytuch joined #minetest-dev |
| 05:58 |
|
Baytuch joined #minetest-dev |
| 06:22 |
|
Baytuch joined #minetest-dev |
| 06:28 |
|
jonadab joined #minetest-dev |
| 07:02 |
|
Baytuch joined #minetest-dev |
| 07:21 |
|
Baytuch_2 joined #minetest-dev |
| 07:25 |
|
behalebabo joined #minetest-dev |
| 07:27 |
|
Baytuch joined #minetest-dev |
| 07:45 |
|
erle joined #minetest-dev |
| 07:46 |
|
Baytuch joined #minetest-dev |
| 08:21 |
|
Baytuch joined #minetest-dev |
| 09:30 |
|
Baytuch_2 joined #minetest-dev |
| 10:04 |
|
HuguesRoss joined #minetest-dev |
| 11:11 |
|
appguru joined #minetest-dev |
| 11:12 |
|
olliy joined #minetest-dev |
| 11:50 |
|
Baytuch joined #minetest-dev |
| 12:28 |
|
cranezhou joined #minetest-dev |
| 12:43 |
|
erle joined #minetest-dev |
| 12:44 |
|
erle joined #minetest-dev |
| 13:12 |
|
Baytuch joined #minetest-dev |
| 13:17 |
|
Baytuch joined #minetest-dev |
| 13:33 |
|
Noisytoot joined #minetest-dev |
| 13:46 |
|
Baytuch joined #minetest-dev |
| 14:00 |
|
Baytuch joined #minetest-dev |
| 14:07 |
sfan5 |
how are the chances for a second approval on #7629? |
| 14:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/7629 -- Run Minetest update checker on startup by SmallJoker |
| 14:17 |
|
Baytuch joined #minetest-dev |
| 14:19 |
|
proller joined #minetest-dev |
| 14:28 |
kilbith |
if MT makes it to Steam someday, this update checker might conflict with their own I guess |
| 14:35 |
MTDiscord |
<ROllerozxa> it's completely disabled on Android right? |
| 14:36 |
rubenwardy |
it's pretty much only useful on Windows |
| 14:36 |
rubenwardy |
and MacOS. Forgot that existed |
| 14:38 |
|
fluxionary joined #minetest-dev |
| 14:59 |
MTDiscord |
<MisterE> The benefit of c++ mapgen is that it is a separate thread, right? So, would it be useful to have a c++ mapgen called ”script” which runs calls a mapscript.lua which provides the mapgen logic? It would be passed the voxelmanip and would return the map data. Would that be faster than runtime lua mapgen, since it is being called from the c++ thread? sfan5 , @grug brained modder |
| 15:00 |
MTDiscord |
<Jordach> no, that'd still have data type conversion latency worse than native datatypes |
| 15:00 |
|
erle joined #minetest-dev |
| 15:04 |
rubenwardy |
MisterE: sfan5 is working on a multithreaded mapgen API. You wouldn't need a separate file, it would copy the function into the mapgen thread like the async API |
| 15:04 |
MTDiscord |
<MisterE> Oh, we need that |
| 15:07 |
MTDiscord |
<MisterE> That would still be slower than c++ because of the datatype conversions, right? |
| 15:07 |
erle |
rubenwardy could it improve the case that kay27 calls the “chunk-in-shell-grinder” where you gave to emerge a gigantic area to be sure that mapgen does not overwrite it later on? |
| 15:08 |
erle |
s/gave/have/ |
| 15:08 |
rubenwardy |
no |
| 15:08 |
MTDiscord |
<MisterE> No to who |
| 15:08 |
erle |
hehe |
| 15:08 |
rubenwardy |
erle |
| 15:08 |
rubenwardy |
MisterE: it will be slower than C++ more because of the copying than the conversions |
| 15:09 |
MTDiscord |
<MisterE> Could the lua be compiled first, and be as fart a c++? |
| 15:09 |
erle |
MisterE[m] to be fair, all the lua mapgen stuff i have seen that was really slow so far was doing something stupid, e.g. going accidentally quadratic or so |
| 15:09 |
rubenwardy |
erle: overgeneration means that mapgen will write into unloaded neighbour mapblocks for things like caves. Pretty sure it only does this to not use map generated areas |
| 15:09 |
rubenwardy |
MisterE: no, it can't |
| 15:09 |
rubenwardy |
MisterE: but the speed of Lua matters a lot less when it's in another thread |
| 15:10 |
MTDiscord |
<MisterE> Blah, we need fart landscapes |
| 15:10 |
erle |
MisterE[m] even if it could, the amount of reasoning you'd have to do on lua to get it fast is already contained in luajit AFAIK |
| 15:10 |
MTDiscord |
<MisterE> Good to know ruben |
| 15:12 |
erle |
and last i checked, luaJIT was the kind of software where you have only a handful of people that are experts on it and some companies have difficulties paying them large sums of money to meaningfully improve luaJIT because other companies are already paying those people comparable or more money |
| 15:13 |
erle |
MisterE[m] if you have excessively slow mapgen code, putting it on a separate thread is basically giving up on it. not saying threads are not useful, but with synchronous code it really hurts if it is slow, because you notice it a lot. |
| 15:16 |
MTDiscord |
<MisterE> erle. #minetest |
| 15:40 |
sfan5 |
copying memory isn't all that slow |
| 15:40 |
sfan5 |
if done correctly I wouldn't say lua is too slow for mapgen, the main issue is just right now it blocks the main thread |
| 15:41 |
rubenwardy |
slower but not slow |
| 15:41 |
rubenwardy |
but yeah |
| 15:41 |
rubenwardy |
you know what's slow? O(n^2) object collision and movement |
| 15:56 |
|
Yad joined #minetest-dev |
| 16:08 |
erle |
rubenwardy “dynamic shadows for every point light source and i put a lot of torches down” too maybe? ;) |
| 16:09 |
erle |
though that may “only” be a linear increase |
| 16:25 |
|
Baytuch joined #minetest-dev |
| 17:01 |
|
Baytuch joined #minetest-dev |
| 17:30 |
|
Baytuch joined #minetest-dev |
| 17:51 |
|
fluxionary joined #minetest-dev |
| 17:53 |
|
olliy1or joined #minetest-dev |
| 17:55 |
|
Baytuch joined #minetest-dev |
| 19:02 |
sfan5 |
the reason I asked about #7629 earlier is because it'd take about 5 minutes to fix the problems that are left with it |
| 19:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/7629 -- Run Minetest update checker on startup by SmallJoker |
| 19:06 |
|
Baytuch joined #minetest-dev |
| 19:08 |
|
vampirefrog joined #minetest-dev |
| 19:12 |
Krock |
the formspec scaling sucks. making it wider and taller shrinks it back again for some reason |
| 19:12 |
Krock |
either that or I made a mistake when I tried last time |
| 19:14 |
sfan5 |
something with real_coordinates? |
| 19:23 |
Krock |
rebuilding to figure that out... |
| 19:28 |
Krock |
I don't know what happened last time. resizing it works fine now. will update the PR |
| 19:36 |
|
Yad joined #minetest-dev |
| 19:45 |
|
Baytuch joined #minetest-dev |
| 19:49 |
Krock |
sfan5: am I seeing it correctly that HTTP fetch_sync is undocumented? |
| 19:49 |
sfan5 |
could be |
| 19:49 |
sfan5 |
but if it's a main menu api ? |
| 19:50 |
Krock |
oh right! missed that point. it's indeed documented in the right file... |
| 19:50 |
Krock |
I saw there's a timeout setting which could be used to avoid disturbing the clients on laggy connections |
| 19:51 |
Krock |
s/clients/users/ |
| 19:51 |
|
Baytuch joined #minetest-dev |
| 19:51 |
Krock |
so with a timeout of perhaps 2 seconds (fixed), this should be okay for a version checker? |
| 19:52 |
Krock |
asking because I cannot figure out how `if not ui.childlist["maintab"].hidden then` is supposed to work. the main menu is already shown by the time the updater kicks in |
| 19:53 |
|
x2048 joined #minetest-dev |
| 19:58 |
rubenwardy |
the main menu may be hidden by a dialog |
| 19:58 |
erle |
Krock which timeout is this? i vaguely remember that you have a bunch of timeouts for HTTP: at the very least: DNS, TCP, HTTP and for each of them the timeout until a connection has to be established and the timeout until it is deemed stale |
| 19:59 |
rubenwardy |
he's referring to a blocking request when starting up minetest |
| 19:59 |
sfan5 |
it's about putting it in the result callback |
| 19:59 |
sfan5 |
if the mainmenu is hidden by a dialog at that point, don't attempt to show the update message |
| 19:59 |
Krock |
oh I see |
| 20:00 |
erle |
how are TLS errors handled in the updater? think captive portal WLAN (hotel or airport). it better not crash. |
| 20:01 |
erle |
i remember actually having been in a hotel where minetest crashed when connecting to cdb while connected to the wifi, but i did not have the clarity of mind to save the debug output :/ |
| 20:19 |
|
olliy joined #minetest-dev |
| 20:21 |
|
YuGiOhJCJ joined #minetest-dev |
| 20:27 |
|
proller joined #minetest-dev |
| 20:36 |
|
BuckarooBanzai joined #minetest-dev |
| 20:40 |
sfan5 |
fyi macos CI is currently unavailable because github is sunsetting that https://github.blog/changelog/2022-07-20-github-actions-the-macos-10-15-actions-runner-image-is-being-deprecated-and-will-be-removed-by-8-30-22/ |
| 20:40 |
sfan5 |
it work again in time for release |
| 20:40 |
sfan5 |
+will |
| 20:40 |
|
YuGiOhJCJ joined #minetest-dev |
| 21:11 |
|
Baytuch joined #minetest-dev |
| 21:14 |
MisterE[m] |
<sfan5> "fyi macos CI is currently..." <- And gitlab's ci won't handle it? |
| 21:14 |
MisterE[m] |
Oh |
| 21:54 |
|
Baytuch joined #minetest-dev |
| 22:24 |
|
Baytuch joined #minetest-dev |
| 22:29 |
|
Baytuch joined #minetest-dev |
| 22:34 |
|
panwolfram joined #minetest-dev |
| 22:35 |
|
vampirefrog joined #minetest-dev |
| 22:40 |
|
cranezhou joined #minetest-dev |
| 23:02 |
|
Baytuch joined #minetest-dev |
| 23:03 |
|
cranezhou joined #minetest-dev |
| 23:40 |
|
Baytuch joined #minetest-dev |
| 23:55 |
|
kilbith joined #minetest-dev |
