Re: [Alephmodular-devel] Copy-on-write in practice

[Woody Z. I. <woo...@sb...>]

On Thursday, January 16, 2003, at 08:18  AM, Woody Zenfell, III wrote:

> I see, yes since I didn't really have any obvious problems with the 
> current code in this regard, I didn't spend much time thinking about 
> these issues, and so my suggestions were generally made with something 
> rather like the current scheme in mind.

I should mention that I rarely manage (yet) to think of how the stuff 
would work in a non-game, which I know is very important to the 
project's goals.  So the stuff I wrote does not necessarily work well in 
such an environment (though offhand I can't think of any specific 
problems).

> Though my COW discussion was heavily biased towards prediction for 
> simplicity, the same mechanism would be used for interpolation.  The 
> basic idea is to be able to split off a copy of the game-state, mess 
> around with it, render from it, and then throw it away (returning to 
> the original state).

It occurs to me that a sufficiently generalized chain-of-game-states 
(which IMO is what we want anyway, despite needing at most 3 for my 
real-predictive-interpolative scheme) could also be used to support 
reverse film playback.  Naturally the bulk-copy approach would probably 
be ill-suited to this (except where implemented in an OS with general 
COW memory support and some intelligent placement of likely-to-change 
elements near each other in memory) because the larger amount of memory 
required per game-state would really start to add up when you're keeping 
around a hundred of them (or however long a chain you might want, 
determined by how far you want to be able to back up).

(You could just remember periodic "keyticks", and on backing up, compute 
forward varying amounts from those, to (greatly) extend how far you're 
able to go backwards in a reasonable amount of memory.  Or actually, you 
could remember keyticks that are like exponentially far back (e.g., last 
tick, 2 ticks ago, 4 ticks ago, 8 ticks ago, etc.) or that happen 
periodically (keep the last 8 ticks as well as every 64th tick, etc.), 
with the idea that backing up a little bit is going to be done more 
frequently than jumping back a long way, but without totally abandoning 
the ability to back up a long way... and without having to recompute all 
the way from the start of film when you do.  Of course, a game-state 
that's 64 ticks after its "base" is probably going to have more changes 
(and thus require more memory) than a game-state only 1 tick after its 
"base".)

Anyway speaking of keeping around lots of game-states... I wonder if 
roughly doubling the size of a saved-game file (to account for unpacking 
int16's into int32's in many cases) would give a reasonable 
estimate.  (?)  If so, well, my saved-game on Waterloo Waterpark (from 
AM) is about 230k, which points toward roughly half a megabyte per 
resident game-state if no "store-only-the-changes" scheme is used.  
(Less-complicated net levels might require substantially less storage.)

Of course, estimating how much stuff *changes* per tick is a bit 
trickier without any of these mechanisms already in place.  :)  But, 
it's bound to be smaller (most of the map geometry, e.g., is constant).  
(Anyone want to take a guess?)

(Of course, an in-game game-state-chain-based replayer and a 
render-to-DV/MPEG/etc. tool (maybe also in-game, with an in-game movie 
player for conveniently viewing the results) are not mutually exclusive; 
each has advantages.)

</random thoughts>

Woody