Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

This topic is 6625 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

How bad of an idea is it to use a few threads to perform the various functions required by a game? One for rendering, one for IO, one for AI? (I program Dyno software for a living - big testing machines for stuff - and we use a number of threads...)

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Sounds okay in principle. For flash people with multiple proccessors it should run a breeze. I don''t think that people on single processors will notice any difference.

I''m sure that people will have a go if I''m wrong.

Share this post


Link to post
Share on other sites
The program shouldn''t become "jumpy". Even if you have separate threads for rendering and logic you will have to sync every frame so your io is handled as fast as possible. Currently the most time of a game is spend in the rendering section (waiting for and feeding the hardware. Theoretically one thread which occupies cpu 2 whith rendering should allow cpu 1 to crunch physics and logic and whatsoever. The problem is syncronisation. Your 3d data (or parts of it) will be needed by the renderer (mostly just reads but perhaps you want to cache some tesselation results so you will have to write to) and it will be needed by the physics (bounding boxes for collision detection and influence of forces) and it will be needed by the ai (move and animate characters). To minimize the dependencies of all these tasks (which could be seen as threads) you have to design your system therefor. A mutltibuffer approach (buffers contain data per frame so the logic could process the next frame and fill the buffers of the next frame) might come in handy (like in sgi performer).

As most games are single threaded I doubt that multi threading is really needed as it introduces lots of new problems. However multi threaing is cool and it''s a challenge technologicaly and from an engineers standpoint :-)

So if you go the "threading way" it would be very nice if you post your insights here ;-)

Bjoern

Share this post


Link to post
Share on other sites
I could purposefully keep the renderer one frame behind the game logic.

Maybe three geometry buffers; GeoLogic(primary), GeoBuffer(secondary), GeoRender(trinary sp?)

        
//

Logic locks the primary
while(!exiting)
Logic thread thinks hard
if(newIO)
interpolate to newio (over a few frames so it's smooth & not jerky)
else
cubic dead-reckoning
Logic lock secondary
Swap primary secondary
Logic releases Secondary
Logic sends msg to Render 'New Frame'
wend

//

Render locks trinary
while(!exiting)
while(msg!='New Frame')
Render sleeps, waiting for 'New Frame'
wend
Render locks secondary
Render swaps secondary trinary
Render thread draws like mad
wend

//

while(!exiting)
while(msg!=IO)
IO sleeps
else
cook IO
send msg to logic thread
wend


And so long the logic thread didnt go off & beat pud everything should stay perfectly out-of-sync - if the render thread beats pud, you skip frames...


Edited by - Magmai Kai Holmlor on June 25, 2000 6:48:01 PM

Edited by - Magmai Kai Holmlor on June 25, 2000 6:49:08 PM

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!