Jump to content
  • Advertisement
Sign in to follow this  
khoadd

how many threads for game loop

This topic is 2146 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all,

 

I saw java game used 2 threads. One thread for game loop (update, render) and one for handling input (keyboard, mouse). Game loop thread was manually created by programmer. The other cames from "Event Dispatcher Thread" of .JFrame.

 

On the other hand, I saw C++ game had just one thread (Example SDL or DirectX game progamming tutorials ). It is like this:

 

...

...

while(running)

{

// handle input or handle messages / events

// update

// render

}

...

...

 

So, my question is "which one should I use?".

 

Thanks!

 

P/S: please explain why

Edited by KhoaVN

Share this post


Link to post
Share on other sites
Advertisement
Depends on your needs.
What are you planning to make, how demanding?

If you can manage fine with 1 thread, performance wise on your target audience, then that's fine (and might save quite some headaches/ complexity)

Share this post


Link to post
Share on other sites

The correct answer for the For Beginners forum is - you should use one thread.

 

In one of the other forums, the answer might be different depending on what you want to accomplish and how you want to go about it.

 

There is no correct number of threads.

Share this post


Link to post
Share on other sites

Hi all,
 
I saw java game used 2 threads. One thread for game loop (update, render) and one for handling input (keyboard, mouse). Game loop thread was manually created by programmer. The other cames from "Event Dispatcher Thread" of .JFrame.
 
On the other hand, I saw C++ game had just one thread (Example SDL or DirectX game progamming tutorials ). It is like this:
So, my question is "which one should I use?".
 
Thanks!
 
P/S: please explain why

 
 
As a beginner you have much to learn already. You are already learning about graphics, animation, audio, effects, user interfaces, event systems, resource management, and much more.
 
 
Threading can be a good thing in games, but it is a complex topic.  As I recently wrote elsewhere:
 
In the process you will also need to learn about proper use of synchronization and locks and mutexes and semaphores, reentrant code, threaded storage, processing granularity, purity/isolation of data, memory barriers, CPU caches and cache coherency, and other topics. You will need to learn about the bugs that come with threading including deadlocks and livelocks, resource starvation, race conditions, memory thrashing, convoying, write tearing, and much more. Threading has even spawned a mathematical notation called transactional object calculus to help model the complexity of threading. It is an interesting topic and very much worth learning, just be aware of the scope. 

 

Threading has many benefits in games. Threads can be used as a structural system to isolate processing to prevent bugs from collapsing your program. Threads can be used for extra eye candy.  Threads can be used to help schedule work. 

 

Multithreading should not be relied on for game-critical performance.  That is, don't write a program that absolutely relies on parallel algorithms because the resources may not be there on low-end machines or heavily loaded machines. Do so at your own peril.

 

 

Certainly you can add all that to your game if you want to, but beginners usually have a hard enough time with a single processing thread.

 

In your case somebody else is running a thread for input.  That is fine, we will assume they know what they are doing and have resolved all those issues mentioned above in their own code. You don't need to use their threads. Just make your design single threaded for now.

 

For some things that you think you want threads for, what you really want is asynchronous calls.  That means somebody else is doing all the hard work in threading. Somebody else who knew how to do it has already solved the problem.  Asynchronous disk reads and asynchronous network communication and asynchronous rendering. Learn to use asynchronous functions so you can take advantage of processing power without stalling your app.

Share this post


Link to post
Share on other sites

In my opinion, most inputs do not need to have allocated threading, but since it came with Jframe threading then no problem.

 

The impression I got is that in general threading is best served toward constant or relatively consistent demand for processing.  Sporadic demand may be most efficient if left to system operations to determine where the processing should go according to changing system and game demands.  There are times when allocating a thread could cause a conflict in memory cache when data has to be dumped from the memory location which normally is assigned to a thread so the system looks for the next available memory slot or waits for garbage collection, though this typically only happens under high data volume periods of gameplay.  Such allocation of threads and corresponding memory issues may cause stuttering even when frames per second is at a high rate.

 

 

 

Another way of thinking is that the more frequently a function is in demand then generally the more likely the need for thread allocation for that data.

 

...just my view on the threading.

 

 

Clinton

Edited by 3Ddreamer

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!