thread in game
Author
is threading is necessary in making games?
cause i''ve made few games in DOS with never knowing about threading.
If it is, necessary, in what condition i should use that threading?
thx
You don''t need threads to be able to write a good game. The only reason I could think of is if you want to keep the UI more responsive, but since your going to have to do a lot of thread syncing it becomes more of a problem than anything else.
Nope, not that I know of. Threads are just seperate sections of your code that run at the same time as another. Threads should be used to update a timer for your game (but you can do this with just a callback function). Nothing else, as far as I know.
Jiia
[edited by - Jiia on February 8, 2004 9:58:51 PM]
Jiia
[edited by - Jiia on February 8, 2004 9:58:51 PM]
Author
thx guys.
is there any other opinion??
because my friend of mine keep saying its should using thread, he code in java. n he always using thread.
is there any other opinion??
because my friend of mine keep saying its should using thread, he code in java. n he always using thread.
Mostly writing thread code in a game is more work then it will save. And usually before you can redraw eveything you have to wait for all threads to finish. And since most end users have 1 CPU, the task will be executed in serial. Meaning, none of the code actually runs on the same time.
Use threads if you are writing something like a gameserver, not a normal game. And if your friends syas you have to use threads because he uses them, it''s just a stupid excuses to show off his "wisdom".
Toolmaker
-Earth is 98% full. Please delete anybody you can.
Use threads if you are writing something like a gameserver, not a normal game. And if your friends syas you have to use threads because he uses them, it''s just a stupid excuses to show off his "wisdom".
Toolmaker
-Earth is 98% full. Please delete anybody you can.
I use a multi-threaded architecture in most of the projects I work on. I find threads to be extremely useful in all games that I have worked on, especially in larger projects...
Here are some of the reasons why I have found threads useful.
1) As a previous user has already stated, responsiveness. I often have a thread dedicated to user input.
2) Make better use of system resources. If you have a thread dedicated to rendering your graphics, other threads can make use of the CPU while the graphics card is executing its task. This also goes for I/O (if you are using blocking read/write functions to disk).
3) Logic and flow... Sometimes I find it natural to create a separate thread for certain things. For instance, I find it useful to have enemies (monsters, npcs or whatever you wish to call it) running their AI in their own thread (ie running as a separate agent). You have to be careful here though....you don''t want too many threads running simultaneously, or your CPU will spend more cycles switching between threads than actually executing the threads.
As for the synchronization, if you properly design your code, it should not be a problem.
Just think of it as another tool available to you. Use it when it makes sense. One thing I did notice though was that, until I learned to use threads properly, I tried to avoid them like the plague. Once you are very comfortable with their use (which requires practice), you''ll find that you will use them quite often.
MJB
Here are some of the reasons why I have found threads useful.
1) As a previous user has already stated, responsiveness. I often have a thread dedicated to user input.
2) Make better use of system resources. If you have a thread dedicated to rendering your graphics, other threads can make use of the CPU while the graphics card is executing its task. This also goes for I/O (if you are using blocking read/write functions to disk).
3) Logic and flow... Sometimes I find it natural to create a separate thread for certain things. For instance, I find it useful to have enemies (monsters, npcs or whatever you wish to call it) running their AI in their own thread (ie running as a separate agent). You have to be careful here though....you don''t want too many threads running simultaneously, or your CPU will spend more cycles switching between threads than actually executing the threads.
As for the synchronization, if you properly design your code, it should not be a problem.
Just think of it as another tool available to you. Use it when it makes sense. One thing I did notice though was that, until I learned to use threads properly, I tried to avoid them like the plague. Once you are very comfortable with their use (which requires practice), you''ll find that you will use them quite often.
MJB
Threads are finding their way into more and more games these days. I use several in my games (sound, input, rendering, script interpreting).
They are a pain, though. I wouldn''t recommend a beginner try them. The biggest problem is synchronization. For example, I have OpenGL rendering in one thread and lua scripts being executed in another thread. When the lua thread wants to draw something, it must access the matrices stored in the OpenGL thread. I have to make sure that these two threads never access this or any other data at the same time. The solution to this problem is called a mutex. If you want to try multithreading, make sure you understand mutexes at least as well.
The best thing in my opinion about threads is that a script can be interpretted without slowing the framerate overmuch. The framerate depends on the speed of the processor rather than on the speed of the script engine. If you are not using scripts, though, there really is no reason to use threads (except sometimes with sound. Notice that most sound libraries create their own threads to play music or wave files. DirectX does this.).
I highly recommend trying SDL. It''s not just a wrapper for OpenGL. It provides platform independent support for threads and mutexes (on most OSs. Technically SDL relies on the OS to do this, but you never see it). SDL is a great way to start out expirementing.
They are a pain, though. I wouldn''t recommend a beginner try them. The biggest problem is synchronization. For example, I have OpenGL rendering in one thread and lua scripts being executed in another thread. When the lua thread wants to draw something, it must access the matrices stored in the OpenGL thread. I have to make sure that these two threads never access this or any other data at the same time. The solution to this problem is called a mutex. If you want to try multithreading, make sure you understand mutexes at least as well.
The best thing in my opinion about threads is that a script can be interpretted without slowing the framerate overmuch. The framerate depends on the speed of the processor rather than on the speed of the script engine. If you are not using scripts, though, there really is no reason to use threads (except sometimes with sound. Notice that most sound libraries create their own threads to play music or wave files. DirectX does this.).
I highly recommend trying SDL. It''s not just a wrapper for OpenGL. It provides platform independent support for threads and mutexes (on most OSs. Technically SDL relies on the OS to do this, but you never see it). SDL is a great way to start out expirementing.
You're friend is coding in Java. Most likely in order for his game to work at all he MUST use a thread (MainGameClass implements Runnable). It's par for the course if you're writing Applets, Midlets, or almost any kind of realtime Java application.
If you were writting the same program in C/C++ your probably wouldn't explicitly use a thread at all. There would be no need for it. It's just a difference between developing with the two languages.
There are places where a C/C++ program WOULD explicitly use a thread, but these usually are not related to graphics. Often the network side of a game would be threaded (but not always) because it's not usually critical for the graphics and UI be in sync with a TCP/IP stack. Rian also gave some examples of using Threads in his programs. I've used threads for some C programs (like Chess) but 99% of the time I never do.
I hope this has answered your question.
Will
[edited by - RPGeezus on February 9, 2004 2:59:35 PM]
If you were writting the same program in C/C++ your probably wouldn't explicitly use a thread at all. There would be no need for it. It's just a difference between developing with the two languages.
There are places where a C/C++ program WOULD explicitly use a thread, but these usually are not related to graphics. Often the network side of a game would be threaded (but not always) because it's not usually critical for the graphics and UI be in sync with a TCP/IP stack. Rian also gave some examples of using Threads in his programs. I've used threads for some C programs (like Chess) but 99% of the time I never do.
I hope this has answered your question.
Will
[edited by - RPGeezus on February 9, 2004 2:59:35 PM]
I concur with MJB--
threads make utilizing the CPU efficiently possible. If you''re just a beginner, dont worry about it because you''ll have a ways to go before you NEED to use the CPU efficiently. But when you start finding your frames dropping because you''re spending too much time loading in resources, etc-- then you''ll start using threads.
Some good uses MJB didnt mention are:
* a non-blocking resource manager which loads resources from file and makes them ready to the game thru an interface. If the resource is not yet ready, the interface object has an imposter of some kind to draw instead.
* running a scripting engine - its best to keep this in a seperate thread as scripts are slower than C/C++ code. most scripting engines that you might plug in (such as Python or LUA) are already on a seperate thread, making threading transparent to you anyway
threads make utilizing the CPU efficiently possible. If you''re just a beginner, dont worry about it because you''ll have a ways to go before you NEED to use the CPU efficiently. But when you start finding your frames dropping because you''re spending too much time loading in resources, etc-- then you''ll start using threads.
Some good uses MJB didnt mention are:
* a non-blocking resource manager which loads resources from file and makes them ready to the game thru an interface. If the resource is not yet ready, the interface object has an imposter of some kind to draw instead.
* running a scripting engine - its best to keep this in a seperate thread as scripts are slower than C/C++ code. most scripting engines that you might plug in (such as Python or LUA) are already on a seperate thread, making threading transparent to you anyway
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
