LÖVE

Hey all,

I'm sitting here wondering what types of uses people have used the threads for, I have used it for encoding and saving images, as well as a variety of one off stuff. I am mostly curious what types of uses people have used threads for.

• GIF saving
• Screenshot saving
• Other things? (don't remember)

I have used it for:

• Serial port communication, most Lua libraries are synchronous so you have to sit and wait for the serial message to come. Threads are good at this.
• TCP communication in localhost, with another program running on the same machine.
• Downloading large files from the internet, I have tried to provide progress bars but unfortunetely we are using a rather old LuaSocket version so async calls are not here yet...
• Stuff I thought took too much time like parsing, but then I realized that this didn't take much time, and I was delaying everything one update unnecessary so I dropped it.

I usually write my stuff like Javascript callbacks, so then I plug an event loop and can do stuff like channel.on("event", callback). That works really nicely because in the event I drop the thread or move to something else I can reuse the callback function

1. Sound system. It can play from another thread.
2. Networking. Luasocket have small buffer for udp-dgrams (64kb), and if it fills, any new data have been lost. Now, i make threaded udp-lib.
3. A lot of high load calculations. Collision detection, serialisation, hashes etc.
4. Control (keyboard/mouse/joysticks) calcs.
Also you can make main gamelogic in child thread, using main thread only for drawing.

HDPLocust wrote: 3. A lot of high load calculations. Collision detection, serialisation, hashes etc.
4. Control (keyboard/mouse/joysticks) calcs.
Also you can make main gamelogic in child thread, using main thread only for drawing.

This are the things that are better done in the main thread. Otherwise everything get's delayed an update, specially Control calcs, think about it this way, you first need to detect your inputs, that happens in a love.event.pump so that is one update, then in that very same update you send all events to the other thread, then you draw (already outdated because there was some input that you haven't processed) then the next update you take the data generated from the thread and you update the draw function, but again you have new input so that draw is already outdated... and that's how it goes.

There are lots of good collision detection libraries that are really optimized, and serialization doesn't tend to be a bottle neck. I can see hashing being a problem though.

The other points I think are spot on too, sound and networking are better done in other threads

Positive07 wrote: Otherwise everything get's delayed an update

All data that can be processed at the beginning of the frame and which are not associated with any data structure can be processed in the subthreads:
The main thread sends input a child, do all of the work that can not be performed without the child threads data, receive data from childs and do some work with that data. Like semaphores. It's blocking operation, but since the load on the main thread of the above, the children have time to do everything. Without delays.
Collision detection can be calculated at the same time when the main (or sub) thread calcs character (de)buffs, AI (one frame delay does not matter).

If it works of course do it! But you need to think too far ahead, you need to tweak things and be very precise about it... Optimizing this stuff is hard and then having everything synced up can be even harder... That is why I recommend not to, but even then at the end of the day I'm not the one writing that code so you may as well do it (because I know that it can actually be done and give way better results than not doing it, it's just harder, or that I think)

Positive07 wrote:Optimizing this stuff is hard and then having everything synced up can be even harder

https://en.m.wikipedia.org/wiki/Race_condition
Yeah, it's hard, if it has multiple states/semaphores in code, But easy with one semaphore-state and unix-way: one thread have one job, but do it perfectly.

Yes that is a must, One threads does one thing, does it well and does it fast and tries to succeed always!

HDPLocust wrote:1. Sound system. It can play from another thread.

Is a thread for audio even needed? Audio already is threaded by LOVE iirc.

bobbyjones wrote:

HDPLocust wrote:1. Sound system. It can play from another thread.

Is a thread for audio even needed? Audio already is threaded by LOVE iirc.

Not for the current use-cases, but 0.11 giving us queuable sources, it might just be handy then.