Mouse movement events get sent constantly while the mouse is moving. Constantly is a lie. There is probably some sample rate going on behind the scenes inside windows and/or the mouse itself. A quick googling reveals numbers in the 100 to 200 samples per second range.
Key up/down events are designed for typing. That's where the repate rate comes in. I don't know how fast a keyboard could be polled, but if the OS sent out a keydown event at maximum poll frequency notepad would fill with letters really fast.
So the difference is really just because of how the different pieces of hardware are used. Keyboard is used for a typed character now and then, mouse is used for a smoothly moving cursor.
[.net] Keyboard/mouse event handlers - must return quickly?
Gage64,
The MouseMove event is usually used for panning and rotating your view, you know, pitch, yaw and such. The reason that the MouseMove event works so well is that it is fired every time the mouse is moved from one screen pixel to the next. Not until such time though, so there's no unnecessary firing until the mouse is actually moved. In other words, if you keep the mouse still, it does not fire. It's smooth because it is fired on each frame that actually counts, or in other words, each frame when the mouse is actually moved and the user would see the view change.
The scan array was just an optimization suggestion. At the end of the programming phase I usually perform all of my optimization checking, to see if there's anyway that I could possible speed things up. The speed up in your code would probably not be noticable for this instance. But what I meant was that if this sort of thing was repeated too much in the render loop you might see performance degrade some.
HTH,
Devin
The MouseMove event is usually used for panning and rotating your view, you know, pitch, yaw and such. The reason that the MouseMove event works so well is that it is fired every time the mouse is moved from one screen pixel to the next. Not until such time though, so there's no unnecessary firing until the mouse is actually moved. In other words, if you keep the mouse still, it does not fire. It's smooth because it is fired on each frame that actually counts, or in other words, each frame when the mouse is actually moved and the user would see the view change.
The scan array was just an optimization suggestion. At the end of the programming phase I usually perform all of my optimization checking, to see if there's anyway that I could possible speed things up. The speed up in your code would probably not be noticable for this instance. But what I meant was that if this sort of thing was repeated too much in the render loop you might see performance degrade some.
HTH,
Devin
I would suggest using polling for the mouse instead of events, it should cut down on some of the overhead a bit. For XNA which can be locked at 60 FPS, this is more than enough for smooth mouse tracking, not to mention the mouse cursor if being rendered wont be rendered faster than 60 fps anyways. Plug in some math to smooth the movement and handle acceleration and it should work well enough for you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
