I am reimplementing input systems in my home grown engine. I went to integrate steamworks and the steam controller with it and discovered I would need to use polling to accomplish the task. (Unless they actually do have a callback system somewhere, or a message pump - whatever though)

So I have a design that sort of works like this:
InputSystem <- InputMapper <- Contextual Bindings
InputMapper <- InputBindingDigital <- InputStateDigital -> InputStateDigital_SteamController
Or..
InputMapper <- InputBindingDigital <- InputStateDigital -> InputStateDigital_Keyboard

and also this..
InputMapper <- InputBindingAnalog <- InputStateAnalog -> InputStateAnalog_SteamController

So I'd be integrating any device through the InputState classes. I am not really here to discuss whether or not this is a good design, open to brief opinions/tips or any gotchya's there might be.


My question to you is what API would you all recommend?

I need to implement keyboard polling, I care most about the latency of API calls, but simplicity is also important. I suspect the simpler the API is the lower the latency of calls.

I did a bit of research to find API's that provide polling interfaces, but I couldn't find anything definitive about latency.

SDL_GetKeyboardState( ... ) - SDL
glfwGetKey( ... ) - glfw
GetKeyState( ... ) - windows.h

i typically poll at 15 Hz minimum. its about as slow as you can go and still be sufficiently responsive.

So that function must be defined with <Windows.h> right?

Where do you have your input polling?

Do you keep it separate from the game loop?

Perhaps different threads?

That is how I intend to do it, so I am just curious if I am doing it a common way.

i typically poll at 15 Hz minimum. its about as slow as you can go and still be sufficiently responsive.

If we assume that his game works at 60 FPS, that means that he polls the keyboard state once per frame.

i typically poll at 15 Hz minimum. its about as slow as you can go and still be sufficiently responsive.

If we assume that his game works at 60 FPS, that means that he polls the keyboard state once per frame.

Well not quite, that would be 60Hz @60FPS. 1Hz is equal to 1 cycle per second.

this is the single keyboard input routine i use in all my games:

GetAsyncKeyState(vkey);

typically poll at 15 Hz minimum

May I say that I consider this a terribly ill-advised strategy? Polling is, in my opinion, something one can do as a last resort, if nothing else helps. But never as "the one" default solution for all applications.

Polling has one very obvious problem (it needlessly burns CPU), but also a not-so-obvious problem: it is unreliable. And what's worst, it is unreliably unreliable -- you cannot even be sure that it doesn't work. Most of the time it "works fine", except when it doesn't. Which can make reproducing an issue a real pain.

This being unreliably unreliable comes from the fact that you do not record transitions between states, but you take discrete point samples. If your sampling frequency is high enough, this "works", but you have to go quite high to be on the safe side. Correctness is always subject to probability, and the transition from "works" to "fails" is smooth. You will probably never see a difference for turning the joystick/steering wheel left or right, but you might, and will, for other things.

For example, if a young hyperactive user with healthy fingers hits the "fire" button quickly, the "button down" state may very well live for only around 50-60ms. Well, that's great... 50% chance that you sample the key while it's down, and 50% chance that you're too early or too late.

Or you might encounter scheduling jitter, and instead of the intended 66.66ms (=15Hz) your process sleeps 80ms or 90ms. It's as if the user never pressed the button! Or maybe it works 99 out of 100 times and only fails in the most user-upsetting moment in the middle of a boss fight (quite possibly it even always works when you try it because your fingers are older and your computer is faster).

No such thing can happen if one processes events. Events are on/off, yes/no, black/white. Polling is... maybe.

as i recall getasync is powered by hardware interrupts

More like hardware interrupts generate key up / key down messages which go through the system's low level message queue, and then at some point set/clear a boolean flag per key in some global state table, and you test the flag in that table each time you call GetAsyncKeyState.

My question to you is what API would you all recommend?

Without really knowing anything about the steam controller (but having looked at the description online), I would still recommend a solution that uses messages (so... virtual keyboard or capturing a "joystick" with old multimedia functions).

If I understand what's online correctly, the Steam controller can simulate either a virtual keyboard or a Gamepad (which is basically... a more or less "ordinary" joystick with a few more buttons and FF). Which means you should be able to use the old multimedia functions that place events in your event queue (in gamepad mode), or just handle the generated keyboard events without even knowing that they actually come from a special controller. Even if the old multimedia functions poll internally (I don't know if they do, but might as well), processing messages is still the "correct" approach. It is as correct and as good as you can get on your end.

But of course, there's also XInput... which, ironically requires you to poll... :rolleyes:

this is the single keyboard input routine i use in all my games:

// returns 1 if vkey is pressed, else returns 0

int Zkeypressed(int vkey)

{

SHORT a;

a=GetAsyncKeyState(vkey);

if (a & 0x8000) return(1);

return(0);

}

as i recall getasync is powered by hardware interrupts (IE it reads key state at a very low level from a data structure maintained by the OS and updated whenever a keyboard hardware interrupt occurs), so no latency.

i typically poll at 15 Hz minimum. its about as slow as you can go and still be sufficiently responsive.

This might be enough for slow games, but if you need to catch double-clicks or fast input with precise timing in general (eg for an FPS or an RTS), then you're looking at sub-10 millisecond intervals, which you can't trap with low-frequency polling. 60Hz translates to a 16.6 ms per tick, which will cause your game to lack responsiveness. This is doubly confusing if you need to respond to key up events.

Respond to WM_CHAR/WN_KEYDOWN/WM_LBUTTONDOW and their up versions instead.

That being said, unless you need it, synchronization between the input and logic threads can be bothersome, which GetAsyncKeyState() avoids.