Use mkxp-z bitmap animations for Intro Cinematic

[SebastianMeinberger]

Mkxp-z allows, in contrast to regular RGSS/rpgmakexp, to add multiple frames to a bitmap and to then play them at a predetermined frame rate that is independent of the game frame rate. These animated bitmaps can be loaded from a gif or be constructed manual at runtime.

Combining the 300 png frames from the intro cinematic into a gif and playing them back using the corresponding mkxp-z functionality has the following advantages:

• Better file "compression". While the gif format doesn't use any real compression, the final gif (edit: plus the first 14 png frames) is 3.8 MB big vs 19.5 MB size of the pngs. This is due to the gif being able to use a concept similar to delta frames, i.e. frames don't include the entire final picture but only the differences compared to the previous frame.
• (Slightly) faster initial loading time. This is due to less cpu stress and less individual io operations. PNGs utilise multiple compression algorithms and therefore first have to be decompressed by mkxp-z, while a gif contains plain bitmaps which only have to be blitted. Also, only one bigger file needs to be opened instead of many small ones, which causes less io overhead. The real difference seems to be pretty small (on my system it resulted in around 1%/0.1s faster loading, so not really noticeable, but still a nice side effect)
• Less code. The entire 051_Addons/Movie.rb file can be removed, since the playback of the gif/animated bitmap is handled by mkxp-z.
• Intro Cinematic becomes frame rate independent. While the current implementation tries to consider different frame rates (it waits framerate/20 frames between displaying the individual intro frames), it plays the intro at the wrong speed if a frame rate not divisible by 20 or a dynamic frame rate is chosen. I know, currently the official version is only meant to be played at 40 fps, but this would be a good base for making the rest of the game frame rate independent in the future.

All in all this isn't a game changer, but decreasing game size and code complexity is always a nice thing.

Edit: I realized, I should further inspect the quality loss, that can happen due to GIFs 256 colors per frame restriction. On the first frames, the degradation is actually pretty bad, due to all colors getting lighter with each frame. Therefore, I decided to keep the first 14 frames as PNGs with full color space and then to simply prepend the frames on startup (mkxp-z has no problem with mixing and matching those, since they get decoded to pure bitmaps anyway).
On the frames after this, there sometimes happens some loss of color. But in my opinion it is never noticeable without viewing it frame by frame and then zooming in pretty hard.
Some examples:

Original	GIF