3
\$\begingroup\$

I 'understand' that the concept of how a game runs i.e

while (game_loop = true)
 {
  //handle events 
  // input/output/sound etc
 }

But it has come to my attention while programming in another HLL is do some games use threads for certain operations? For example take any Pokemon game ; during interaction a textbox appears to display information. Now I've been trying to simulate that sort of textbox and the only way I could have got it to be exactly the same is by using a loop and yes once a loop is started there is no way to handle window events unless they are handled again inside the loop itself.

I couldn't have used this loop inside a different thread other than the main one (due to a DirectX limitation) so the only option was to use it inside the main program thread. I was wondering if some games work like this ; do they only use the main program thread and handle events again if they're inside a loop?

Edit: I forgot to mention this is about console games not PC games!

Thanks Nubcake

\$\endgroup\$
3
  • \$\begingroup\$ You write that you understand the concept of how a game "runs" and post a while loop with no content what so ever. You clearly don't know as much as you think. But to answer the question "Do games use threads?" - Yes, why else do you think some consoles have multiple cores? \$\endgroup\$
    – user22553
    Nov 9, 2012 at 23:18
  • \$\begingroup\$ Yes it's true I don't know much but I was talking about the basic layout isn't it what I mentioned? \$\endgroup\$
    – Nubcake
    Nov 9, 2012 at 23:25
  • 3
    \$\begingroup\$ Layne, it looks like the while loop is pseudocode and the comments would be replaced by real code. Nubcake did the right thing in not copy-pasting an actual game loop. Please share your knowledge without including personal insults and snide remarks... We're all just here to learn! :) \$\endgroup\$
    – Ricket
    Nov 11, 2012 at 5:13

4 Answers 4

4
\$\begingroup\$

Up to these days threading in games can still be described as not very mature. It is mostly used for island calculations like sounds, physics, particle-systems, I/O, path-finding etc, stuff that can be easily outsourced from the main-thread without running into too many locking problems. Yet the main game entity update chain is very hard to distribute over multiple threads with current state of the art engine designs.

Unfortunetly there is still no language available on consoles (or in the general game development scene) that has the concept of threads in its very language design, like for instance Erlang has it. This is long overdue in my point of view.

The PS3 tried to adress that issue with its SPUs, but overall it's pretty much fair to say that it's concept didn't exactly succeed for the majority of the developers with some exeptions like for instance Mike Acton. Making properly use of the SPUs meant completely rewriting big parts of the engines for only one platform, making cross platform development even harder. Only some PS3 exclusive titles could really afford to go that route.

It's very interesting to see where it's going with the next gen consoles, since simply adding more cores only helps if we find better concepts of really making use of them, other than 1 big main game thread and some small low priority worker threads.

\$\endgroup\$
4
\$\begingroup\$

Of course many games use threads. It's impossible to make full use of modern hardware without them. The XBox360 has three cores, many phones have two or four cores, and PC's are typically shipping with four cores and up these days. Without threads, games would be stuck using only ~25%-50% of the hardware. Some platforms even require the use of threads to accomplish certain tasks.

That said, the problem you're referring to with the text box is a horrible place to consider using a thread. It's also a horrible place to use a loop. You want to look into event-driven programming for solving problems like these.

The basic idea is that you create some kind of object or other data and register it with a manager to note that there should be a texbox open. Your main loop can then update any open text boxes, such as redrawing them or updating their contents. When the text box no longer needs to be there, you simply destroy the object and deregister it from the manager. There's no need for a thread, the problem with loops can be entirely eliminated, and the model is pretty much necessary for doing more advanced games features.

\$\endgroup\$
1
\$\begingroup\$

For the type of text box you're talking about, you don't need to resort to a new thread.

It sounds like what you're talking about is putting a loop inside your main game loop that continues until the text box goes away, the problem with this course of action being that everything else in said game loop cannot progress until that loop finishes.

Your game loop is going to be set up to be one frame* of time, so nothing that takes multiple frames should block it. Instead of putting a loop inside of the game loop what you will want to do is allow the logic to, instead of updating general game logic, update the textbox logic one frame and use the game loop as the textbox's loop. Through whatever methods you prefer, you'll want each run through the game loop while the text box is up to look something like

BeginGameLoop
     HandlePreLogicSystemStuff()  //Input and other stuff needed for the logic
     HandleTextBox()
     HandleEndOfFrameSystemStuff()  //Drawing and other output from frame
EndGameLoop

This could be as simple as putting an if block in there so if you're in text box mode you just update the text box logic and not the Move/Shoot/DanceParty logic you'd normally be running.

To answer your title question though: Yes games can (but are not required to) use threads. I wouldn't recommend it for solving this sort of problem though as deciding to start using threading opens a whole new can of worms and there are easier solutions available.


*Game loops can vary on whether they are simulated frames, drawn frames, or some other watchdog to decide when to call one or both of the previous, take this as a general statement for ease of conversation

\$\endgroup\$
2
  • \$\begingroup\$ Worth looking into finite state machines as well, so you don't need a separate copy of that loop for each of your game states. \$\endgroup\$ Nov 9, 2012 at 23:47
  • \$\begingroup\$ @TrevorPowell Yes, that is a good solution for this sort of thing :). I was trying to avoid specifying a specific method of causing the textbox update to happen each time through the loop when the problem was more with the base logic of pseudo nested gameloops. Sean's answer also has a good explanation of an implementation. \$\endgroup\$
    – Lunin
    Nov 9, 2012 at 23:53
0
\$\begingroup\$

Game timing is one of the main concerns / mechanics to have in mind from the very start of designing a game, and there are several frameworks that handle them, but in most all cases, threads are used unless every object that you use has its own state and is updated based on time intervals, in which case that update function is the main thing that you're running as your game loops. Without a framework like one of those, you'd be stuck waiting for every action to finish before processing the next one, so you'd never be able to do things like show different graphical effects happening simultaneously, or have multiple objects with AI functions running at once.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .