AFAIK it doesn't miss events, unless you let the queue run out of RAM
>> On Windows, the Keyboard, Mouse and USB game devices use an event queue[/size]
do you know off hand if that's hardware driven or polled? hardware driven, id imagine. it can't miss a keypress can it?[/size]
Some people work around this by running a dedicated poll+timestamp thread thread at 1000Hz, and then having their update thread read from this timestamped queue.
and the message pump is a hardware driven event queue, but with no time stamps... [/size]
all you can say is "these things occurred at some point between now and the last time i checked the queue."[/size]
AFAIK, quake has usually used a 500Hz input polling thread.
I gave you two examples of where other orders are used to decrease input latency.
well, at least my original question was answered. nobody came up with an example of a different order at all, much less one that didn't introduce lag. i suppose that makes sense. if you have to do each step A thru E in order, then ABCDE is the shortest path - whether its all on one thread or spread across two (one, then the other).[/size]
1) When the game is GPU bottlenecked, or display-vsync bottlenecked, and when you're left with enough CPU time to increase the update+poll rate above the render rate, then increasing thr update+poll rate can make it feel more responsive. Worst-case input latency remains the same, but average input latency can dramatically improve.
2) when the sim is fixed at a low frequency - e.g. a 10Hz large scale RTS - increasing the poll and render rate not only provides smooth animation, but makes the GUI much morse responsive, allowing orders to be given more easily and feedback of commands given immediately (well before the next sim tick).
Or 3 ,above, when the relative timing of inputs matters to gameplay, such as in a rhythm game, polling at a much higher rate than the sim reduces quantization error and allows timestamping, making inputs feel more responsive and accurate.