Time Nick Message 10:32 sfan5 btw meshgen is on a separate thread, so that's not it 10:33 sfan5 you could try something like renderdoc to debug the rendering side of that 10:34 MTDiscord @ExeVirus check context switching and locking mechanism, we should loose some performance there. If we want to be blasing fast, it's not ez and it require a massive change client side to work on a message queue instead of many sync orders to rendering engine 10:34 MTDiscord but it's close to rewrite the whole renderer 10:34 MTDiscord maybe not renderer, mostly the client 11:30 MTDiscord Yeah, not meshgen, though that is slow haha. No it's the entity mesh rendering, which does happen client side, and I believe on the client updateFrame. 11:30 MTDiscord And also: yeah I'm personally not going to pull off a rewrite, but I can see performance improvements in front of me, so I'll try to get those done 11:31 MTDiscord Specifically, the skinned mesh animation and skinning when you have a bunch of entities is like 30% of client side thread time 11:31 MTDiscord With another 20% being their collision math haha. 11:33 MTDiscord Did the wheel inventory make it into 5.9, if the future freeze isn't currently in effect it might be a good idea to add ability to freeze/disable the mouse rotation as a server side and client side function. 11:33 MTDiscord * feature freeze 14:04 sfan5 we're already in feature freeze 19:28 MTDiscord I know this sounds like a mediocre idea, but: I've been diving through the rabbit hole of converting C/C++ libraries to pure Lua 5.1 long story short: not possible easily. But to luaJIT: that's already been done and working. The issue is it makes use of 'ffi' for handling u64->f64->u64 kinds of situations. Wondering how hard it would be for us to expose those data types to our luaJIT builds? Benefits: most C libraries now open 19:28 MTDiscord up as an option for modders to use. Stuff like valid Markdown parsers, valid XML parsers, regex if they happen to hate patterns for some reason, some of the math libraries, etc. Thoughts? 19:29 MTDiscord what does it have to do with minetest? you mean binding them in your own package? 19:29 Krock unprotected FFI could allow to manipulate the server memory or maybe even execute machine code. Thus I don't think that's generally somewhat we'd want to give modders 19:30 MTDiscord it'd have to be a mod trust thing, yeah 19:31 MTDiscord Well, in this case the ffi merely gives them the ability to create u32, double, float, directly. Nothing else ffi would be exposed 19:31 Krock there's some more points to that: http://luajit.org/ext_ffi_semantics.html (thanks Mike Pall for this explanation) 19:31 Krock (heading "No Hand-holding!") 19:37 MTDiscord As a corollary of the above, the FFI library is not safe for use by untrusted Lua code. If you're sandboxing untrusted Lua code, you definitely don't want to give this code access to the FFI library or to any cdata object (except 64 bit integers or complex numbers). Any properly engineered Lua sandbox needs to provide safety wrappers for many of the standard Lua library functions — similar wrappers need to be written for high-level 19:37 MTDiscord operations on FFI data types, too. Interestingly, I think I only need u64 and doubles 19:42 sfan5 it sounds like you want some very specific operation and not actually "luajit ffi" 19:43 sfan5 but I don't understand what would be the point of exposing ffi types and nothing else 19:46 MTDiscord Purely for inspection of doubles. Sadly, pure Lua 5.1 doesn't have a way, even with bit op, to get at those bits 19:47 MTDiscord Mostly, I'm curious if this is even a route I should take us down and create an example PR for... It would be some decent work that could be spent improving performance instead, for example 19:50 sfan5 out of all things C/C++ libraries do bitcasts are they only thing that's missing in Lua? 19:51 MTDiscord Yes, basically. Because the toolchain I've been working with goes c/c++ -> WASM 32 -> luaJIT with some ffi as outlined above. WASMs memory model allows us to pull it off in pure Lua. Of course that emulation is a lot 20:33 MTDiscord A lot slower* 20:51 MTDiscord speaking off, ill work on porting more stuff after work tonight 20:51 MTDiscord (given im not sleepy)