Scott T: The Blog
Un-Decoding VDXs
Posted Mon, Dec 21, 2009 at 5:20pm by ScottTagged: programming, scummvm
The usual direction when adding support for T7G and 11H to ScummVM is to take the data files, decode them, and get the video and/or audio out of them. Last week in a moment of boredom, curiosity, and 'how hard can it be?', I decided to work on working on going the opposite direction and have a look at encoding instead.
As it turns out, still frames were fairly straight-forward to implement due to the simple structure.
Animation frames were a little harder. Most of the issues resolved to be related to how I was attempting to keep track of palette changes between frames (and the rewriting of the new frame to line up colours common between both palettes but at differing indices), but I also got caught up in some minor logic errors in the encoder (in particular, encoding the same tile using two different methods, and requiring a "new line" opcode at the end of *every* line - not just those that end early). The final result can be found at this YouTube video (sorry - no embedding, since my blog doesn't support it).
Encode speeds currently aren't the greatest yet, the output VDX files are not compressed, and the encoder requires 8bpp Indexed BMPs for use as input, but it's certainly a start for proof-of-concept purposes :)
Comments
Do you still have the VDX encoder? Have you done any additional work on this? I just wonder if we exported all the assets out of T7G, upscaled them, and then re-encoded them, if it could make for a higher-resolution version of the game. Granted, that means rendering higher definition frames in 8bpp but, it still might be a better result than the native SCUMMVM upscaling of older games.
Posted Wed, Apr 10, 2019 at 3:58am by Chris