Technical solution to eliminate desync in single-player sessions

"

HellGauss wrote:

As SkyCore point out, the only issue that requires some brainstorm is security.

"

HellGauss wrote:

"

deteego wrote:

@HellGauss, if you read the article posted earlier, its not as simple as using precomputed constants for Sin/Cos, or using fixed point math. Even if you solely use fixed point math, you can get rounding errors due to how the variables are stored in memory

There is also the obvious point of performance

I do not know how to answer.... maybe you are assuming that fixed-point math = rounded floating point. no!

In a fixed point implementation, a number is represented (say) by two 32 bit *integer*. The first one is the integer part, and the second one the fractional part (base 2). You can perform basic arithmetic operation using only the ALU and integer operations, and stay away from the FPU. Those operations are very deterministic and very standard for each processor/SO. Rounding is not an issue as long as you choose your standard way to perform approximations.

"

Skogenik wrote:

To my mind, I think the biggest problem can be read in-between the lines of one of Rhys' posts; specifically, if you didn't do things locally on the Client, then it would take 2-3 seconds for the mob to drop stuff, your orbs to apply, etc etc.

The way I read that is to say that we're basically overloading the servers as a 2-3 tick, is incredibly slow for an MMO.
How to fix? Keep buying those microtransactions and help GGG upgrade their stuff :)

"

deteego wrote:

I understand what Fixed Point arithmetic is, I don't think you understand what was said in that article

"

LogoOnPoE wrote:

"

deteego wrote:

I understand what Fixed Point arithmetic is, I don't think you understand what was said in that article

Actually unless I missed it, that article says nothing about fixed point determinism, can you quote where it says that fixed point operations are non-deterministic?

"

Wikipedia wrote:

Precision loss and overflow

Because fixed point operations can produce results that have more bits than the operands, there is possibility for information loss. For instance, the result of fixed point multiplication could potentially have as many bits as the sum of the number of bits in the two operands. In order to fit the result into the same number of bits as the operands, the answer must be rounded or truncated. If this is the case, the choice of which bits to keep is very important. When multiplying two fixed point numbers with the same format, for instance with I integer bits, and Q fractional bits, the answer could have up to 2I integer bits, and 2Q fractional bits.

For simplicity, many fixed-point multiply procedures use the same result format as the operands. This has the effect of keeping the middle bits; the I-number of least significant integer bits, and the Q-number of most significant fractional bits. Fractional bits lost below this value represent a precision loss which is common in fractional multiplication. If any integer bits are lost, however, the value will be radically inaccurate. Some model-based fixed-point packages[5] allow you to specify a result format different from the input formats. This allows you to maximize precision and avoid overflow.

Some operations, like divide, often have built-in result limiting so that any positive overflow results in the largest possible number that can be represented by the current format. Likewise, negative overflow results in the largest negative number represented by the current format. This built in limiting is often referred to as saturation.

Some processors support a hardware overflow flag that can generate an exception on the occurrence of an overflow, but it is usually too late to salvage the proper result at this point.

Modern development cycles include a prototyping phase which examines the potential precision loss and overflow of designs using fixed point calculations before proceeding to physical prototyping.

"

SkyCore wrote:

If i read Rhys' mind correctly, that has nothing to do with server overload. It deals with the fact that the client only pulses information to be processed every second. That information travels through tcp to the server. And then the server validates it. Then sends back the loot through tcp. Finally to be received by the client. All this takes time. Networks are unreliable resulting in resending the information causing yet more delay.
In the end you end up with a couple seconds of delay often.

"

Skogenik wrote:

"

LogoOnPoE wrote:

"

deteego wrote:

I understand what Fixed Point arithmetic is, I don't think you understand what was said in that article

Actually unless I missed it, that article says nothing about fixed point determinism, can you quote where it says that fixed point operations are non-deterministic?

I think this sums it up pretty well:

"

Wikipedia wrote:

Precision loss and overflow

Because fixed point operations can produce results that have more bits than the operands, there is possibility for information loss. For instance, the result of fixed point multiplication could potentially have as many bits as the sum of the number of bits in the two operands. In order to fit the result into the same number of bits as the operands, the answer must be rounded or truncated. If this is the case, the choice of which bits to keep is very important. When multiplying two fixed point numbers with the same format, for instance with I integer bits, and Q fractional bits, the answer could have up to 2I integer bits, and 2Q fractional bits.

For simplicity, many fixed-point multiply procedures use the same result format as the operands. This has the effect of keeping the middle bits; the I-number of least significant integer bits, and the Q-number of most significant fractional bits. Fractional bits lost below this value represent a precision loss which is common in fractional multiplication. If any integer bits are lost, however, the value will be radically inaccurate. Some model-based fixed-point packages[5] allow you to specify a result format different from the input formats. This allows you to maximize precision and avoid overflow.

Some operations, like divide, often have built-in result limiting so that any positive overflow results in the largest possible number that can be represented by the current format. Likewise, negative overflow results in the largest negative number represented by the current format. This built in limiting is often referred to as saturation.

Some processors support a hardware overflow flag that can generate an exception on the occurrence of an overflow, but it is usually too late to salvage the proper result at this point.

Modern development cycles include a prototyping phase which examines the potential precision loss and overflow of designs using fixed point calculations before proceeding to physical prototyping.

Take into account different architectures, different operating systems and potential thunking issues.

"

Skogenik wrote:

I guess, we'd have to wait to hear what Rhys has to say; I still think that 2-3k-ms is abnormal though; but I will admit that I don't know how GGG are managing their ticks, so it might actually be optimal.

"

I have to admit it's been a while since my computer architecture and translation methods classes, but as I understand the loss of precision itself does not imply non deterministic behavior.