[vx]鼠标系统 1楼无DLLl,2楼依赖DLL(2010-09-23更新)

54cn

支持，新鼠标看起来不错。

==================分割线==================
坚决不做伸手党。

紫苏

回复 沉影不器 的帖子
但作者给 press? 写的注释里确实说的是 down? 的功能 ><

#   Mouse.press?
#   This returns a true/false value  when you test  whether a button is pressed
#   and kept depressed.  The values you pass are 1 (for the left mouse button),
#   2 (for the right mouse button), or 3 (for the middle).

我觉着吧就是她/他没仔细看说明文档或者一时疏忽了，如果想做切换的功能可能把方法命名为 toggled? 更合适

zh 判断的 > 1，原意应该是想只判断 down?，不判断 toggled?，按常理来想这么做也确实可行，因为 GetKeyState 返回的是 16 位整数，而 Ruby 是 31 位整数，无论 GetKeyState 的返回值怎么变，直接拷贝数据到 31 位整数里的话，应该都不会影响 31 位整数的符号位，所以一旦 16 位整数的最高位被设为了 1，整个整数必然 > 1；但实际测试了下，GetKeyState 返回的数有时是负的，有时不是，是负的时候刚好是 16 位整数最高位为 1 时所表示的那个负数，说明这里有符号扩展，影响了 31 位整数的符号位，也应该是柳柳那个问题的来源。最不会有问题的办法自然还是与上 0x8000 再判断 != 0 了

在 Ruby 里 GetMessage 确实不好，因为 Graphics.update 也在同时处理消息，游戏一帧之间 Ruby 脚本可能只调用一次 GetMessage（一帧之间多次调用 GetMessage 的话，不知道什么时候该停止），而 Graphics.update 却不止，两帧之间的程序空闲时间足够调用成百上千次 GetMessage 了，当队列比较长时，可能大部分消息会被 Graphics.update 抢走

紫苏

回复 沉影不器 的帖子

>_< 说错了，我的意思是 Graphics.update 一帧一次，但期间这厮可能已经处理了成百上千个消息了
现在基本上可以确定 Graphics.update 是处理 RM 窗口消息的过程，由于 RM 需要锁帧，所以 Graphics.update 每帧会至多占用主线程 (1000/fps) 毫秒的 CPU 时间，特别是在配置高的机器上，假设游戏是 60 fps，最好的情况下游戏高层逻辑只需要 1 毫秒来完成，那 Graphics.update 每帧都有  (1000-1)/60，将近 17 毫秒的时间来处理各种消息
所以理论上来说 fps 越高，Graphics.update 得到的时间就越少，Ruby 抢占消息的赢面就更大……但这样做同时也增加了 CPU 负荷……|||

沉影闲下来了可以试试用夏娜的思路做一个，不必用到系统钩子，仅仅替换窗口过程~