Page 4 of 91
Re: "Questions that don't deserve their own thread" thread
Posted: Fri Jul 18, 2014 1:29 pm
by Whatthefuck
Fenrir wrote:Well that pretty much completely ruins the functionality of threads for me if I can't render something to a canvas on a separate thread.
Well consider it as ruined, drawing even on canvas must be done in the main thread.
It's pretty dumb though. Userdata is shared (awesome), variables/etc are not, can't send complex tables, rendering is restricted to the main thread. (welp, that completely removes any functionality provided by shared userdata)
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.
Re: "Questions that don't deserve their own thread" thread
Posted: Fri Jul 18, 2014 2:00 pm
by slime
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.)
Re: "Questions that don't deserve their own thread" thread
Posted: Fri Jul 18, 2014 2:32 pm
by Whatthefuck
I have to recompute the lighting quite often, so the only way of optimizing it is by splitting it up into numerous canvases and spritebatches, in order to render less. (Stuff that is out of the player's vision basically)
256 sprites is for a 16x16 canvas, which is then upscaled to 320x320 to let linear filtering smooth it out.
On my native res, which is 1680x1050, I need to re-add a total of 24,576 sprites to spritebatches (!!!) every time the lighting changes, hence why I'm looking for a way to do that on a separate thread.
So, is at least adding sprites to a spritebatch, without doing a drawcall, on a separate thread possible?
Edit: just realized that 12 canvases is too much on the horizontal scale of my monitor, looks like that's one thing I'll optimize now.
Re: "Questions that don't deserve their own thread" thread
Posted: Fri Jul 18, 2014 2:46 pm
by slime
Whatthefuck wrote:256 sprites is for a 16x16 canvas, which is then upscaled to 320x320 to let linear filtering smooth it out.
How come you have a sprite for each pixel?
Lighting is generally very well suited to shaders (which can process millions of pixels per frame with no sweat) - at the very least I've never heard of a lighting technique where you generate each texel of the lightmap like this rather than with a more GPU-friendly approach. You might be able to draw a single large quad or have a single sprite or draw-call per light, when rendering to the lightmap.
Re: "Questions that don't deserve their own thread" thread
Posted: Fri Jul 18, 2014 2:50 pm
by Whatthefuck
slime wrote:Whatthefuck wrote:256 sprites is for a 16x16 canvas, which is then upscaled to 320x320 to let linear filtering smooth it out.
How come you have a sprite for each pixel?
Lighting is generally very well suited to shaders (which can process millions of pixels per frame with no sweat) - at the very least I've never heard of a lighting technique where you generate each texel of the lightmap like this rather than with a more GPU-friendly approach. You might be able to draw a single large quad with a shader active that creates the lightmap, or have a single sprite or draw-call per light.
Because I have no experience with shaders nor do I know how to write one that would do that.
Re: "Questions that don't deserve their own thread" thread
Posted: Fri Jul 18, 2014 2:57 pm
by slime
What's a screenshot or game example that demonstrates the look you want to achieve with the lighting? We might be able to help with it (and it might be a good idea to make a dedicated thread for it at this point.)
Re: "Questions that don't deserve their own thread" thread
Posted: Fri Jul 18, 2014 3:01 pm
by Whatthefuck
slime wrote:What's a screenshot or game example that demonstrates the look you want to achieve with the lighting? We might be able to help with it (and it might be a good idea to make a dedicated thread for it at this point.)
Here's what the lighting looks like at the moment:
https://www.dropbox.com/s/g5n70g82ujnth ... 815%29.mp4
Forgive the chatter in the video, was talking to a friend. :V
Re: "Questions that don't deserve their own thread" thread
Posted: Fri Jul 18, 2014 9:23 pm
by Ranguna259
micha wrote:...
That's not quite what I'm looking for, but thanks
I
found the lib, it's outdated but I'll try to port it to 0.9.1
EDIT:
Done
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Jul 19, 2014 8:03 am
by lumlune
Question: how can I utilize "require" within a thread? I can start the thread without incident, but nothing after that line is executed.
Link to a minimal recreation.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Jul 19, 2014 8:34 am
by bartbes
lumlune wrote:Question: how can I utilize "require" within a thread?
Only love.thread is loaded in a thread, and to require files normally, you also need to load love.filesystem, so start off with
and it should work from then on.