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

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)

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.

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.

Thank cozzie

Thank Dave Hunt

Thank frob

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