On Fri, Apr 1, 2011 at 12:34 AM, Curtis Olson <curtol...@gmail.com> 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 ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
