Player Position Interpolation Progress

[Bak]

The next item on the todo list is "3. Fix timer sync and client position prediction"

 

This isn't completely trivial and has been bugging me and holding up progress for a while now. I've finally settled on an approach I think will work, and have a made a demonstration Java program. Here, you can generate two points corresponding to two positions and velocities that you want to interpolate between (for example, the current "predicted" player position and an updated position that you infer from a new position packet). You can then see the quality of the interpolation between the two points. Two methods are available, linear and cubic Bézier. I've attached the program (with source), and a screenshot.

 

 

Expect to see it in Discretion soon.

DiscInterpolationTests.zip

[Dr Brain]

What does SubSpace use?

[Bak]

I'm not sure. Do you know someone good at assembly?

[Samapico]

Pretty sure Continuum just uses a simple linear interpolation... When someone lags out (or goes through a jump gate in Hyperspace), the ship just continues to float at a constant speed, whether or not you were thrusting in a direction.

 

And emm... This is extrapolation, btw, not interpolation

 

The tricky part, in my opinion, is to consider the future ship bounces in the extrapolation, so you don't predict someone will go through a wall.

[Bak]

so there's two issues, one is interpolation between packets, and one is extrapolation after you receive a packet. You're right that the extrapolation you see after a lagout is linear, but the interpolation between ships is definitely non-linear (It was the first thing I tried in Discretion and was very wrong).

 

A little experiment you can do is this:

 

Fly next to a player in Continuum that's drifting through space. Match his speed. If you look at him he'll be drifting faster and slower as Continuum adjusts his velocity for you.

[Dr Brain]

So you're saying SS/Cont doesn't display the true position of the player the moment it comes in? Interesting.

[Samapico]

Yeah... so... when you receive a packet, it's not the player's actual position? You're saying it waits before placing that player there?

 

What would be the point of this? Smoother display? Working around sync issues? Not quite sure to understand...

 

I assumed:

My Time     -------------------------->
His pos pkts  1     2     3        4

His pos       1.....2.....3........4
on my screen

With ..... being extrapolation from the last packet. I'm guessing it's much more complex than this, then?

[Bak]

yes it definately won't display him right away, as it would be very jumpy.

 

get the latest version off the svn and look at how smoothly fake player moves (he'll mirror you in a warbird)... that's what it looks like when it places the player right at the position where it receives the packet (no interpolation).

[Samapico]

But doesn't delaying it make lag worse? If only interpolation is used (no extrapolation), it would effectively double the lag...

A combination of interpolation and extrapolation could be used like this:

When a position packet is received, the client smoothly makes that ship fly to the target position in X ticks, starting from the last extrapolated position (unless the extrapolation is way off I guess)

After reaching the target position, player's position is extrapolated linearly until a new packet comes in

 

This still adds lag, but it would be a fixed amount, instead of doubling it. Or X could be a function of the player's ping or something...

 

 

get the latest version off the svn and look at how smoothly fake player moves (he'll mirror you in a warbird)... that's what it looks like when it places the player right at the position where it receives the packet (no interpolation).

Can't do that right now, but does it use extrapolation after each packet?

[Bak]

yes.

 

the extrapolation / interpolation approach is what it does (I think). It doesn't delay the ship position an entire packet interval before interpolating

[JoWie]

Since every position packet has a c2slatency field, this could be a factor in the (inter|extra)polation as well.

 

You could set up a simple experiment in ASSS, where you have 3 players and 2 of them see very different c2slatency for the third player (game.h: A_PPK EditIndividualPPK). I actually want to test this myself but I do not have the time this week.

[Bak]

hmm perhaps.

[Dr Brain]

It'd be trivially easy to setup a module to broadcast predetermined packets for an experiment like that. If run locally, you could eliminate the lag component while still being able to alter the c2slatency on the outgoing position packets.

[Cheese]

when youre floating next to them, and their speed isnt constant, most likely whats happening is that the client interpolates position, and then recieves the next position, and plots it, causing a small jump

 

this is most noticable at high speeds close to a high gravity wormhole

 

 

 

 

 

additionally under high lag, all players drift in a straight line until they bounce off a wall with no speed loss

 

 

 

 

 

 

also, ive recently been planning to make a fake pilot module, so that might help with something, maybe

[Samapico]

Just a thought: Do we really want/need to replicate Continuum's inter/extrapolation exactly? I think reverse-engineering this would be incredibly complex, unless you can crack the assembly code. By setting up tests like Jowie suggested, I think the best you can actually achieve is guessing which variables are involved. But to determine how they interact would be a major pain in the butt, in my opinion.

It might be best to just develop something based on algorithms that exist (surely there are some open-source games we could get inspiration from?) and tweak it until it looks good (which doesn't necessarily mean that it looks like Continuum).

[Dr Brain]

If discretion wants to interoperate with Continuum in the same zone, then you need to get players to match up exactly for collision calculations.

 

I doubt the SS/Continuum algorithm is complicated. It's probably the simplest thing they could get to work.

[Kilo]

If it's anything like how powerball friction works though, it's probably not the simplest thing. I don't remember who figured out (reverse engineered?) that one, but their help would be nice. :/

[Cheese]

Just a thought: Do we really want/need to replicate Continuum's inter/extrapolation exactly?

 

if we are making a new client, wouldnt this be the time to improve everything, and add new features?

having discretion-only arenas would be worth it if new stuff got added

[L.C.]

If discretion wants to interoperate with Continuum in the same zone, then you need to get players to match up exactly for collision calculations.

+1

 

I think I have said something like this before at least once. If you don't do this, then Subgame2 will go haywire on you (and Continuum will not have a smooth gameplay experience).

 

(EDIT: Of course that is only if coexistence is planned. Otherwise you can just build a client with its own algorithms for everything.)

Edited August 14, 2010 by L.C.

[Samapico]

Even if both clients coexist, developping an algorithm that 'appears similar to' Continuum's, without being an exact replica, would be enough imo. The only case where you could see a slight difference would be with a very laggy player, anyway.

 

And as soon as Discretion has at least all the features of Continuum, I don't see why we would need them to coexist. Just like we transitionned from Continuum 0.38/39 to 0.40, we could have a transition to Discretion. Compatibility with subgame, however, is a must (unless there's a major change towards ASSS in the larger zones in the next months)

[L.C.]

Well the reason I said what I said was because of Subgame2+SaidClient's heavy reliance on timings. If something doesn't correspond, the reaction won't be so kind. Hence many parts of the client are client-side (and this makes things tighter as far as keeping gameplay perfectly synchronized). Client and server code know each other, so they don't have to compensate for 'unknown' variables and values, or for algorithm mismatches.

 

EDIT: Nevermind, sorry. I don't belong in this thread.

Edited August 14, 2010 by L.C.

[JoWie]

The algorithm would not have changed a lot, if at all, between continuum versions. Maybe even between the subspace and continuum client. The old versions of continuum were easy to unpack, maybe one could start there.

[Dr Brain]

Compatibility with subgame, however, is a must (unless there's a major change towards ASSS in the larger zones in the next months)

 

Breaking Continuum's encryption and then publishing the results (source or binary) would outright kill the subgame zones.

[Samapico]

Hmmm, right, nevermind. Unless making it go through Oracle, like Starlight... But only when it's a subgame server.

Would this work? I must admit I'm a bit clueless about this stuff.

[L.C.]

Yoohoo guys! The interpolation algorithm was already released and open sourced by Snrrrub.

 

Starting with http://daccel.cvs.sourceforge.net/viewvc/daccel/SubSpace/AppFramework/SSPlayer.cpp?revision=1.9&view=markup (line 287, also file is about 8 years old), and then the following resources:

 

* http://sharvil.nanavati.net/projects/subspace/encryption.html (See 'Oracle' section)

* http://sharvil.nanavati.net/projects/subspace/unpex.html (Unpacking and packing)