>> Nah that's too conservative to cover input->photon time

>> If you just count present->present

well, you have to get all the steps in there....

the input key press

the polling that picks up the key press

anything you do between the polling that picks up the key press and the update that processes it (probably nothing)

the update that processes the key press

the render of that update's output

and the present of that render

so its not time between subsequent presents, it time from end of one present to the end of the next present that includes all those steps, in a multi-threaded system those presents will not occur back to back. there will be some number of presents (one?) in between, as the two threads "overlap each other in terms of being in phase" so to speak.

>> If you fix the caveman download links, I can do some empirical tests with a 240Hz camera for you.

woah! you're tempting me to release another demo beta! and after getting just the kind of feedback you guys said i would on the last one - "it doesn't run 'cause my PCs screwed up!". <g>

i have 30 of 50 questgens left to implement an then its time for final graphics. i'll up the recommended requirements to 3Ghz and GTX 700 or 900 series, and the framerate limiter up to 30Hz or more. i may be able to go 45Hz without further optimization. SIMSpace and AIRSHIPs are both desiged for 30Hz from the get go. and all of these are pretty easy to change, just add a float multiplier to movement rates. that would be just 3 places in caveman: generic_move(ID) for band members, B2_animal_move(ID,amount) for NPCs and monsters, and move_missile(ID) for projectiles. or in OO terms: BandMember.Move(direction), NonPlayerEntity.Move(amount), and Missile.Move().

maybe then i'll take you up on your offer. but i doubt it will be required.

from the comments here it would seem that polling fast enough to catch short key presses is also an issue.

Hey, let's do some science. Set up a simple input system that polls at 60hz alongside an input system that simply logs all input state changes as they occur, then see if you can press and release a key fast enough to miss the polling.

Hey, let's do some science. Set up a simple input system that polls at 60hz alongside an input system that simply logs all input state changes as they occur, then see if you can press and release a key fast enough to miss the polling.

I'm curious what kind of game would need input so fast as that... You'd have to be superhuman beyond comprehension to trigger that combo...

someone here or on another recent thread was mentioning button presses on the order of 10ms. at 60Hz, you'd poll every 16.6ms. and polling would take less than 1ms most likely. so you could poll at t0=0ms, finish polling at t1= 1ms, press the button at t2 = 1.5ms, release at t3=11.5 ms, and the next poll occurs at t4=16.6ms. and just like that you missed an input entirely.

It depends on the type of API being used -- message queues or snapshots.

On Windows, the Keyboard, Mouse and USB game devices use an event queue. So in the "short press" situation, you just get a "press" and "release" event on the one frame. At low framerates, you may even get a whole load of individual "press" events per frame! So, this is ideal :) The best of the best design would be this, along with timestamps attached to the events, so a low-polling-rate game could still inject them with the original spacings into a simulation.

However, for some reason, XInput -- the standard gamepad API for Windows -- is a non-buffered snapshot API... Each time you poll it, it tells you the gamepad state at that point in time only, so, if you don't poll fast enough, yep you could miss events :o

There's also some snapshot APIs that avoid dropping short presses, e.g. by returning two bits per key that's polled. One bit specifies whether the key is down at the moment, and the other bit specifies whether it has been down at all during the period of time since the previous poll call.

I'm not sure about GetAsyncKeyState - it might have XInput's flaw, or it might be 'sticky', where keys only "unpress" after being polled...?

someone here or on another recent thread was mentioning button presses on the order of 10ms. at 60Hz, you'd poll every 16.6ms. and polling would take less than 1ms most likely. so you could poll at t0=0ms, finish polling at t1= 1ms, press the button at t2 = 1.5ms, release at t3=11.5 ms, and the next poll occurs at t4=16.6ms. and just like that you missed an input entirely.

Yeah, science sucks, lol.

>> On Windows, the Keyboard, Mouse and USB game devices use an event queue

do you know off hand if that's hardware driven or polled? hardware driven, id imagine. it can't miss a keypress can it?

as i recall, getasynckeystate is a hardware driven "state lookup table".

googling...

well, looks like its one of those snapshots that returns 2 bits, but its not preemptive multitasking compatible, so you can't count on the 2nd bit (another task might eat it first), you can only count on the current state. so that would seem to imply that it is a hardware driven state lookup table, and is prone to missing keystrokes if not polled frequently enough.

and the message pump is a hardware driven event queue, but with no time stamps...

all you can say is "these things occurred at some point between now and the last time i checked the queue."

seems there's no easy answer for that.

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).

>> On Windows, the Keyboard, Mouse and USB game devices use an event queue

do you know off hand if that's hardware driven or polled? hardware driven, id imagine. it can't miss a keypress can it?

AFAIK it doesn't miss events, unless you let the queue run out of RAM :)

and the message pump is a hardware driven event queue, but with no time stamps...

all you can say is "these things occurred at some point between now and the last time i checked the queue."

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.

AFAIK, quake has usually used a 500Hz input polling thread.

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).

I gave you two examples of where other orders are used to decrease input latency.

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.

>> I gave you two examples of where other orders are used to decrease input latency.

yes, i guess that one long poll and long update vs many short polls and updates would count as a different order. i tend to think of it as analogous to "stepped movement for missiles", IE many short updates instead of one long one, but since its both polling and updating it is technically a different ordering.

thanks to everyone for the answers!