Time Nick Message 00:36 [MatrxMT] in order to make more sense of concept approved / supported by core dev labels, the latter is now called "Roadmap: supported by core dev" (rubenwardy's suggestion, made sense) 00:36 [MatrxMT] in short: the former is for issues and PRs related to such issues. The latter is for when some core dev decides to take care of a PR not in the roadmap 07:32 SFENCE Is there some reason why USE_SDL2 cmake option is not documented in doc/compiling/README.md? 08:09 MTDiscord it's a compile option inside of irrlichtmt, so it's still only listed in irr's readme 09:49 SFENCE Understand. But it is complicated to find if someone has no idea what he is looking for. #15136 09:49 ShadowBot https://github.com/minetest/minetest/issues/15136 -- Add SDL2 options to compiling README. by sfence 09:51 MTDiscord yes. all of the other irr exclusive compile options such as the video driver options should be added to the minetest docs too 09:54 SFENCE #15069 ready for review. 09:54 ShadowBot https://github.com/minetest/minetest/issues/15069 -- Try to support older MacOS version by sfence 09:56 SFENCE Will be nice to be part of 5.9.1 release, so we can continue in supporting macOS 10.15 and newer ones. 11:42 sfan5 merging #15131, #15129, #15128 in 10m 11:42 ShadowBot https://github.com/minetest/minetest/issues/15131 -- Count global number of drawcalls too by sfan5 11:42 ShadowBot https://github.com/minetest/minetest/issues/15129 -- [no sq] Get rid of duplicated IGUISkin implementation by grorp 11:42 ShadowBot https://github.com/minetest/minetest/issues/15128 -- MacOS: make mute sound actually work by sfence 12:34 [MatrxMT] Reminder to prioritise #15087 and #15098 for 5.9.1 12:34 ShadowBot https://github.com/minetest/minetest/issues/15087 -- [no squash] Fix network window size logic by sfan5 12:34 ShadowBot https://github.com/minetest/minetest/issues/15098 -- Only apply "touch_punch_gesture" when item has no on_use callback by grorp 13:54 Krock a regular feature freeze + 5.10.0 release would be possible too; depending on how long it takes to solve the remaining issues. 15:40 rubenwardy Reminder that we should avoid delaying releases for specific things, 5.9.1 should be done ASAP. Anything remaining can go into 5.9.2 15:57 sfan5 then lets merge those two and release 16:39 Krock starting with the backport PR. please ping me asap if someone else is already on it. no need to duplicate efforts. I hope there's not too many conflicts to resolve. 16:51 [MatrxMT] 5.9.2 can simply be merged with 5.10 so we can actually start with the name change 16:54 MTDiscord name change? 😳 I thought that went nowhere 17:02 MTDiscord it just went somewhere else 17:02 red-001 I Backported some of those LuaJIT features that it copied from Lua 5.2, I don't think getting most of them ported would be too much work 17:03 red-001 aside from yielding across pcalls 17:03 red-001 cause for that moving to 5.2 and readding environments would probably be easier 17:04 red-001 well maybe not, I didn't really look into how much code that change would touch, maybe it wouldn't be that bad 17:33 Krock thanks meld. It produced total garbage. 17:41 Krock sfan5: shall I include #15124 for 5.9.1? 17:41 ShadowBot https://github.com/minetest/minetest/issues/15124 -- [no squash] Fix texture matrix handling in our shaders by sfan5 17:41 Krock not as important because yawsprites aren't used that much 17:46 Krock #15137 17:46 ShadowBot https://github.com/minetest/minetest/issues/15137 -- Backport for 5.9.1 by SmallJoker 17:48 Krock to whom it may concern: feel free to test. 17:56 sfan5 Krock: sure, you can 18:46 sfan5 ok wow apparently calling draw2DImageBatch just does multiple drawcalls on the GL driver 18:47 Krock yes 18:48 Krock at least for the OpenGL 1.x/2.x driver, I tried to optimize it here: https://github.com/SmallJoker/minetest/commit/7faf7c0476f43875120bdf1297bd5e2122e4da9e#diff-27977efd41c14fce4f30a9bb3e917667f1c9c4e2c2e51b86ba164c048feebdeeR1428 (belongs to the PoC batch rendering) 18:49 Krock there's no glScissor active, thus batching the triangles is trivial 18:49 Krock I did however not notice a big difference in performance on my side, thus did not follow this topic further since then 18:51 sfan5 yeah I'm looking at the same thing but a different approach 18:52 Krock I wish there was a batched GL_TRIANGLE_FAN to save a few vertex points but I guess we cannot have it all. 18:52 sfan5 https://www.khronos.org/opengl/wiki/Vertex_Rendering#Primitive_Restart would work 18:53 sfan5 my idea is to move all of the 2d drawing functions out of the gl driver, so that only draw2DVertexPrimitiveList remains and then implement them anew on top of that 18:53 sfan5 once that works we could allow the caller to control batching manually 18:54 Krock makes sense. Clever batching of multiple function calls can be done in a later step 18:56 Krock requires OpenGL 3 18:56 Krock found it in https://docs.gl/gl3/glEnable 18:57 Krock apparently not available in OpenGL ES 2 nor 3 19:00 Krock (unless GL_PRIMITIVE_RESTART_FIXED_INDEX is also a possibility) 19:21 MTDiscord Krock: Does #15062 need a second approval, or it can be merged under the one approval rule? If it needs it, I'm asking @Lars for a review. 19:21 ShadowBot https://github.com/minetest/minetest/issues/15062 -- Document negative saturation by nauta-turbidus 19:23 Krock 2nd review 21:04 red-001 Just checked that #15134 passes the internal Lua test suite, what's the difficulty with switching fully to Lua 5.2 when not using LuaJIT? Just the changes to how environments are handled? 21:05 ShadowBot https://github.com/minetest/minetest/issues/15134 -- [no-sq] Some Lua 5.2 backports by red-001 21:05 red-001 I don't really see why standard Lua even needs to be supported, doesn't LuaJIT support all the platforms Minetest supports? 21:07 MTDiscord I wouldn't want to be "locked in" to LuaJIT given it's uncertain maintenance state. PUC Lua 5.1 is good to have as a fallback, it's a much more maintainable codebase. 21:08 MTDiscord There have been problems caused by LuaJIT in the past, it's good if you can just switch to PUC to rule JIT out (or to suspect JIT) as the cause of a problem. 21:09 red-001 do enough mods even use Lua environments for it to be a problem if Minetest just didn't support them? 21:09 sfan5 depending on a library with a bus factor of one for our central functionality is not wise 21:09 red-001 or if they needed different code for LuaJIT and standard builds 21:10 sfan5 we literally have setfenv calls in builtin 21:12 MTDiscord if the concept of the pr is acceptable, probably should document/note those things in lua_api.md somewhere 21:12 MTDiscord *accepted 21:13 red-001 I think the serialize.lua code would just need a small change to work with the Lua 5.2/5.3 environments, just set the environment on load 21:14 red-001 don't see any examples in builtin that actually need setfenv, if not for being written for Lua 5.1 21:16 MTDiscord the main use case you really need setfenv for in 5.1 is for sandboxing kind of things, and you are right that passing an environment to load obsoletes that (though we would still require modders to manually upgrade). 21:17 MTDiscord however there are also mods which use setfenv for convenience; many of my mods do this for example. arguably these could also be reworked to use load, but that may be somewhat dirty and well, again the modders would have to do it. 21:18 red-001 I mean sure it's a change for modders, but I think they'll live at least when it comes to sandboxing. In what context do you use it as a convenience feature? 21:21 red-001 there's another option here and that's bundling Lua 5.2 or 5.3 and potentially modifying it so that makes sure each function has an _ENV upvalue 21:21 red-001 not actually super clear on whatever stock Lua already ensures that or not 21:26 sfan5 not much use thinking about totally incompatible changes 21:30 red-001 not really totally incompatible, just a minor change really, could modify the vendored-in version of Lua 5.3 to hide the _ENV variable from the user so it's more like Lua 5.1. And implement polyfills for getfenv and setfenv for functions 21:31 red-001 wouldn't work for threads and userdata and c-functions but that's not a massive breakage I suspect 21:35 sfan5 it literally introduces an integer type 21:38 MTDiscord Not even for Minetest 7.0.0? 21:39 MTDiscord integers are 5.3, so could upgrade to 5.2 and polyfill in support for 5.1 stuff? 21:40 red-001 I meant 5.2, tho admittedly I initially said 5.2/5.3 cause I thought integers only got added in 5.4 21:41 sfan5 have you looked at #1277 21:41 ShadowBot https://github.com/minetest/minetest/issues/1277 -- Update to Lua 5.2 by ShadowNinja 21:43 red-001 I have, I don't get the "example" given is the point that functions that don't access globals have no environment? Okay so what's the problem with that? 21:49 red-001 okay I see there's some further example code linked https://web.archive.org/web/20141118212657/http://codepad.org/tLMkCXOq 22:07 red-001 it still seems like a hack, it abuses the debug library to do all this 22:07 MTDiscord sfan5: would it help if i did the second possible test on #14999 - just wanted to check that it was still relevant after doing to the first possible 22:07 ShadowBot https://github.com/minetest/minetest/issues/14999 -- minetest 5.9 mapblock flickering depending on camera view 23:55 pgimeno @lars JIT can be disabled with jit.off() or jit.off(some_function), no need to switch to PUC to rule out JIT 23:58 pgimeno the idea of switching to 5.2 makes me nervous, isn't there a risk of running into a feature that isn't implemented in LuaJIT and some mod uses it, causing incompatibilities?