3 ms·

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

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]. 0) https://github.com/glfw/glfw/blob/97da62a027794d9ff0f4512268cb9a73a8fb5073/src/win32_window.c#L1957 https://github.com/glfw/glfw/blob/97da62a027794d9ff0f4512268... 1) http://www.website.masmforum.com/tutorials/index.htm http://www.website.masmforum.com/tutorials/index.htm 2) https://nim-lang.org/ https://nim-lang.org/ 3) https://www.rust-lang.org/ https://www.rust-lang.org/

EsportToys 4y ago
1) 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.

EsportToys 4y ago

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