Let''s assume we are making a Windows FPS game. Obviously since it is an FPS, speed and optimization are key. I don''t know if this is standard operating procedure, a weird idea, or just plain not feasible, but would it work if we separated JUST the graphics code from the remainder and ran it as a separate thread? So that there would be two threads, one handling sound, physics, networking, etc, and the graphics thread simply reading off the constantly-being-updated polygon data and rendering it onscreen? Is Windows'' thread synchronization even half-competent enough to handle something like this? Thanks in advance for replies. Hi there, I''m AnCcE, and you''d be too if you weren''t somebody else.

I don''t think it is. I haven''t tried it, but I''ve heard that it gets out of sync.

JoeMont001@aol.com www.polarisoft.n3.net

Yep, it can be done. Also, seperate threads are used for input so the mouse input isn''t stalled by the program loop. as for how to do it, I have no idea...

The point of that idea is that the graphics code wouldn''t be quite as held back by waiting for the physics and all that to finish, so it wouldn''t matter if they got a little bit out of sync, the idea is for the graphics to continue rendering while the input and physics are running updates to the data based on a timer system... Good idea, separating input into another thread too...

Hi there, I''m AnCcE, and you''d be too if you weren''t somebody else.

AnCcE:
- what if the drawing thread ran twice as fast...you would draw the same scene twice...waisted cycles.
- what if the drawing thread ran slower...you calculate movements with twice as much calculations, and use more network resources than needed...waisting cycles & network traffic

Have you tried "on idle" processing? (In your messageloop - not the WM_ENTERIDLE message)




Edited by - baskuenen on September 10, 2000 10:07:53 PM

I think most games just get data from physics module and pass it onto rendering module so you update physics then display new info or position based on previous physics situation. However while reading MSDN doc on multithreading or was it somewhere else, anyway... some author mentioned that certain artificial intelligence is easy to do by multithreading otherwise you have to implement some clock that switches between running AI code if not doing it through threads. The author also mentions that some AI is impossible to do without threads so I think this would be something you would read about when you get to do AI stuff which so far I haven''t. Personally, I think threads would be a boon if you ran under multi-cpus otherwise one cpu still switches between threads which are not run at the same time but instead one after another gaining little advantage if any and introducing unwanted complexity. Try threading yourself and report your findings here, I sure would like to find out if it''s something we all should be doing on single cpus.

my homepage
E-Mail: BlueOrbSoftware@mailcity.com

I don''t think I was as clear as I should have been with my first post... My idea was that there could be a bool or something that the main graphics loop checks to see if it needs to redraw i.e. when the input module has put its stuff through physics and the scene onscreen is no longer accurate. The idea doesn''t involve passing anything to any graphics functions, it just involves setting a global bool which would trigger the graphics module to render the vertex data which would already be global.

Hi there, I''m AnCcE, and you''d be too if you weren''t somebody else.

Hi all.

What about 2 sets of the global data? While the graphics engine is rendering one set, the game logic is updating the other set.

The game logic keeps on bool which indicates which set is most current. The graphics engine keeps a bool which indicates the set currently or last updated. When those 2 flags are deferent, and the graphics engine is done with the previous set, the it updates it''s flag to match that of the game logic, and goes to render the other set.

But then again, I shall agree with JD in one point: task switching takes time, and according to what I have read in another possts, especially in Windows. In order for this to work at the most eficient level you need 1 CPU per thread.

Topgoro


;You are not a real programmer until you start all your sentences with a semicolon

Topgoro: You have just re-invented triple-buffering

Basically back in the bad old days you would have an interupt handler blast your off-screen(main memory) info to the video card
while you worked with a seperate main memory buffer. This was for pixels, but the idea is basically the same.

Basically it ain''t worth it. D3D/OpenGL give fairly close to the same semantics without the headaches.

Topgoro is right, Windows isn''t particularly good at context-switching. In layman''s terms, while threads all operate simultaneously from a conceptual perspective, the OS really just executes one for a little bit, then the next for a little bit, and so on, in a continuous loop. The OS switching from executing the code of one thread to the code in another is called "context-switching."

Now for whatever reason, Windows has a rather high cost associated with context-switching, so it''s generally not a good idea to have much more than 1 thread per CPU (they give you all these nifty features and then tell you not to use them eh?).

For something like this, however... The game engine could do its thing and write frames into memory somewhere and then signal the rendering engine that a frame is ready. The rendering engine could wait on a "frame ready" signal and when it''s woken up it would process all available frames and then go back to sleep. Basically, the rendering thread would be blocked until it had work to do. This seems like a feasible solution (and most likely what is happening in the dual-cpu version of the quake 3 code), but you''ll need to experiment to see how it affects performance. From a conceptual standpoint, you''re right, it''s a nice clean way to separate rendering code from the other engine code. I would imagine that 2 threads may offer a performance benefit if the code were done right, though as the number of threads increases expect to see performance degrade (because you''re going to be doing more and more context-switching).