0
\$\begingroup\$

Lets say we send a snapshot from the server to the clients about world details, containing object positions, velocities etc, every second. We should send only delta-data based on the previous snapshot that was sent.

For example, if the player moved from (x:50, y:0) to (x:100, y:0), then the snapshot will only contain (move_x:50: move_y:0), and the clients will add the previous position and move_x. We should sending delta values, as it is less data to send.

How do I achieve this in Javascript?

My objects already have data stored in Float32 (by TypedArray) and there is no Float16 data type in JavaScript.

For example:

delta = currentPos - prevPos 20 = 100 - 80

okey, now I have 20 instead of 80, but this isn't less data to send.. still both will be send as Float32.

data.writeFloat32(delta); //for simplesness

there is no Float16 and I am afraid that even if JS will has Float16 TypedArrays, then it still would be not enough, because for example 20.3454356 from Float32 to Float16 will lose precision to lets say sth like 20.34, or I'm wrong?

How to send delta data in JS and gain the benefits of this technique in JS?

\$\endgroup\$
3
  • \$\begingroup\$ Please note that I have removed the component requesting additional explanation of the floating precision of float32. You can ask multiple questions as multiple questions, or in direct relation to the core question. I see no relation when you specifically say you dont have access to float16, regardless of the additional understanding. \$\endgroup\$ Commented Jan 16, 2017 at 3:00
  • \$\begingroup\$ It also occurs to me that, as its own question, you should ask about floating precision at StackOverflow. \$\endgroup\$ Commented Jan 16, 2017 at 3:06
  • \$\begingroup\$ What exactly are you having trouble with? This question seems kind of broad at the moment. \$\endgroup\$ Commented Jan 16, 2017 at 10:55

1 Answer 1

Reset to default
3
\$\begingroup\$

I think you misunderstood what people mean when they say that you should only be sending deltas in your netcode.

The message is about sending data when it changed. It means that when the player isn't moving, you don't keep sending the same position every frame. You only send position updates when the player is moving. It's not saying anything about whether you send absolute position updates (the new coordinates) or relative position updates (the difference between new and old positions).

Relative movement coordinates usually require a far smaller number-range than absolute coordinates. That means truncating the data-type you use for relative position updates can save a few bytes of network traffic. But only when you use integer-coordinates!

You have recognized correctly that it is a much worse idea with floating-point values. When you use 16bit instead of 32bit or 64bit floats, you aren't just losing range, you are mostly losing precision!

But even when you are dealing with floating point values with uniform precision, keep in mind that floating-point arithmetics are always a bit fuzzy. When you only send differences and never absolute positions, these imprecisions are going to accumulate. This effect will get worse with less precise floating-point values, but they even occur with high-precision floats. So you might still want to send an absolute update from time to time to re-synchronize.

If you still want to go down this route, I would recommend you to encode your position differences in Int16 by multiplying them with your desired precision factor while encoding and then dividing them again by the same value when decoding. That way you retain complete control over the tradeoff between range and precision.

\$\endgroup\$
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.