Changes to protocol 666

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Changes to protocol 666

Post by mankrip »

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".
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Changes to protocol 666

Post by Baker »

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.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Changes to protocol 666

Post by mankrip »

Hmm, calculador accuracy has tricked me.

But division by 250 still works perfectly for multiples of 0.1, which is my main point.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Changes to protocol 666

Post by mankrip »

Wait, I got what you're saying.

My low-level computing skills are more rusty than I though.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Changes to protocol 666

Post by Baker »

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 ...

Image
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Changes to protocol 666

Post by Spike »

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).
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Changes to protocol 666

Post by Baker »

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.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
metlslime
Posts: 316
Joined: Tue Feb 05, 2008 11:03 pm

Re: Changes to protocol 666

Post by metlslime »

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 :)
Post Reply