Re: [Flightgear-devel] Replay system

[ThorstenB <br...@gm...>]

On Fri, Apr 1, 2011 at 12:34 AM, Curtis Olson <cur...@gm...> wrote:

>> So, it might be a good idea to record all properties in an interval of a
>> few seconds only, while only recording properties that have actually
>> changed with every frame. That should allow to drastically reduce the
>> amount of recorded data - and allow much longer high resolution memory
>> recordings. And you could still fast-forward within the buffer, since
>> you'll have a complete set of properties every now and then. It's a
>> simple but effective compression method which is used in many areas.
>
> Pluses and minus to every approach ... determining if a property has changed
> by enough of a threshold amount to log the change would be extra work and
> could also complicate the playback, so that would have to be balanced
> against the potential pay off.  When you get away from a fixed record
> format, then you need a way to identify/tag each data value along with a
> corresponding time stamp, so you have to give some of the space savings back
> ... and I would imagine to do this efficiently (space and time) could lead
> to some pretty complicated errr sophisticated logging code.  I'm not saying
> that's bad, but this is a pretty complicated proposal I think when you start
> digging into the details.

In fact, frames of tagged values is the same method we're already
using in encoding data for multiplayer transmission. Though that
module could also do with some improvements (*yikes* it's currently
packing each 8bit string character into a 32bit value for
transmission). Also, it doesn't reduce traffic by detecting unchanged
values yet (UDP transmissions loose some data, so that's more tricky
here, though also not impossible).

Yes, the tags are additional overhead. But I'm quite convinced that
this schemes outweighs the disadvantage - if we used this to encode
changing values only. I checked our current recording data structure:
it has a huge size of 1160 bytes for every frame. Also, the fixed
structure needs to reserve space for the maximum number of
wheels/engines/tanks etc - so even if an a/c has fewer tanks/.., it
still uses up the space. And it doesn't work for aircraft which
somehow exceed the default (btw, I saw a maximum of 4 tanks and 3
wheels is configured, so that is why there are gear replay issues with
4 or 5-gear aircraft, like the Concorde...). And looking at many of
the recorded properties, I think many of them indeed will hardly ever
change from frame to frame, so this 1K structure could probably be
reduced significantly - despite extra tagging bytes.

Thinking about it, it should also be possible to join some of the
multiplayer and replay code. The replay system could use the existing
encoder of the multiplay manager to generate the data packets - but
then record them locally instead of transmitting them via UDP. During
replay, these packets could then also be decoded by existing
multiplayer code. Might be worth a thought, if someone wanted to dig
in this area.

cheers,
Thorsten