Hi MASM community!
I was working on a simple 2d game using the win64 API. I understand that using 64-bit is overkill for a lot of things, but I thought that this would be a fun and highly engaging challenge to keep me busy!
I came across input handling for my game after having all the items set-up and ready to go for it. However, the way I had it designed originally using GetAsyncKeyState function had me very dissatisfied because I simply didn't like how the input felt using this to interpret keyboard data.
After a bit of thinking I thought that the best approach would be to use Raw Input data. I was going to use RAWINPUTDEVICE Struct, as suggested by other forums, microsoft, and games before me, but I came across the struggle that this item actually isn't in the win64.inc file or at all in any part of win64 api. However, it does exist in the 32 bit windows.inc file. I was also looking around for WM_INPUT Message. To my surprise this item also doesn't exist within win64. :nie:
I guess what I wanted to ask after all this information presented itself to me was to understand, outside of architectural differences, why are there certain items that don't exist from win32 to win64 such RAWINPUTDEVICE struct and WM_INPUT?
I'm not sure if I should manually create the struct and the message value myself?
What effect would that have on my application if I used something meant for win32 and brought it to win64? I would assume it would be backwards compatible.
Also, does anyone here have any experience setting up their program to use raw input? I would seriously appreciate some examples! :biggrin:
Thank you for the read! If I need to elaborate more, please let me know!
The short answer is just that the 64-bit MASM package here is woefully underdeveloped and missing tons of stuff. Not by design, just by lack of effort.
Which doesn't bother me in the least, as I find Win32 to be more than adequate for any programming tasks I want to undertake.
Since it sounds as if you are only looking for input from the keyboard, might I suggest that you look for these messages in your window procedure: WM_KEYDOWN & WM_KEYUP for a lower-level implementation, or WM_CHAR to capture keyboard characters as they're typed.
Very easy to implement.
Quote from: NoCforMe on March 25, 2025, 10:41:24 AMSince it sounds as if you are only looking for input from the keyboard, might I suggest that you look for these messages in your window procedure: WM_KEYDOWN & WM_KEYUP for a lower-level implementation, or WM_CHAR to capture keyboard characters as they're typed.
Very easy to implement.
Hi NoCforMe!
I have tried using those messages, but when I do, there seems to be like a quarter of a second delay... I originally did want to try using the WM_KEYDOWN. But I was unhappy with the results due to the delay. So then I moved to trying GetAsynchKeyState
What my vision for the program was, is to have very crisp and responsive inputs.
Interesting, that delay: I totally get that you don't want that!
So what's your environment? DOS? Windows (x)?
I use the "raw" keystroke messages in Windows 7 and have never experienced any delay.
Quote from: NoCforMe on March 25, 2025, 11:15:43 AMInteresting, that delay: I totally get that you don't want that!
So what's your environment? DOS? Windows (x)?
I use the "raw" keystroke messages in Windows 7 and have never experienced any delay.
currently, I am using Windows 11. How do you setup raw input for windows 7?
I should clarify what I mean by "raw" keystroke messages: by that I mean the basic messages like WM_KEYDOWN and WM_CHAR. I don't mean the "raw input" mode that gives you WM_INPUT messages.
If you don't already know, to receive WM_INPUT messages you first need to register your application with the raw input device(s) you want to access; this is done through the RegisterRawInputDevices() (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerrawinputdevices) function (click link for the Micro$oft Learn page on this). You'll need to set up one or more RAWINPUTDEVICE (https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-rawinputdevice) structures to do this.
I have no idea how to use "raw input" this way, as I've never played around with this. Seems kinda complicated ...
BTW, are you sure the delay handling keystrokes isn't due a delay somewhere in your code? As I wrote before, I've never experienced any kind of delay handling keyboard input using the low-level keyboard messages (not WM_INPUT).
Quote from: NoCforMe on March 25, 2025, 11:53:47 AMI should clarify what I mean by "raw" keystroke messages: by that I mean the basic messages like WM_KEYDOWN and WM_CHAR. I don't mean the "raw input" mode that gives you WM_INPUT messages.
If you don't already know, to receive WM_INPUT messages you first need to register your application with the raw input device(s) you want to access; this is done through the RegisterRawInputDevices() (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerrawinputdevices) function (click link for the Micro$oft Learn page on this). You'll need to set up one or more RAWINPUTDEVICE (https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-rawinputdevice) structures to do this.
I have no idea how to use "raw input" this way, as I've never played around with this. Seems kinda complicated ...
BTW, are you sure the delay handling keystrokes isn't due a delay somewhere in your code? As I wrote before, I've never experienced any kind of delay handling keyboard input using the low-level keyboard messages (not WM_INPUT).
You know what, I actually haven't tried WM_CHAR yet! hopefully this is my solution! I'll give it a shot and let you know!
AV software could also be slowing down your code, while 'inspecting' it. What Antivirus software are you running? Any "realtime" protection may be interfering here...
This may give some clue for the apparent slow reaction time for keyboard messages.
Quote from: zedd151 on March 25, 2025, 12:16:46 PMAV software could also be slowing down your code, while 'inspecting' it. What Antivirus software are you running? This may give some clue for the apparent slow reaction time for keyboard messages.
Hi Zedd151!
I am not running any sort of AV right now.. I have windows defender disabled currently.
Okay, that is not the issue then. Good to hear it. My PC would grind almost to a halt when realtime protection was enabled, especially for my tiny assembly programs. :smiley: AV software typically deems small assembly programs as 'suspect' and scrutinizes them endlessly and sometimes quarantining them. Those days are gone for me forever. On Windows 10, btw.
Carry on. :tongue:
I am with NoCforMe on this one. Since it is not an AV issue, something must me amiss in your code. Keyboard messages are supposed to be handled instantly whether using WM_KEYUP, WM_KEYDOWN, or WM_CHAR. (Or at least have the perception of instantaneous action)
Quote from: NoCforMe on March 25, 2025, 11:53:47 AMI should clarify what I mean by "raw" keystroke messages: by that I mean the basic messages like WM_KEYDOWN and WM_CHAR. I don't mean the "raw input" mode that gives you WM_INPUT messages.
If you don't already know, to receive WM_INPUT messages you first need to register your application with the raw input device(s) you want to access; this is done through the RegisterRawInputDevices() (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerrawinputdevices) function (click link for the Micro$oft Learn page on this). You'll need to set up one or more RAWINPUTDEVICE (https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-rawinputdevice) structures to do this.
I have no idea how to use "raw input" this way, as I've never played around with this. Seems kinda complicated ...
BTW, are you sure the delay handling keystrokes isn't due a delay somewhere in your code? As I wrote before, I've never experienced any kind of delay handling keyboard input using the low-level keyboard messages (not WM_INPUT).
to elaborate more on this, I have tried to set-up the RAWINPUTDEVICE struct, but every time I set that item up, I get 03E6 error in GetLastError.... when I set it up, I'll show you what I tried in setting that up in one moment.
since I'm on x64, we're using fastcall, I have tried also setting hwndTarget to DD to see if that might be the issue too. RCX should also be an array of RAWINPUTDEVICE struct from my understanding... I tried to set it up like this but I have a theory that I could be doing it wrong too.
RAWINPUTDEVICE STRUCT
usUsagePage DW ?
usUsage DW ?
dwFlags DD ?
hwndTarget DQ ?
RAWINPUTDEVICE ENDS
RawInputDevices RAWINPUTDEVICE <>
.code
....
;whatever code here to get to setting up RAWDEVICEINPUT Struct
mov WORD PTR [RawInputDevices.usUsagePage], 1 ; Generic Desktop Controls
mov WORD PTR [RawInputDevices.usUsage], 6 ; Usage for Keyboard
mov DWORD PTR [RawInputDevices.dwFlags], 0 ; No special flags
mov DWORD PTR [RawInputDevices.hwndTarget], RAX ; I have also tried setting this to 0 as I have heard that you can set it to 0 and it follows the keyboard's focus. But it still yielded the same result.
mov RCX, OFFSET RawInputDevices
mov RDX, 1
mov R8, SIZEOF RAWINPUTDEVICE
call RegisterRawInputDevices
Call GetLastError
RAX = 00000000000003E6
Try WM_CHAR and let us know how it works.
That "raw input" stuff is just too damn complicated.
BTW, rather than just displaying a meaningless hex value from GetLastError(), use this to actually display a message showing what the error actually is:
ShowLastError PROC
LOCAL buffer[256]:BYTE
CALL GetLastError
MOV EDX, EAX
PUSH EAX
INVOKE FormatMessage, FORMAT_MESSAGE_FROM_SYSTEM OR FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, EDX, 0, ADDR buffer, SIZEOF buffer, NULL
INVOKE MessageBox, 0, ADDR buffer, NULL, MB_OK
POP EAX
RET
ShowLastError ENDP
Quote from: NoCforMe on March 25, 2025, 12:35:09 PMTry WM_CHAR and let us know how it works.
That "raw input" stuff is just too damn complicated.
BTW, rather than just displaying a meaningless hex value from GetLastError(), use this to actually display a message showing what the error actually is:
ShowLastError PROC
LOCAL buffer[256]:BYTE
CALL GetLastError
MOV EDX, EAX
PUSH EAX
INVOKE FormatMessage, FORMAT_MESSAGE_FROM_SYSTEM OR FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, EDX, 0, ADDR buffer, SIZEOF buffer, NULL
INVOKE MessageBox, 0, ADDR buffer, NULL, MB_OK
POP EAX
RET
ShowLastError ENDP
Neat advice! Thank you for your patience!
I'll try it out and let you all know!
This line shouldn't compile?
mov DWORD PTR [RawInputDevices.hwndTarget], RAXhwndTarget is a QWORD
What does RegisterRawInputDevices return?
You're using fastcall, are you setting up shadow space correctly?
Quote from: sinsi on March 25, 2025, 02:20:09 PMWhat does RegisterRawInputDevices return?
Quote from: ccdcmc421 on March 25, 2025, 12:32:50 PMRAX = 00000000000003E6
Edit:
Whoops, That was what GetLastError returned. :undecided: sorry 'bout that. I will leave now. :eusa_boohoo:
Let's hope we can just leave all this "raw input" crap behind us ...
Using Raw Input (https://learn.microsoft.com/en-us/windows/win32/inputdev/using-raw-input)
RAWINPUTDEVICE structure (https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-rawinputdevice)
So RAWINPUTDEVICE structs could have static values in it, except if hwndTarget is needed.
Small test:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);
TCHAR *szAppName = TEXT("WinFrame");
TCHAR *szFrameClass = TEXT("cWinFrame");
HWND hFrame;
HANDLE hInst;
RAWINPUTDEVICE rid[2] = {1,0x06,RIDEV_NOLEGACY,0};
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
WNDCLASSEX wcx;
MSG msg;
wcx.cbSize = sizeof(WNDCLASSEX);
wcx.style = CS_HREDRAW | CS_VREDRAW;
wcx.lpfnWndProc = WndProc;
wcx.cbClsExtra = 0;
wcx.cbWndExtra = 0;
wcx.hInstance = hInstance;
wcx.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wcx.hCursor = LoadCursor(NULL, IDC_ARROW);
wcx.hbrBackground= (HBRUSH)COLOR_APPWORKSPACE+1;
wcx.lpszMenuName = NULL;
wcx.lpszClassName= szFrameClass;
wcx.hIconSm = 0;
if (!RegisterClassEx(&wcx))
return 0;
hInst = hInstance;
hFrame = CreateWindowEx(0, szFrameClass, szAppName,
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL, hInst, NULL);
if(!hFrame) return 0;
ShowWindow(hFrame, nCmdShow);
//UpdateWindow(hFrame);
rid[0].hwndTarget = hFrame; // test target window
if (RegisterRawInputDevices(rid, 1, sizeof(rid[0])) == FALSE) {
MessageBox(hFrame, TEXT("failled"), TEXT("error"), MB_OK);
}
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg) {
case WM_INPUT:
OutputDebugString(TEXT("WM_INPUT"));
return (0);
case WM_DESTROY:
PostQuitMessage(0);
return(0);
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
And that earlier error:
Error name:
ERROR_NOACCESS
Error value:
0x000003E6 (998)
Description:
Invalid access to memory location.
Quote from: TimoVJL on March 25, 2025, 07:34:09 PMUsing Raw Input (https://learn.microsoft.com/en-us/windows/win32/inputdev/using-raw-input)
@Timo: let's not even go there, OK?
So OP: how goes your experiment with the old-school keyboard messages?
Despite the recent disruption we're still interested in that.
Hi all,
I'm so sorry!
So, I actually came to the conclusion that I might be a bit slow. Should have used WM_TIMER messages. WM_CHAR Didn't really work out so well as it had the same effect as WM_KEYDOWN. However, WM_TIMER worked perfectly for my use case in handling crisp, clean and responsive inputs.
I appreciate the assistance and the minds of everyone who tried to help :)
sucks that rawinput messages don't work, but for the use, case this is working perfectly. Maybe one day I'll have to revisit the Rawinputdevices thing. But that wont be till the future and when I'm more experienced.
Well that's not a very satisfying conclusion. :sad: Your post above mine sounds like you are finished with this part of the code.
No code to share with us, or even just the executable?
It really would have been nice to see your current progress. :smiley: