Threads

Started by
6 comments, last by Shannon Barber 23 years, 10 months ago
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...)
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Advertisement
probably a good idea!
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.
It''ll be a good excuse to give my wife when I go buy a dual thunderbird MB & two chips
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
I don''t know; seperating rendering from logic could make the game a little jumpy. But for IO it should be fine.

lntakitopi@aol.com | http://geocities.com/guanajam/
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
What I mean by "jumpy" is that if the physics thread is halfway through moving a set of objects when the render thread renders to the screen, half of the objects will be moved and half won''t. It will probably be very minimal, but it might still be noticeable.

lntakitopi@aol.com | http://geocities.com/guanajam/
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 primarywhile(!exiting)Logic thread thinks hard  if(newIO)     interpolate to newio (over a few frames so it's smooth & not jerky)  else    cubic dead-reckoningLogic lock secondarySwap primary secondaryLogic releases SecondaryLogic sends msg to Render 'New Frame'wend//Render locks trinarywhile(!exiting)  while(msg!='New Frame')  Render sleeps, waiting for 'New Frame'  wendRender locks secondaryRender swaps secondary trinaryRender thread draws like madwend//while(!exiting)  while(msg!=IO)    IO sleeps  else    cook IO    send msg to logic threadwend        


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
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

This topic is closed to new replies.

Advertisement