Can't be positive but it looks like things are fairly stable now as far as saving is concerned.
For testing, I've saved smack dab in the middle of complex controlled sequences, involving lots of character motion and multiple scripts, and it comes back like nothing ever happened, so that is a good sign.
So, with that fixed, I am moving on to other things, namely, implmenting our, Company Logo/Intro/Credits.
At first we used Flash to mock some stuff up, and export to AVI, but this proved horrible.
The only way to save space was to use some compression codec, and then said codec would have to be distributed with the application, and installed.
We didin't want to get into that can of worms, so we decided to revive an old idea we had.
The Cinematic component was writen a long long long time ago (but not in a galaxy far away [grin]), and it's purpose was fairly simple.
Show images in sequence and with interpolated properties across key frames.
At the time, it fell far short of the glory, it was very hard to use and didin't have all the features I wanted.
Now however, I am going to re-tool this component and actually make it an engine component (so any game written with flare can have cinematics).
This integration we feel is fairly important, since during a cinematic we want to have everything else stop and full control go to the cinematic.
While this is achievable by the Application extension of the engine, it is a bit of a hack (multiplexing the User engine state), So instead we are going to create a new engine state for cinematics.
The goal we wish to reach is that playing a cinematic at any point is as easy as:
g_game.LoadCinematic("intro","data/intro.cine");
g_game.PlayCinematic("intro");
So what exactly is a .cine anyway?
A .cine file, like most files in the flare engine, is an xml document, which describes a component based 'movie'.
Here is what some sample XML would look like:
data/frame0.gmb This is some text. data/sound1.ogg As you can see, the movie specifies at what FPS it would like to be displayed at, this is used by the TBM(Time Based Motion) system to make the movie play as closely as possible to the original intent.
The heart of a .cine contains a number of layers, layers overlap each other in decending order, so the last layer will appear on top of everything else. Each layer has a certain content type, at the moment only types "image", "text" and "sound" are supported.
A layer can have any number of "keys", a key is an instantaneous state of the properties of a layer, properties such as:
-x
-y
-width
-height
-red tint
-green tint
-blue tint
-alpha blend
A key also specifies how much space (in frames) it displaces, each subsequent key will be placed after the preceding key, in frame-time.
As time passes between these keys, thier properties will be interpolated (linearly, at the moment), using this functionality, more complex effects can be created such as, fading an image from 0 to 255 alpha, over the course of 30 frames.
When a .cine is loaded, the XML is parsed into an object model representing the movie, this object model can then be processed by the engine to produce the desired visuals.
.cine files have many pros and cons
Pros:
-very small file size compared to bitmaped video
-loads almost instantly
-less load on the system to play
-defined with XML, and so can have additional app-specific data
-no codec required
Cons:
-VERY hard to achive certain effects that bitmapped videos can
-No visual editors
-Doesn't look the same on all graphics adapter implementations
On the whole I think it is the best system for our needs =)
