love.thread guide/example game?

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.
Post Reply
User avatar
Eamonn
Party member
Posts: 550
Joined: Sat May 04, 2013 1:29 pm
Location: Ireland

love.thread guide/example game?

Post by Eamonn » Wed Jul 03, 2013 12:03 am

Ok, I just found out LÖVE had Threads. I assume these are like threads you would see in normal programming? So, how would I use them? I've never used threads in programming before, but they seem good for multitasking. Maybe not the most useful thing for simple games, but I'd like to know about them and how they work all the same. I learned about the Box2D physics module and yet I have never used it.

Just so I keep up with my trend:

Thanks! Any help is appreciated!
"In those quiet moments, you come into my mind" - Liam Reilly

User avatar
verilog
Citizen
Posts: 97
Joined: Thu Nov 03, 2011 3:15 am
Contact:

Re: love.thread guide/example game?

Post by verilog » Wed Jul 03, 2013 2:03 am

Hi,

I haven’t used löve’s implementation of threads, but I have experience with C threading, so I’d be able to give a basic idea of what this is all about.

First, I’d suggest to be cautious about threading, depending on what you are doing, their implementation and debugging could be somewhat difficult. If you can achieve the same results with another approach such as co-routines, then, I’d personally encourage you to explore that option instead.

For a little background, threads are essentially pieces of code that can be run simultaneously inside a single process (i.e. application). Now, we can argue the true meaning of concurrency here, depending on the kind of CPU architecture we’re talking about (mono or multi processor) but that’s another topic.

Threads offer the ability to run various tasks at the same time, giving you the capacity to multi-task certain aspects of your application. One common example of threads in action is the “loading bar” application.

Suppose your application has an initial “loading” stage where all your resources are actually being loaded into memory. If your program uses just one thread for this task, the user will stare at an unresponsive and ugly “frozen” application screen while all resources are being loaded.

That is because the application is actually doing just one thing at a time, it can’t update the graphical interface or response to user input because it is busy loading resources. But now... imagine if we could somehow split the program into two tasks and run them “simultaneously”?

We could load resources with one task (thread) and show a nice, dynamic “progress bar” for the user’s visual enjoyment with another task. Nice eh? And that’s just one example of threading!

Now, the ugly part. Threads are generally generated in one, shared, environment (i.e. one single program). That means that, if we’re not cautious enough, threads could access global data and change its value (nasty!) at the same time (known as race condition).

Of course, there’s a solution to these problems. Blocking mechanisms should ensure that certain resources are only accessible to just one thread at a time. Depending on the implementation, thread managing could also be quite laborious, compromising the complexity of your application.

So, basically, you must be aware of the benefits and disadvantages of threads. Of course, it all depends on your application and what you are trying to achieve, there are some functionalities that can be accomplished through threads only.

That’s the general idea behind it, hope it helps! :ultraglee:

User avatar
slime
Solid Snayke
Posts: 2851
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: love.thread guide/example game?

Post by slime » Wed Jul 03, 2013 2:12 am

verilog wrote:Now, the ugly part. Threads are generally generated in one, shared, environment (i.e. one single program). That means that, if we’re not cautious enough, threads could access global data and change its value (nasty!) at the same time (known as race condition).

Of course, there’s a solution to these problems. Blocking mechanisms should ensure that certain resources are only accessible to just one thread at a time. Depending on the implementation, thread managing could also be quite laborious, compromising the complexity of your application.
In LÖVE's case each thread has its own completely unique Lua state, so you don't run into concurrent access problems with your own Lua code, however much of the functionality and data provided by LÖVE is not unique to each thread and not all of it is thread-safe (e.g. you can send a single SoundData between threads and it won't be duplicated internally, but SoundData in particular doesn't do anything to prevent issues you mentioned above.)

User avatar
verilog
Citizen
Posts: 97
Joined: Thu Nov 03, 2011 3:15 am
Contact:

Re: love.thread guide/example game?

Post by verilog » Wed Jul 03, 2013 2:25 am

Ah! thanks for your clarification, slime! I have yet to play with löve's thread implementation, I'm a little bit stuck in C at the time, but it's super helpful to know that löve's implementation is a little bit more benevolent.

Germanunkol
Party member
Posts: 706
Joined: Fri Jun 22, 2012 4:54 pm
Contact:

Re: love.thread guide/example game?

Post by Germanunkol » Wed Jul 03, 2013 10:19 am

My game trAInsported uses threads a lot, for client/server connections and for rendering of images:
http://trainsportedgame.no-ip.org/download.php
https://github.com/Germanunkol/trAInsported

Might be a bit more complex than what you need right now, but check out the code, especially renderImageBox.lua:
https://github.com/Germanunkol/trAInspo ... ageBox.lua (for the thread)
and function button.init(maxNumThreads) in button.lua (for the starting and handling of the thread).

With all that said, make sure to only use threads where you absolutely need them. Looking back, I should maybe have used less threads for the game.
trAInsported - Write AI to control your trains
Bandana (Dev blog) - Platformer featuring an awesome little ninja by Micha and me
GridCars - Our jam entry for LD31
Germanunkol.de

User avatar
Eamonn
Party member
Posts: 550
Joined: Sat May 04, 2013 1:29 pm
Location: Ireland

Re: love.thread guide/example game?

Post by Eamonn » Wed Jul 03, 2013 12:23 pm

Thanks everyone for the replies! I'll check your games, Germanunkol! Verilog and slime you guys helped a lot too :D Maybe threads aren't useful now(for single player games at least(I think you'd use threads in a MultiPlayer game to help with performance)) but maybe as LÖVE grows and gets even more powerful they'll be useful!
"In those quiet moments, you come into my mind" - Liam Reilly

User avatar
Plu
Inner party member
Posts: 722
Joined: Fri Mar 15, 2013 9:36 pm

Re: love.thread guide/example game?

Post by Plu » Wed Jul 03, 2013 12:25 pm

As a general guideline, threads are great if you need to do a lot of work to get a very simple answer. Examples like pathfinding (a lot of calculating to get a handful of values) and AI (a lot of work to determine the next move it makes) are great to push into threads.

(Although I understood you can also share userdata over them?)

User avatar
raidho36
Party member
Posts: 1919
Joined: Mon Jun 17, 2013 12:00 pm

Re: love.thread guide/example game?

Post by raidho36 » Wed Jul 03, 2013 6:53 pm

The first thing you have to know about threads in video games: DON'T.

First off, multithreading doesn't give any performance benefits. Just using several cores doesn't makes code run any faster (in fact, it makes it run slower). A thumb rule for threads usage is to only use when you have a lot of heavy computations that you can easily split in parts. E.g. you can easily split a task of compressing several files to a several treads just by assigning certain files to certain threads, since they're processed independently. Or a task of encoding a video can be split to several threads by assigning them certain lists of keyframes to encode, since they also processed independently (and then encoded data is simply glued together in order the keyframes appear).

Additionally, löve2d would have separate memory pools for every thread (unlike threads in C application, for example), so your only means of transferring data is using messages, which isn't exactly effecient way to do it, therefore you must cut it to minimum. Like Plu said, with löve2d threading you're pretty much limited to computing very heavy tasks that involve next to zero data transfer.

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests