GetAsyncKeyState的返回值似乎与描述不符
我调查了 GetAsyncKeyState 在代码示例中看到如何通过 WASD 键使虚构角色在屏幕上移动后。
我在其 MSDN 页面上读到了这一点:
返回值
类型:简短
如果函数成功,返回值指定key是否 自上次调用 GetAsyncKeyState 后被按下,以及是否 键当前处于向上或向下状态。
如果设置了最高有效位,则 键被按下,如果设置了最低有效位,则键被按下 在上次调用 GetAsyncKeyState 后按下。
我无法理解返回值的结构:
它表示类型是 short
,因此我想通过它您可以表示数字零,二进制为 0000000000000000
,或十六进制为 0x0000
(因为据我所知,一个十六进制数字代表四个二进制数字)。
描述说按下按键时应设置最高有效位。这让我认为,如果设置了该位,数字将如下所示:
1000000000000000
为了在我的程序中更好地利用它,我通过将其转换为十六进制来缩短它,结果是:
0x8000
因为 8
十六进制应对应于二进制的 1000
。
当我看到上述机制在我的程序中不起作用(执行 GetAsyncKeyState(chr) == 0x8000 总是会产生 false,无论是否按下该键)我又看了一眼原始示例我首先看到了使用的函数。在那里,返回值与数字 -32767
进行比较,当使用 Windows 计算器将其快速转换为十六进制时,结果为值 0xFFFFFFFFFFFF8001
。现在,不要介意最后一个十六进制数字 (1),因为这是用于检查最低有效位是否也处于活动状态的位,但在我的情况下我不希望这样。
这里我无法理解的事情如下:
- 为什么,如果一个十六进制数字代表四个二进制数字,并且函数的输出值是一个短整型(两个字节),那么这里的数字是由十六个十六进制数字表示的?这不是八个字节吗?
- 返回值的描述表明,如果按下按键,最高有效位将设置为 1,这让我相信该数字将类似于
1000000000000000
,而不是0000000000001000
。我在这里缺少什么?
I investigated GetAsyncKeyState after seeing it in a code example on how to make a fictional character move on the screen through the WASD keys.
I read this on its MSDN page:
Return value
Type: SHORT
If the function succeeds, the return value specifies whether the key
was pressed since the last call to GetAsyncKeyState, and whether the
key is currently up or down.If the most significant bit is set, the
key is down, and if the least significant bit is set, the key was
pressed after the previous call to GetAsyncKeyState.
I'm having trouble understanding the structure of the return value:
It says the type is short
, so through it I suppose you could represent the number zero, in binary, as 0000000000000000
, or in hex as 0x0000
(since as far as I know one hex digit represents four binary digits).
The description says that the most significant bit should be set when the key is pressed. That makes me think that, if said bit was set, the number would appear like this:
1000000000000000
To make better use of it in my program, I shortened it by translating it to hex, resulting into:
0x8000
Because 8
in hex should correspond to 1000
in binary.
When I saw that said mechanism was not working in my program (doing GetAsyncKeyState(chr) == 0x8000
would always yield false, no matter if the key was pressed or not) I took one more look to the original example I saw the function employed in first. There, the return value was being compared with the number -32767
, which, when quickly translated to hex using the Windows calculator, results into the value 0xFFFFFFFFFFFF8001
. Now, don't mind the last hex digit (1) because that's the bit used to check whether the least significant bit is also active, but I don't want that in my case.
The things that I can't understand here are the following:
- Why, if one hex digit represents four binary digits, and the output value of the function is a short (two bytes), here the number is represented by sixteen hex digits? Aren't those eight bytes?
- The description of the return value said that the most significant bit would be set to 1 if the key was being pressed, and that led me to believe that the number would look like
1000000000000000
, not0000000000001000
. What am I missing here?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是错误的检查。用途:
查看最高有效位是否已设置。
值
0xFFFFFFFFFFFF8001
与 GetAsyncKeyState 的实际返回值不对应。 Windows 计算器不知道从 GetAsyncKeyState 返回的值的大小,因此它假设您正在使用 64 位数字。您可以在其设置中覆盖它。This is incorrect check. Use:
to see if the most-significant bit is set.
The value
0xFFFFFFFFFFFF8001
doesn't correspond to the actual returned value from GetAsyncKeyState. Windows calculator doesn't know the size of the value returned from GetAsyncKeyState, so it assumes you're working with 64-bit number. You can override it in its settings.1 - 返回值为
SHORT
,即 16 位 = 2 个字节。2 - 最高有效位是第 15 位,因为如果将其转换为 32 位
INT
,则该值是有符号的,16 位1000 0000
值将变为1111 1111 1000 0000
(在 64 位世界中,转换为1000 0000
->1111 1111 1111 1111 - 1111 1111 1000 0000
)。如果您只想测试有符号整数值的最高有效位,只需将其与零进行比较:1 - returned value is
SHORT
, which is 16 bits = 2 bytes.2 - most significant bit is the 15th, as the value is signed if you cast it to 32-bit
INT
, 16-bit1000 0000
value would become1111 1111 1000 0000
(in 64-bit world the conversion would be1000 0000
->1111 1111 1111 1111 - 1111 1111 1000 0000
). If you want to just test the most significant bit of the signed integer value, just compare it to zero: