Multi-player Multi-platform

[silnarm]

So I've been very busy unravelling the unit & projectile update process, I had thought I could deliver this without having to convert much of the code to fixed point arithmetic.  Indeed I had it mostly working this way, with the client becoming a kind of 'puppet', the results of command updates were sent by the server.  Despite packing these down to 1-4 bytes (depending on the resultant skill) this was using a bit of bandwidth, and then I found more problems.  Radius of splash effects is floating point (not a particularly big problem) and all damage calculations are floating point (big problem). Sending all these results as well was going to be too much information...

So, I bit the bullet. I've converted the vast majority of the floating point calculations (the stuff that effects the 'game state' that is) to fixed point. While the framework for sending updates I developed is now not needed, the 'hooks' have proved useful, at the moment I'm using them to checksum every update, and that is sent with keyframes (for debugging obviously, this means the client will throw an exception on the very command/projectile update that evaluated differently to the server, which will make tracking down problems rather a lot easier).

There is still some more fixed point conversion to do, and the small issue of the how to deal with the pathfinder (uses lots of floating point, not sure I want to change it), so I may just use the original idea of sending an explicit update from the server for the move skill. In any case, this should all be wrapped up on the weekend...

Multi-player Multi-platform, coming soon to a glest advanced engine near you 

[John.d.h]

So basically the longer numbers are being rounded to make them easier to send back and forth, right?

[titi]

Sounds good!
Lets hope this floatingpoint issue is the problem we have and not something else (too) ...

[silnarm]

So basically the longer numbers are being rounded to make them easier to send back and forth, right?

No, they are just being represented differently, to eliminate rounding errors, or make them exactly the same errors regardless of he compiler. I'm using the same number of bits as floats.  Integer arithmetic is very well defined and has perfectly predictable results, the same is not true with floating point numbers, so we just represent our fractional numbers as integers, with a 'fixed' point.  This removes the need to send lots of information back and forth, as you can trust the calculations will give the same results.

I'm not putting great emphasis on accuracy, but fixed point can give you that too, for example all the calculations your bank makes on your money (interest etc) is done in fixed point, and great care is taken to make sure no precision is lost, and no rounding takes place, otherwise money would 'disappear'.

Sounds good!
Lets hope this floatingpoint issue is the problem we have and not something else (too) ...

Let's hope indeed, the way I'm currently checksumming all updates will at least make it easy to tell if anything else is amiss.

[Yggdrasil]

This is really nice. Keep rocking silnarm. This will hopefully spawn some more interest in multiplayer.

[silnarm]

Just an update for anyone interested.

  I had some, inevitable, issues with the changes I made. The nastiest of them are now sorted, but something bizarre has happened with the build command, which results in workers moving to the build site and then proceeding to walk around in circles.  Die animations are sometimes being skipped too, and just going straight to the last frame.

  Hopefully will all be sorted soon, and should be ready for at least an alpha test on the weekend.

  I currently have the game saving the results of all updates, if the client does get a sync error it dumps a log of the the current frame and then sends a message back to the server requesting it do the same for the offending frame, so if there are any more sync issues we'll get good information about where to look for them.  This is also why it will only be an alpha initially, I'd like to leave it all enabled obviously, but it will need to be turned off for a public release.

  Anyone who can't compile and is willing and able to test linux-windows games (on LAN, internet not recommended with all the checksums in the keyframe) please PM me with an email address, and I'll make sure binaries find their way to your inbox when they are ready.

Cheers.

[titi]

Just some thoughts what all maybe involved in this floatingpoint->fixedpoint problems:

- pathfinder
- shot hit calculation
- collision detection ( is there something like this when units move beside the pathfinder?)
- unit placement
- random number calculation
- unit uphill/downhill speedup
- terrain smoothing after loading maps ( this effects the one above too)

Did you find some more Problems?

By the way do you use an external lib to do this fixed point calculation? When these problems showed up the first time someone from the springRTS community mentioned something like this.

[silnarm]

- pathfinder
I side-stepped this one, fixed point isn't as fast, so I'm just sending move updates from the server.

- shot hit calculation
Converted to fixed point.

- collision detection ( is there something like this when units move beside the pathfinder?)
There is no 'collision detection' of any note in Glest, beyond the cell map.

- unit placement
Is all integer.

- random number calculation
The only ones that make a difference to the game state were already integer, int and fixed interoperate nicely.

- unit uphill/downhill speedup
- terrain smoothing after loading maps ( this effects the one above too)
The move updates mentioned above also contain the length of the skill cycle, the 'servers says', the client does.

Did you find some more Problems?

All skills are updated via floating point, a progress counter between 0 and 1 is added to in each update(), these cycle lengths are all the same except for the move skill, so the server calculates them all and sends the results to the clients before the game starts, This is in the SkillCycleTable class. This also holds anim cycle lengths, and attack system start times (as a frame offset into the animation cycle) for attack skills. Also, projectile paths are calculated by the server and sent as updates, although this could probably be converted to fixed point without to much concern over performance.

By the way do you use an external lib to do this fixed point calculation? When these problems showed up the first time someone from the springRTS community mentioned something like this.

No, I rolled my own, borrowing the sqrt() function from c.snippets.org.  Fixed point needs to be handled carefully, using someone else's code would not have been a good idea I don't think.  You need to know how they work to use them effectively, and safely.