GameInput Suitability for Win32/Terminal Apps

[TriceHelix]

Hi,

I've spent a couple of hours trying to make GameInput work in a plain Windows 10 Win32 (C++) app, configured via CMake. Including the GameInput.h header, compiling, and linking the executable all work as expected. There are no runtime errors. However, the IGameInput singleton does not provide any meaningful readings. Only one device exists, which is completely dead (no key, mouse, gamepad, or other kind of data is accessible). My code is as close to the examples available in the documentation as possible. My hardware is connected properly, drivers up-to-date, and everything else Windows-related is completely functional.

I have also tried building it as a Terminal application (plain int main() entry point, using std::cout to display read data), with limited success. Contrary to the Win32 attempt, my keyboard, mouse, and gamepad (Xbox One S Wireless Controller) are recognized by GameInput and I can detect pressed keys/buttons, mouse movement, etc. However, this behaviour is extremely inconsistent. For example, the mouse interface stops working after a few seconds (appears to be connected, but GetCurrentReading() always fetches the same IGameInputReading instance). What's worse is that after a system reboot, the code broke in a similar manner to the Win32 test. No code changes, no recompiles, simply a reboot.

I've also tried re-installing the entire GDK (I am using the latest version), to no avail. I cannot find any insight that might help me because most example projects are locked behind an NDA. As such, I hope to find some advice here.

• Is GameInput even suitable for Win32?
• If so, why is it so inconsistent? Are input events perhaps "consumed" by the GUI or otherwise blocked before they reach the underlying implementation?
• When can I expect this behaviour to improve, or to be further documented (troubleshooting guides, etc.)?

[TriceHelix]

Resolved:
Launching the built executable directly by double-clicking on it in the explorer instead of starting it from cmd.exe (or PowerShell) fixed all issues I had. No idea how that would influence the inner workings of the GDK, but maybe just a misconfiguration on my system. Sorry!