[gernb]

Am I missing how that would work? That's an exponential increase in bandwidth needed to send all the mouse positions. 1 position per 100ms per player vs 10-30 per 100 ms per player. Those positions all have to be propagated to other players. so in the first case, 10 players = 10 positions per 100ms. In the 2nd case is 100-300 positions per 100ms.

[Sohcahtoa82]

Yeah but stop and think about how little bandwidth it still is.

X and Y can easily be 2 bytes each, 4 bytes total. 100 samples per second is a mere 400 bytes per second. You could do it from a dialup modem from the early 90s!

[Aeolun]

You could, but I think for most web applications the authors wouldn’t think about binary encoding. So you’d end up with something like:

  {“x”:50,”y”:56}

Encoded as a UTF8 string, which is 15 bytes, x100 is 1.5kb/second/participant.

Ok, I guess that’s still not that much.

[Etherlord87]

So you implement spline logic rather than a byte stream? Doesn't make sense to me.

[ec109685]

That’ll get compressed a bit too.

[Etherlord87]

Well spotted, and in reality it would more likely be 4096x4096 plane, encoded as 12 bits + 12 bits = 3 bytes. And probably 30 FPS giving 90 B/s. So the only problem is how often you want to send those packets, but the bandwidth of the cursor data becomes completely irrelevant.

[Etherlord87]

60 FPS = 60 F/s = 6 F/100 ms - so where did you get 10-30? That would mean 90-270 FPS, you don't need that much for a cursor.