Scott T: The Blog
Digging into T7G iOS
Posted Tue, Nov 29, 2011 at 8:43pm by ScottTagged: games, programming, scummvm
7 comments
I've been thinking about writing up this post for the last few months now but with the release of ScummVM 1.4.0 a few weeks back (which supports T7G iOS), now seems like a suitable time.
My first iOS game!
The 7th Guest for iPhone and iPad was announced mid last year and then released in December. I read around a bit at the launch and it seemed a mixed bag - three culled puzzles (including the notorious microscope puzzle), high framerates for most videos, but a good large dose of nostalgia for many people.
Back in April I was able to borrow a friends iPhone, and so was finally able to test out the port for myself. Though it played fluidly, it was a little rough around the edges - the music was a little flat (admittedly this is personal preference), the cursor mapping just above the finger was a little awkward for some puzzles, high-speed animations included all the 'teeth' events which took away from the atmosphere (and caused out-of-sync music). Interestingly, the port also suffered the same problem as the Windows interpreter (see ScummVM bug #2831041) though not too surprising given the Windows release source was likely used as the reference. Similarly, the cake puzzle bug also still exists.
After the playthrough, the next step was to obviously look under the hood. After extracting the app archive and digging down into the folder heirarchy, it turns out almost all the original game datafiles were present, completely untouched (including the original introduction and credits - both of which were replaced in the port). Data-wise, the largest change was the removal of XMIDI music in favour of AAC.
AAC powered music!
Work then began on the required changes to support the game - clone2727 mostly worked on the AAC decoder (as part of extending the QuickTime code) while I added the necessary changes to handle and load the music resources as well as a config file option to run the game at faster game speeds (add t7g_speed=tweaked in the ScummVM config file for faster walking/puzzles but normal cutscenes and supernatural events, t7g_speed=im_an_ios for all non-cutscene videos sped up).
Stauf is back for more microscopic action
In the end, it was a relatively straight-forward process to add support for the game. The missing puzzles are also back as the required game scripts were never removed. Best of all - this provides an easy way (if you have an iTunes account) to grab T7G but play it on whatever platform you desire :)
Un-Decoding VDXs
Posted Mon, Dec 21, 2009 at 5:20pm by ScottTagged: programming, scummvm
1 comments
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 :)
11H Cursors - Part 2
Posted Mon, Aug 31, 2009 at 12:57pm by ScottTagged: programming, scummvm
2 comments
After some questioning of my original logic, another look at the disassembly revealed I'd misinterpreted a few bits and pieces wrongly. A short time later, and we get cursors without missing pixels =)
Still no alpha-blending, so the black edges are still visible and the hand isn't see-through, but it makes it a lot easier to navigate through the mansion.
Pointing the Way
Posted Sun, Aug 30, 2009 at 11:20am by ScottTagged: games, programming, scummvm
2 comments
In a combination of getting my mind off of study, and giving clone2727 no reason for not posting Riven videos - see the IRC logs (at around [15:00]) for explanation - you can now see where the mouse is located in 11H (and the other GroovieV2 games).
There still needs to be a little bit of work done though. For some reason that I'm yet to determine, some pixels of the cursors are still missing (more obvious in the full-sized images).
Blending is still not supported, although how to apply the blending has been worked out. Currently I'm assuming the cursor will always be over the top of a black background, which works well when it is (like the above) but not so well for when it isn't.
And as much as the above image doesn't show it, they are animated although the transition between hand direction isn't implemented yet.
Beating JPEG
Posted Wed, Jul 01, 2009 at 11:03pm by ScottTagged: games, programming, scummvm
2 comments
One of the main sticking points for working on The 11th Hour recently (ignoring lack of time) has been the still frames within ROQ files. Although seemingly trivial within T7G, 11H uses more complex/advanced image compression for both video and stills. The video frames have been working for a while with some very minor glitches however the still frames use JPEG, and it's hard to find a decent documentation source. Never-the-less, some work had been done prior to now by clone2727 (for Mohawk) and jvprat which I obtained last week and then became rather obsessed with fixing =P
From rather simple beginnings, there were some rather critical issues to be fixed first (ie, missing functionality) which rapidly pushed towards a greyscale image.
Fiddling here and there resulted in a vast number of -ish improvements until a breakthrough resulted in the following:
All the AC components of the image seemed fine so after fixing an issue with the DC values, success was reached. Five minutes of tinkering to add JPEG to the 16bpp branch and we have the final image, rendered in RGB.
For those interested in the progress shots, the (semi-permanent) gallery has many ways of not to decode a JPEG.
