Hi, I''m trying to design the core part of a game engine under windows and I''m seriously thinking about putting the graphics engine and the sound engine in their own threads separate from the rest of the engine. I was planning on using the windows message pump to pass events to each engine but I have no idea how responsive the windows message pump is in practice. It''s not going to be good if the latency is large enough to cause a noticeable delay between an event on-screen and the accompanying sound effect (I''m not going for that poorly dubbed Hong Kong action movie look ;-) ). So, my question is how fast is the windows messaging system? Is the latency low enough to sync events in separate threads and not cause a slowdown in frame rate in the graphics engine? Thanks in advance, any help is greatly appreciated -Daedalus

I recall an article at sysinternals.com pertaining to timing increments in windows. I don''t remember if it was specifically concerning the messaging system. This article makes reference to it and even though it''s a bit off topic, it does discuss timing issues under Windows: Detecting Vertical Retrace in Microsoft Windows

Thread context switching is costly, you''ll want to look into that more closely. I''ve seen a couple of forum topics on that subject in the last month or so. Here''s one

Wolve''s advice is probably similar to the route I''d take if I decided to move different components of an engine into different threads. However on its own a global structure refrerred to by all threads isn''t thread safe, with the addition of some form of synchronisation such as a critical section it''d be fine (and in fact a very common way of doing things).

Multiple threads live in the same process, even if they are in different DLLs, and therefore the same process address space - so its totally legal, valid and safe for one thread to access the variables which might be in a different module.

Window messages are really for passing user interface messages between different active windows (e.g. controls are active windows which get messages). Messages go into a queue based on priority - which means there could be quite a big delay in communication between components of your engine if any higher priority messages happen. Particularly since all your engine components will be very likely to be in the same process, windows messages would be a bad choice.



--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Aren''t things like DirectSound and DirectShow (if you want to play mp3s/whatever) already asynchronous? Why create threads for your sound engine when DirectX can handle that?