InsideQC Forums

I'm implementing its features in my own way, and I've figured out that multiplying the .nextthink delta for 250 instead of 255 gives perfect accuracy for U_LERPFINISH in most cases, because (1/250 == 0.004), while (1/255 = 0.0039215686275).

(0.1*250 == 25), which can be fully stored in a byte and losslessly decoded as (25/250 == 0.1), while (0.1*255 == 25.5), which gets cut to 25 and then lossy decoded as (25/255 == 0.0980392156863).

As .nextthink deltas most often occurs in multiples of 0.1, I suggest for engines who adopted the FitzQuake protocol to do this change.

The maximum possible difference between these is (250/255 == 0.9803921568627) and (255/250 == 1.02), which can probably be rounded without very noticeable artifacts.

I've tried to post this at func_, but got an "error 42".

1/250 maybe be 0.004 to humans. But to a machine it is not a round number, it is ...

0.0040000002

Do printf ("%f", 0.04) and look at the results.

in binary a number like 1/2 or 1/8 is "round". 250 is 5 x 5 x 5 x 2, notice the fives.

Hmm, calculador accuracy has tricked me.

But division by 250 still works perfectly for multiples of 0.1, which is my main point.

Wait, I got what you're saying.

My low-level computing skills are more rusty than I though.

Yeah, 0.1 isn't a precise number in binary either because 1/10 <--- ten isn't divisible by 2. similar to 1/3 being .333333333 in decimal ..

Floating point for non-integers math is always fun.

0.1: It looks like this in binary ...

if you're worried about precision, I'd recommend using 1250 or so instead of 255. then use the remaining unused values to appropriately flag it as 'more than 0.1 seconds'.
because frankly, noone's really going to want to interpolate things at lower framerates.

(disclaimer: fte clients ignore this field (parse+discard). fte stops interpolating when the rate drops below 5fps).

If you don't ignore the field ...
And interpret the value ...
And use a different interpretation that other clients/servers using 666 ...

I think demos recorded in Fitz 666 in a different engine would play back weird just for your specific engine.

Demos are pretty much data from the server.

Fitzquake servers never sends the interval if it is the default value of 0.1. So the most common case doesn't have a problem.

For all other intervals, the maximum error is 0.001953125 seconds. Is this ever noticeable to a player?

If it is noticeable, then you should choose a new protocol number. Otherwise the noticeably different behavior will cause bad behavior between implementations.

if it is not noticeable, probably shouldn't create an new implementation then