LÖVE

Hooray for multithreaded colored lighting!

Whatthefuck wrote:Hooray for multithreaded colored lighting!

What exactly do the seperate threads do?

S0lll0s wrote:

Whatthefuck wrote:Hooray for multithreaded colored lighting!

What exactly do the seperate threads do?

It computes the lighting on a separate thread, obviously.

Basically the way it works is the main thread sends a request for light computation and then goes on to draw other stuff. Once it's done drawing other stuff, it waits until the other thread is finished, finishes the lighting up and renders it.

This way if the rendering process of other stuff takes longer than the light computation, there is virtually no framerate impact from the light compute, since by the time it's done rendering other stuff, it'll just finalize the lighting (without waiting) and render it.

Whatthefuck wrote:

S0lll0s wrote:

Whatthefuck wrote:Hooray for multithreaded colored lighting!

What exactly do the seperate threads do?

It computes the lighting on a separate thread, obviously.

Basically the way it works is the main thread sends a request for light computation and then goes on to draw other stuff. Once it's done drawing other stuff, it waits until the other thread is finished, finishes the lighting up and renders it.

This way if the rendering process of other stuff takes longer than the light computation, there is virtually no framerate impact from the light compute, since by the time it's done rendering other stuff, it'll just finalize the lighting (without waiting) and render it.

And how do you serialize the world/map across threads? The "flat" table limitation still keeps me from doing multi-threading.

S0lll0s wrote:And how do you serialize the world/map across threads? The "flat" table limitation still keeps me from doing multi-threading.

I write the lighting which I want computed into a ImageData object, since it's userdata, it's shared between threads, and no duplicates are required. So upon initialization I send a reference of the LightData object to a separate thread, read it's size and set up various variables accordingly.

For the actual lighting compute - I write the color of the light to the RGB channels, and then other data into the alpha channel, for example whether the current pixel is a light source, whether light can pass through the current pixel, etc, which the lighting computation thread interprets as necessary and begins it's work from there.

Finally, on the main thread I call :demand on the channel and once the channel sends the confirmation that it's done (a simple bool), it calls :refresh on the Image object that's created from the same old ImageData, finalizes the lighting using a shader and finally draws it on the screen.

Couple that with the FFI ImageData implementation that one of the devs has made and you get crazy fast multithreaded lighting compute.

I've actually had the lighting compute this way for several months now, I simply implemented colored lighting recently. (~2 weeks ago)

Thanks for the insight - I suppose by LightData you mean ImageData for a light image? I can't find anything called LightData.

S0lll0s wrote:Thanks for the insight - I suppose by LightData you mean ImageData for a light image? I can't find anything called LightData.

Yeah, whoops, typo, meant ImageData.

Also, just to give you an idea of how fast it is, on a 1080p monitor, an i5 4670 + R9 290 and a 25x25 pixel over-compute (where each pixel is a separate world block):

60 updates/sec:
stock @ 3.4 GHZ - 900-930 FPS
downclocked @ 800 MHZ - ~170 FPS

15 updates/sec (Terraria's rate):
stock @ 3.4GHZ - ~970 FPS
downclocked @ 800 MHZ - ~230 FPS

I made this water surface simulator thingy for my game. It doesn't look very natural at the moment, I'm hoping once I add particles it'll look better. It's pretty simple at the moment, I think I might try to release it as a library later on if I have the time. I'm using assets from some of my older games so I'm not just working with squares anymore.

I'm working on a rogue-lite dungeon crawler/top-down shooter. All of the art is just placeholder and it's just barely starting to resemble a playable game, but I think it's coming along nicely.

(best viewed at 60FPS in Chrome)