Movies
The "Movies" window allows to view and change the movies (cutscenes) of the game.
The game supports three cutscenes:
- Intro
- Death
- End
While death and end have only one variant, intro is localized for the three languages.
One movie has three media channels: video, audio, and subtitles.
Even though intro is stored in three files, the subtitles are always stored for all three languages. This means, the German intro movie also contains the French subtitles for example.
The editor only supports the "high resolution" format of the cutscenes, as this is the most common format nowadays.
There are three formats:
- High resolution (600x300), used by the CD-ROM version and the Enhanced Edition
- Mid resolution (320x150), used by the CD-ROM version as an option
- Low resolution (320x200), used by the Floppy-Disk version
Audio is based on a mono, 8-bit uncompressed waveform with 22kHz sample rate.
Import/Export is possible via .wav files.
Subtitles are available for three languages.
Import/Export is possible via .srt files. These are special-formatted text files. Note that only timing and text itself is supported, nothing more.
When timing subtitles, it is recommended to have one (perhaps two) subtitles per scene. Since subtitles are cleared upon scene change, avoid placing a subtitle immediately before a scene change happens. The editor will move a subtitle to the next scene automatically if it is set within 500 milliseconds before the change.
While the editor exports end times for subtitle entries, these are ignored when importing.
The color and placement for subtitles is currently hardcoded. A later editor version may support more fine-grained control.
The video has a size of 600x300 pixel, and uses 8-bit paletted colors with 255 colors per scene. The framerate also differs per scene, and is typically below 15 frames per second each in the original.
Import/Export of scenes is possible via animated .gif files.
Editing video is the most tricky part. The compression algorithm is geared towards large areas that don't change over time. The originals have little movement in specific areas with large areas being static.
When importing a new scene, compression can take long (This can be even minutes). The longer it takes, the more likely it is that the import will fail, due to several limits the compression algorithm has. For reference, export an original scene and re-import it again to get a feel for a "working" case.
The implemented encoder is a best-effort one. How the original encoder actually worked I have no idea, and I lack the knowledge of properly cracking it. The current implementation needs only a little bit more space than the original files, so it's close enough for the effort poured in.
- Remove "noise" as much as possible. The graphics tool "gimp" has a function for animations to detect changes (Filters -> Animation -> Optimize (Difference)). This removes all static information from layers and leaves only the deltas. With that, you can have a look at changes and remove any "change" that does not contribute to any movement. Videos often contain some "film grain", which is the bane of this ancient compression algorithm.
- Reduce the use of different colors as the last resort. It is more recommended to keep large static areas.
- Redrawing large portions of the framebuffer lets the playback stutter. A scene-change is a complete redraw.
- When creating the
.gif, use a palette of 255 colours. The subtitles use the color of the last palette index, which the editor will overwrite. Should the imported file use 255 colors, then the use of the last index is matched to the next best color. The colour index 0 will be used as the background index with color black. - Should the editor import a GIF wrong (first frame OK, further ones with large black areas), try exporting the GIF with replacing frames (rather than delta-frames) from your graphics tool first. I may not have implemented the GIF frame-replacement algorithm correctly.
Animated GIF files store frames with 1/100th second timing resolution. The rate of the codec is more fine-grained and timing suffers a bit between the conversions. When exporting, the editor rounds to the next 10ms, yet with a scene of 100 frames, an error of 4 milliseconds already accumulates to 400. To fix this, the editor allows to change the timing per scene with a slider. This fraction slider has frame timing in 1/65536th of a second, but only allows the number range of 1-16384 (250ms). This slider is not visible if the imported GIF specified a delay of one second or more.
The codec supports per-frame-timing. At the moment, the editor only allows for setting the frame-time for entire scenes. If the imported GIF has different durations per frame, these are respected.
The editor window will show a red "Size warning" label should the corresponding file need more than 16 megabytes. This is due to the internal limit of the engine about what can be stored in resource files. It is recommended to reduce the number of frames in your movie in this case.
If you reach this limit, the video still will be played by the engine, though it does so by a "bug" and more by accident than intentionally. As long as all the current engines keep this behaviour, then you will be fine - a future patch might stop supporting such files though.
The movie lasts until the last media has finished. If audio takes longer, the last frame is displayed, frozen.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
