The thread that listens for inputs from the OS is its own thread. For Windows, this has to be the main thread—the thread that created the window. That means keep your game and render thread(s) off it. You can’t catch inputs accurately if the thread that listens for inputs is busy drawing a monster or colliding objects together.

but don't some parts of directx have to be on the main thread too? i could have sworn i saw something like that somewhere. I haven't had to go mutlithread for speed yet myself, so i'm not sure.

The correct solution is to only consume from the input buffer as many input events as took place during the logical-update period.
That is, since our logical update is 30 milliseconds, you consume only the next 30 millisecond’s worth of events from the buffered input, leaving later inputs in the buffer for the next logical updates to consume.

thereby keeping input and simulation in sync. clever.

the only thing you don't get is the visual feedback between sim steps, like you normally would without long frame times.

now if there was only a way to fix that....

if that last bit could be fixed, you would have the lowest possible overhead simulation, smoothest possible animation, a simulation that didn't get "ahead" of its input, and visual feedback every sim turn, irregardless of frame time. best of all worlds.


the obvious first thing would be to not let the sim run more that one turn between drawing frames when frame times were long.

but your frame times are already long, and now you're drawing a frame after every sim turn. so the number of sim turns queued up waiting to be processed would probably just keep growing, until the frame times dropped back down and it would eventually catch up.

but this is probably ok. for the following reason:

about the only way to get that screen update every sim turn when the frame time is high, is to SLOW DOWN TIME. you slow down everything (well, the sim, but probably not the input checker) to whatever the speed of the slowest component is (the graphics). sort of slipping into "bullet time" as it were. everything moves slow, except the player, who can still react to the slowly changing scene at his/her normal speeds. as the frame time drops back to normal, the simulation speeds back up.

so it may be possible to have the best of all worlds, if you have the game slowdown towards "bullet time" when frame times get long.

suddenly slowing down would probably be ok. the only other option would be to slow down the simulation gradually, which would allow it to get ahead of the graphics feedback to the player. but suddenly speeding up again might be a problem. one could always cap the rate of speed increase to some playable value.

so if slipping into "bullet time" is an acceptable solution for slowdowns, one can have the best of all worlds. having your cake and eating it too, very WITH my religion! <g>.

this means you wouldn't have to limit the game so much based on how many characters you can draw onscreen at once (unless you're developing for a console and they have a problem with the "bullet time" solution).

The thread that listens for inputs from the OS is its own thread. For Windows, this has to be the main thread—the thread that created the window. That means keep your game and render thread(s) off it. You can’t catch inputs accurately if the thread that listens for inputs is busy drawing a monster or colliding objects together.

but don't some parts of directx have to be on the main thread too? i could have sworn i saw something like that somewhere. I haven't had to go mutlithread for speed yet myself, so i'm not sure.

They have to be on the same thread but that need not be the main thread.

about the only other solution would be to slow the simulation down. like a governor driven by frame time. max speed sim can run at is a function of frame time. that would fix it, i think.

Sure, and this is how many games used to play, but:

• It's useless for multiplayer, since everybody has to be running the simulation at the same speed
• Who decides when the sim should start to slow down? I used to enjoy playing Doom at 15fps, and wouldn't have enjoyed it if you'd made it run at half-speed in order to give me the same reaction times as a 30Hz game.

I don't think this really works because acceptable reaction times and latency are subjective.

well, i'm primarily thinking single player here. the problem is protracted enough without adding multiplayer sync and lag to the equation. but you're right, bullet time probably wouldn't work well for multiplayer. in the case of multiplayer, there are likely sufficient temporary inaccuracies from lack of lockstep sync that trying to fix frame independant movement and long frame times is probably overkill.

but for single player, actually, it could be optional. either drop frames or go bullet time, player's choice. and the player could configure the FPS at which it started to slide into bullet time.

thats would allow them to tailor the "low end" behavior to their liking, while retaining all the "high end" performance advantages of decoupling the render, simulate, and getinput stages, IE the 3 basic parts of a game loop: draw, get input, move everything.

so you'd decouple render, getinput, and simulate. if bullet time slowdown was enabled, when render slows down to the user specified speed (FPS), you re-couple them (well, maybe just render and simulate). when render speeds back up, you gradually decouple them again.