Threads

probably a good idea!

It''ll be a good excuse to give my wife when I go buy a dual thunderbird MB & two chips

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 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