I vouched for your post, I had a questions and a comment!
1) games on Windows frequently use DirectInput[a], it would be a nice addition to your application. Is it possible with autoit ?
2) Your application is simple enough (without direct input) that you could write it in 32bit assembly. It would be a great learning experience to rewrite it in the lowest level language. If you want to go that way I recommend those tutorials [b]. Don't be scared, assembly is one of the easiest way to explore the win32 api.
1) I think anything that Autoit can DllCall with should be doable though I'd need to really study and play around with how the API works to get a good idea of how it could be integrated or if it is more appropriate as a separate application. It seems that DirectInput is generally deprecated nowadays, Microsoft suggests rawinput for message-based devices like Mice/Keyboard, and XInput or directly querying HID file for state-based devices like Joysticks. It would definitely be interesting to experiment to figure out why older games that used DirectInput have issues such as dropped inputs etc.
2) Thanks for pointing that out! I definitely want to figure out how the least possible latency overhead could be achieved for accurate timestamping of input events. Pretty much all frameworks like SDL2 used by games all seem to use a polling based approach for message retrieval, which makes reliable timestamping impossible. It is due to this flawed polling philosophy that esport games all need framerate far above refresh rate because, despite Windows already providing the machinery to accurately sequence user inputs, commercial game engines just dump all the work into each frame and so you actually lose input-order information within a frame. Particularly notorious is Valorant's clunky aiming despite Riot's self-congratulatory "esport-focused optimization" that mostly just made things worse, like reintroducing floating-point camera jitter because they changed from UE4's default quaternions into successive rotation matrix multiplications.
It seems that DirectInput is generally deprecated nowadays.
Sorry, it has been a long time since I last read on windows input methods, the docs says your right about DirectInput!
use a polling based approach for message retrieval... Windows already providing the machinery to accurately sequence user inputs
I'd like to know about those api ! Because as far as I know, if you go low level enough (but stay in userland) it appears that polling is the only way to get the input event in a Windows application. If a framework offers you some callback mechanism, it is an abstraction over the event loop[0] or the polling of the gamepad state.
Also the link I had in my bookmarks for win32 assembly programming has semi rotted, I found another working link[1]
While the tutorial I suggested are old and in x86 assembly, the concept presented are still relevant and the instructions and registers are still available in x64 ASM.
I don't suggested that you stay in assembly (nor autoit ;) ) to write complex applications but that knowledge will make you a better system programmer without giving you bad habits like C or a C like language would. So when your done with the first few tutorial I linked, you could learn a highlevel language like nim[2] and a system language like rust[3].
Basically, for message-based devices like mice, because the RawInput API just simply posts messages to the application's message queue, the events arrive in exactly the order as had been generated by the hardware. All the application needs to do is to process them message-by-message, rather than lumping the result together as a single state.
In the glfw code you linked, you can see that they use `PeekMessage` as a non-blocking way to check for presence of events in the message queue. This is also the case for basically every other frameworks too like SDL2, when what they should be doing instead is have a separate lightweight thread that runs the blocking `GetMessage` counterpart, and the very first line to execute right after `while GetMessage` is to query the high-precision timer to timestamp the exact instant that the OS places the message in the queue.
Frameworks that offer "blocking" versions of their API call don't actually use the blocking call, they just simply skips the game loop until they happened to poll a message, so it is still beholden to the poll timing rather than the OS's unblock timing.
2)
Thanks, I actually found the same link after Googling the tutorial name of the rotted link. I'm actually looking to have Rust as my "main" system programming language.
However, the biggest annoyances for all of the compiled language that I've surveyed is the lack of a "dummy-proof" portable way to set up the toolchain, unlike AutoIt where I can drag the text file to an exe and instantly test it. I really dislike having dependencies installed on my main OS; Docker as a "click and forget" compiler was promising at first but the setup process is still something that I had to look up, which just eventually became too much of a cognitive hassle and ended up reverting to the "easy prototyping" languages whenever I'm doing anything exploratory, which means that I never ended up having those exploratory scenarios being applied on the languages that I needed to familiarize myself with.
1) games on Windows frequently use DirectInput[a], it would be a nice addition to your application. Is it possible with autoit ?
2) Your application is simple enough (without direct input) that you could write it in 32bit assembly. It would be a great learning experience to rewrite it in the lowest level language. If you want to go that way I recommend those tutorials [b]. Don't be scared, assembly is one of the easiest way to explore the win32 api.
a) https://docs.microsoft.com/en-us/previous-versions/windows/d...
b) https://www.winasm.org/iczelion-tutorials.html