News. . .

[Vidiot_X]

Hi,

 

I have a working client and server that can handle ship/bullet collision. I am working out some small issues but close to getting it working. Below is a server (left) and client (right). I have a number indicating shield strength/power on the local ships as well as changing color. I'm also using the radar back screen to indicate shield status (just for testing). I'll be adding explosions and fixing a few issues.

 

So I'm close to posting a new version.

 

http://www.phoenix.subspace.co//s_c_ship_col.jpg

[Resol]

Where's the Like button?

 

Good work

[»Axe Demento]

that and excellent choice in computer backgrounds

 

 

...Axe

[Vidiot_X]

@Axe,

 

LOL. . . I forgot that was even there. And the six's are my kinda girls.

 

@All

 

The biggest issue I'm working on now is timing from the server to the client. The server is always behind the client as the clients have to send data like movement/location to the server then the server can process that data. So I'm working out a buffering system to record movement/location that lets the server run behind all the clients and keep timing. It's simple and complicated all at the same time.

[Resol]

I think continuum predicts where the movement packets are going to be, and compensate for lag.

[Vidiot_X]

@Resol

 

Well, I am using client side prediction and the buffer I'm talking about is used to record (on the server) the movement/weapons from the client. The client too would have a similar buffer. I can use this buffer for predictions on player/ship and bullets. Basically using a time or other index to sequence and then process the movement of a ship or bullet based on the buffered inputs from a client (in the case of a server) and make predictions about the player/bullet.

 

It is a method to help with latency and accuracy in predictions. You can read about it here for more information.

http://gafferongames.com/game-physics/networked-physics/

http://wiki.beyondunreal.com/Legacy:Lag_Compensation

[Vidiot_X]

And..

 

SubSpace I'm told does not use any client prediction at all but instead the server simply (old school) forwards close by client's data to the the current client receiving data. This makes scene to me as the original servers were plagued by cheating. Client prediction removes cheating (nearly) as a problem as even if a client is cheating it only fools it self. The server will verify it's data to make sure it fits a set of parameters. If it falls outside then the client is removed.

 

The other model I'm considering is a generalized networking model that may fit my design for Phoenix.

 

- Rich -

[JoWie]

Becareful with floats in such a model.

 

In a lot of cases, floating point math is not consistent across different systems. It might not even be consistent on your own system (like when your instructions are *suddenly* optimized by using CPU registers which may have more bits, ex 80bit float point in register, 64 bit floating point in ram).

 

This can usually be fixed by a keyword (like "strictfp" in java, and "volatile" partly helps in C), compiler flag, or by not using floats for the networking/physics stuff.

In Aphelion we use use integers (no temporary casts to float) for the networked server authoritative physics and floats for the graphics/view.

Edited September 12, 2012 by JoWie

[Dr Brain]

Yes, fixed point math is going to give you better (and faster) results for the physics computations, where you don't need a lot of dynamic range. In situations where fixed point is possible you end up with more precision than using an equivalently sized floating point number (e.g. int64_t vs. double, int32_t vs. float), since you're not wasting space storing the exponent.

[Vidiot_X]

Yup...

 

This is on my mind. I use floats for lots of things but as you both point out different platforms and hardware (or even twice on the same hardware) can and do give different results. I believe that I can use integers for all the networking stuff. The mapping, collision and other frameworks all use floating point math currently which I love because of the smooth movement of an object at low speeds to the display device. You can see what I mean in Continuum when your ship moves very slowly and sorta hops to the next position. The other issue is the vertlet style collision I am using really needs floating point math.

 

My thinking here was that any differences in the expression of a float would be small enough to be periodically corrected by the server which gets done anyway in a client side prediction model, but an integer based model would require less correction and thus less bandwidth per client. My other concern regarding floating point math is devices like cellphones or tablets which have limited hardware performance.

 

Much to consider here. . .

[Cheese]

why not just use long ints and divide by 10000000 or something?

 

 

and what about doubles

[Vidiot_X]

Perhaps truncating the floating point number to say 4 decimal places (for example) and convert to integer like this ( float * 10000 ) =Int and then converting it back to a float like this ( Int / 10000 )=Float. Or just using truncated floating point numbers.

 

Edit- In effect lowering the precision of the floating point number but getting improved accuracy.

[Vidiot_X]

I am thinking the differences in the floating point numbers between two platforms might be very small at 4 decimal places and I could handle it in my client side prediction framework. The precision at 4 decimal places should be good enough for the collision and physics framework and affect a only a handful of variables.

[JoWie]

I am thinking the differences in the floating point numbers between two platforms might be very small at 4 decimal places and I could handle it in my client side prediction framework. The precision at 4 decimal places should be good enough for the collision and physics framework and affect a only a handful of variables.

 

Wouldn't rounding at 4 decimal places (in base 10) have different effects on the precision depending on the magnitude of your number?

For example, a single precision floating point can represent every natural number between -16777216 and 16777216 inclusive (2^24), but after 16777216 natural numbers start to round:

((float) 16777216) == ((float) 16777215) // false
((float) 16777216) == ((float) 16777217) // true

And that is without any decimals.

(double precision is able to represent natural numbers up to 2^53 inclusive)

 

 

Edited September 13, 2012 by JoWie

[Dr Brain]

Edit- In effect lowering the precision of the floating point number but getting improved accuracy.

 

Point is that floating point numbers do not have improved accuracy over fixed point numbers. For a given size, they have less accuracy.

 

Also rounding doesn't make the problem go away. It just makes the problem harder to find.

 

EDIT: I'm not trying to tell you how to write your game. I'm simply participating in an intellectual design discussion. It is not my intention to be belligerent, though I know I can sometimes come across that way.

[Vidiot_X]

@Dr. Brain

NP. Speak freely. Math is not my strong point.

 

In my frameworks there are just a few variables that need to match on the both the client and the server. Those would be object position (x,y), object velocity (dx,dy) and object rotation. There are other variables involved but I'll use these as an example. At 4 decimal places there is likely to be little difference in the values of two floating point numbers on two separate platforms. So I might get values like these using single precision:

 

Platform A - 1.999991

Platform B - 1.999993

 

Truncated at 4th decimal place I would have 1.9999 on both platforms. In the case of:

 

Platform A - 1.999998

Platform B - 2.000000

 

If platform A is the server I could then correct the client (platform B ). This is what I was envisioning and why I suggested higher accuracy in matching between the two platform values.

 

This is an issue I had plan to research and I have had this method suggested to me by others.

[Vidiot_X]

Some interesting discussion about this here:

 

https://plus.google.com/u/0/111116177023306684673/posts

http://www.blitzbasic.com/Community/posts.php?topic=98786#1156840

[Vidiot_X]

It is looking like the best approach is to just deal with the non-deterministic nature of floating point numbers by correcting clients when they drift out of position due to differences in floating point values as they accumulate over time. Using a fixed point method will work but other math functions like Sin() and operations like +,-,* and / would all have to be processed by a fixed point algorithm.

[JoWie]

Just to clarify what I said about floating points math not always giving the same results on the same machine (I was not talking about randomness):

 

The x87 subset (of x86) has floating point instructions in 32bit, 64bit or 80bit. What might happen is that your 64 bit floating point may get temporarily converted to 80 bits in a cpu register, when this happens you may end up with different results than if it had stayed 64 bits.

This depends on how your compiler optimizes things, this is why using "volatile float bla;" in C should rid the problem.

 

The real fun begins when Just In Time compilation is used, in that case the optimization might be trigged during run-time, but it might also not be. In that case you could call a function twice with the same arguments and get different results.

 

SSE2 (which is newer) does not have 80 bits floating point instructions.

 

Bak- actually run into this problem in discretion. The thread is on ssforum somewhere.

 

In aphelion I replaced sin() with an integer approximation because it supports a huge number of rotation points. If you only support a handful of rotation points, you could compute the sin values on your own machine and place them in a lookup table.

Edited September 16, 2012 by JoWie

[Vidiot_X]

The x87 subset (of x86) has floating point instructions in 32bit, 64bit or 80bit. What might happen is that your 64 bit floating point may get temporarily converted to 80 bits in a cpu register, when this happens you may end up with different results than if it had stayed 64 bits.

This depends on how your compiler optimizes things, this is why using "volatile float bla;" in C should rid the problem.

 

Right on JoWie,

 

You could even have other applications mess with the level of precision resetting the register on the same machine. This post really sums up how I feel about this subject.

 

http://www.blitzmax.com/Community/posts.php?topic=98786#1157186

 

Client side prediction really does handle this sort of incongruity fairly well. Since SubSpace does not use this model the use of fixed point math is needed. My position is that server side corrections should easily handle the accumulated differences in an objects position.

[JoWie]

This post really sums up how I feel about this subject.

http://www.blitzmax....c=98786#1157186

 

that was what I was replying to haha.

 

 

Anyways, you would also have to correct bombs, mines, etc.

You would probably end up with a networking model that transers snapshots (with some delta encoding).

This is what valve's source engine does, by default the server sends 20 snapshots of the world per second and the client sends 33 input samples per second. The client can modify its snapshot rate on the server depending on its bandwidth. The client runs 100ms in the "past" by default so that it always has 2 snapshots to interpolate between.

Local player input causes prediction on the local player to prevent input lag.

Edited September 17, 2012 by JoWie

[Vidiot_X]

This is a video showing the server ship (white) moving on a client (yellow ship) at a 'one' second lag/delay (1000 milliseconds). I'm only using the 'lockstep' method sending a frame number and the moves for the that frame plus a position/velocity correction. So it's not catching missing or out of sequence frames (packets) but it looks promising so far.

 

The video recordings a little slow on the FPS but I thin k you can see what I mean. Just the first step in working this out but for a 1000 milliseconds of lag it's kind of cool,

 

http://www.youtube.com/watch?v=3taNSJhl2B8&feature=youtu.be

[Vidiot_X]

Hi,

 

Well it's looking good for client side prediction. It's really magical how well it handles lag. At the moment I am still exploring what exactly is the best implementation of this model but I do have bullet/ship collision working with a 1000 (it can handle higher spikes) millisecond delay. As soon as I have pinned this down I'll release something to test.

 

- Rich -

[JoWie]

Have you tried simulating packetloss?

[Vidiot_X]

Have you tried simulating packetloss?

 

Not yet. Right now I'm working out the best approach to predicting movement while waiting for the next packet. But I will simulate packet loss and latency spiking and test for these as soon as I finalize my prediction model.

 

But still, it's the coolest thing watching the local client duplicating a string of inputs from the server and then smoothly predicting movement. I can't wait to get something up to test and see how it does.