Skip to main content
gamedev.net
🔒 Locked

Mouse Packets

Started by DragonWolf Jan 14, 2005 at 11:54 AM 2 replies 2.1k views
Original Post
DragonWolf
DragonWolf
Hi all, Are there any articles out there or do you have any tips on methods of reducing the amount of network traffic produced by orientation of the player avatar when it is controlled by a mouse? At the moment the data for the orientation is sent when, the mouse is moving slowly (not changing much) (less frequently) the mouse moves alot (more frequently) When the user (clicks) send a update on the mouse direction I'm wondering if when the mouse accelerates, decelerates and changes direction might be more effective and less demanding on bandwidth. Regards
hplus0603
hplus0603
If you send velocity deltas, then a single lost packet is more likely to cause problems.

What kind of game is this? If it's an FPS-like game, or a very kinetic online RPG (like City of Heroes), then you probably need to send some measure of mouse movement in each UI packet, say 20 times a second. You can get away with sending fewer bits by sending only a delta from the previously acknowledged packet and using variable-length coding, or by quantizing your orientation.

If you want to send absolute orientations still, one simple way to quantize is to throw away one of the four values in a quaternion, and then send the other values as 16-bit integers (where -32768 to 32767 map to -1 to .999969482421875). On the other end, you stuff the values back in, and calculate the missing value using the fact that the quaternion is unit length. Another is to convert to Euler angles, and store them as 10 bit values (each tick is 360/1024 degrees) and smosh them together into a 32-bit integer. On the other end, pull out the values, and convert back.

What, specifically, would make sense in your situation mostly depends on what your game type is, and what kind of quality/precision/performance requirements you have.
enum Bool { True, False, FileNotFound };
hannibal84
hannibal84
Another thing you would have to think about with the acceleration/deceleration idea is how people move the mouse. I don't know about you, but I've never seen someone who could keep mouse movement perfectly constant (as far as the sampling by the system is concerned). This would imply that you would receive just as many mouse packets concerning movement. True, you could get around it by checking for a certain amount of accel/decel, but that just changes the scale of the issue; it doesn't really solve it.
DragonWolf
DragonWolf
I'm referring specifically to a FPS game, though I'm interested in any other information as well.

I am already using delta compression on the data, and it only updates 5 times a second when the orientation (mouse data) is not important. But when the user performs an action (such as shooting a gun) the data is sent more frequently (10-20 times a second depending on bandwidth) until they finish the action.

As I see it this is probably the best method. I was just curious if there are any other techniques out there.

As for calculating the change in mouse movements I was thinking of using Bezier Curves or something though this would take up too much processing time.

Quote:
Original post by hplus0603
If you want to send absolute orientations still, one simple way to quantize is to throw away one of the four values in a quaternion, and then send the other values as 16-bit integers (where -32768 to 32767 map to -1 to .999969482421875). On the other end, you stuff the values back in, and calculate the missing value using the fact that the quaternion is unit length. Another is to convert to Euler angles, and store them as 10 bit values (each tick is 360/1024 degrees) and smosh them together into a 32-bit integer. On the other end, pull out the values, and convert back.


Could you not also delta compress this? Such as the change in the 32-bit integer?

[Edited by - DragonWolf on January 20, 2005 8:05:23 AM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.