If you have little experience with Windows or multithreaded code just stick with a single-threaded model. You will run into a million little with a multi-threaded model. Someone who understands these issues can get around them. If youre not familier with mutex or Critical Sections then just stick with the single thread. I tried using multiple threads in my engine and it just made it more complicated and didn''t give any performance increase. Most of the time comsuming issues are done in hardware anyway( if your using DirectX or OpenGL ). I usually set everything up before I hit the message loop and clean everything up when GetMessage returns zero( that means someone posted a WM_QUIT message ).

Games shouldn''t be multithreaded, *especially* in Windows. You''ll see posts around here that will say otherwise (I think one awhile back said to use one for each enitity *gasp!*) but really, they should be avoided in 99% of the cases out there.

The only circumstance that I think that threads could be used is accessing files realtime as gameplay commences (such as Kings Field II and Castlevania: SOTN uses for Playstation). But even in these cases, it could be implemented without threads via states.

.travois.

why not multithread ??

i found it useful in making the frame rate constant all the time ...

useful for loading maps and files..

i usually process the mouse from a separate thread also ...

quote:Original post by Houdini

Doesn''t threads break platform independancy? If that''s not a good reason to not use them I don''t know what is.


- Houdini

Well by that logic, using C++ to program your game in is a bad idea because that too will break platform independency, since there are some platforms that you can''t program for in C++...

A lot of game functions are easier to keep in separate threads, like audio, file i/o, etc...

Don''t ever say games _shouldn''t_ be done in a particular way because there''s always situations where it''s better to do it in that way...