Descriptive Problem Summary:
Mouse procs are being called much less frequently when keyboard input is happening at the same time. The current behavior in v489 is significantly different from the v476 behavior (that version supposedly fixed this issue).
Numbered Steps to Reproduce Problem:
1. Download this library.
2. Run the demo that comes with it.
3. Move the mouse while not pressing any keys. Observe how smoothly the crosshairs move.
4. Hold down an arrow key and move the mouse at the same time. Observe how much less frequently the crosshairs are positioned.
The arrow key you're holding doesn't even have to cause you to move. If you stand in the bottom-left corner of the map and hold the left arrow key, you'll still see this problem. It's like the client only wants to send one message to the server and the mouse events are fighting the keyboard events to be that message (and the keyboard events usually win).
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
The crosshairs move smoothly as the mouse position updates regularly.
Actual Results:
The mouse position updates infrequently so the crosshairs movement is very choppy.
Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?
When does the problem NOT occur?
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
This problem sounded familiar and I came across this bug report. Unfortunately it looks like the issue was resolved, so I'm not sure if I'm seeing a different problem or if it wasn't entirely resolved.
I installed v476 and tried the demo again. The behavior is significantly different. The mouse position updates more smoothly, but you can still see that the updates are slower while a key is held. It looks like the bug came back. Can a client not submit a keyboard and mouse command to the server on the same tick (even with the fix to the other bug)? This would seem very odd.
Workarounds:
ID:117700
 Aug 27 2011, 1:23 am
|
|||||||||||||
Resolved
| |||||||||||||
|
Aug 27 2011, 1:41 am
|
|
Bravo1
 |
I am also experience this bug.
|
I've been digging nto our code and so far I've managed to narrow down the behavior change to version 478. Specifically I believe it's the fix to issue 2244 causing this change. In 476 and 477, you can see that the keyboard movement is actually blocked by the mouse commands because of the way they get prioritized, which is obviously not good. I'm trying to find out if there's a way to improve on the mouse queueing significantly.
| |
What's the problem? I understand that you need a queue so events get executed in order, but what's the limitation on processing the queue? Can you not have a mouse and keyboard event in the same tick? Can you not have two mouse events in the same tick? Is there a reason for a limit to exist or is that just how things are handled?
| |
I couldn't think of any reason to keep mouse events non-instant so I changed that to fix this issue.
| |
Ok. I had noticed in v476 that mouse and keyboard events slowed down when both were happening, like they'd alternate ticks. Is that fixed now (assuming it was intentional in the first place)?
| |
Yeah, the mouse events will happen alongside keyboard events on the same tick.
| |