"Questions that don't deserve their own thread" thread

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Whatthefuck
Party member
Posts: 106
Joined: Sat Jun 21, 2014 3:45 pm

Re: "Questions that don't deserve their own thread" thread

Post 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.
User avatar
slime
Solid Snayke
Posts: 3131
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: "Questions that don't deserve their own thread" thread

Post 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.)
Whatthefuck
Party member
Posts: 106
Joined: Sat Jun 21, 2014 3:45 pm

Re: "Questions that don't deserve their own thread" thread

Post 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.
User avatar
slime
Solid Snayke
Posts: 3131
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: "Questions that don't deserve their own thread" thread

Post 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.
Whatthefuck
Party member
Posts: 106
Joined: Sat Jun 21, 2014 3:45 pm

Re: "Questions that don't deserve their own thread" thread

Post 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.
User avatar
slime
Solid Snayke
Posts: 3131
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: "Questions that don't deserve their own thread" thread

Post 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.)
Whatthefuck
Party member
Posts: 106
Joined: Sat Jun 21, 2014 3:45 pm

Re: "Questions that don't deserve their own thread" thread

Post 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
User avatar
Ranguna259
Party member
Posts: 911
Joined: Tue Jun 18, 2013 10:58 pm
Location: I'm right next to you

Re: "Questions that don't deserve their own thread" thread

Post by Ranguna259 »

micha wrote:...
That's not quite what I'm looking for, but thanks :P
I found the lib, it's outdated but I'll try to port it to 0.9.1
EDIT: Done
LoveDebug- A library that will help you debug your game with an on-screen fully interactive lua console, you can even do code hotswapping :D

Check out my twitter.
lumlune
Prole
Posts: 12
Joined: Fri May 02, 2014 9:50 pm

Re: "Questions that don't deserve their own thread" thread

Post 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.
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: "Questions that don't deserve their own thread" thread

Post 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

Code: Select all

require "love.filesystem"
and it should work from then on.
Locked

Who is online

Users browsing this forum: No registered users and 42 guests