This also refactors target configuration storage to reduce the redundancy in copying the same set of files for every target. Each configured entry now instead uses a .ini file with the name of the entry stored in ./targets. SteamTarget can accept the path to a .ini file as a command line argument.
This also fixes the UI so that inputs are ordered the same as the visual order so that tab behavior isn't confusing.
By using VID and PID of Valve's SteamController, Steam doesn't give us ANOTHER "fake" XInput device
Therefore it's not necessary anymore to count controllers before we plug in any virtual controllers
By Unhooking Steams hook to XInputGetState, we can detect how many Controllers Steam "emulates", before pluggin in any virtual controllers.
This *should* enable the use of multiple Valve SteamControllers.
The unhooking procedure currently only works on AMD64 and prob. only with XInput1_4
Found out GameOverlayRenderer likes to post very specific messages
Now, instead of memory reading some value from some address, which changes in updates, examine the messagequeue of the process to get overlay status
done by mid function hooking a function in steamclient.dll
the function appears to be setting the appId of the new controller bindings
inject/hook right after the target launched
switch focus -> binding gets changed to shortcut bindings -> hook function grabs appid
hook function replaces desktop-config appid with the one grabbed everytime steam tries to active desktop-config
glosc_gamelauncher unloads dll when the target closes; unloading dll patches steamclient.dll back to original
this significantly reduces input-lag while keeping cpu usage at a minimum
also removed any of the vsync / framerate options as we now always render the overlay with 60fps
this reduces cpu usage and unnecessary overhead if playing with the default option of vsync on high refresh rate displays
