Whatthefuck wrote:I don't know much about how multithreading works, so I can't judge the devs and say that they're doing a bad job of adding multithreading, but this is p. much useless.
It has nothing to do with LÖVE's specific implementation of threading. This is just how OpenGL works - an OpenGL context is local to a single thread.
The only rendering APIs which allow efficient multithreaded command submission are Mantle, Metal, and DirectX 12, and none are released yet. The first two won't even run on the majority of systems. Even if one of those were used, the actual GPU hardware still tends to process things in a mostly serial manner because GPUs are massive pipelines.
AAA games made in the past decade or so which have multithreaded engines often have a single thread dedicated to submitting render commands, and worker threads for generating content to submit in the render thread. You can implement essentially the same idea in LÖVE (the render thread has to be the main thread though, the same one where the window is created and events are pumped.)
Threads are pretty far from useless even with this limitation, but in my opinion you should have a specific problem that you know is solvable with threads and won't add too much complexity and potential bugs by doing so, otherwise threads (LÖVE's implementation or otherwise) can cause more problems than they solve.
Whatthefuck wrote:Since I have to clear/re-add sprites to spritebatches quite often, can someone provide an example on how to add a sprite to a spritebatch via FFI if it's possible?
Having to clear 32 spritebatches (on a 1680x1050 res) and re-add 8192 sprites once the lighting changes is way too many C func calls and makes a slight stutter.
That can't be done right now - but in general you should try to optimize the higher level first. 8192 sprites sounds like much more than could ever be onscreen at once, and 32 spritebatches sounds like a lot more than should be necessary if you use a texture atlas. Try to take the problem from a different angle, rather than digging into micro-optimizations with your current method.
Whatthefuck wrote:The canvas is not a single one, but plenty of 16x16 canvases. (to avoid having to re-render unnecessary stuff)
Switching canvases is one of the most expensive state change operations you can do, I'm not sure having smaller canvases is benefiting you (but I don't know exactly what you want your end result to be.)