New SourceForge project - Scummvm-misc

It's been a busy month. As those of you who follow the mailing list will be aware, I finished work on an engine module called Gargoyle over a month ago, that allows the playing of Infocom z-code text adventure games. Unfortunately, the consensus was that it really didn't fit in with the ScummVM theme of point and click adventure games. So I created a new project on SourceForge named Scummvm-misc to host the project. But I'd been so busy that I've only now had time to create a proper homepage for the project.

See Scummvm-misc for the project's new website. Rather than just create a project specifically for Gargoyle, I decided to keep the project name generic.. Gargoyle isn't the first non-point 'n click adventure engine, and there may be more in the future. ScummVM provides such a solid base for creating games that can run on multiple systems, I figured it would be good to keep track of other such engines.

The index page I've created also lists all the other publicly known ScummVM engines that are either in development or for which work has stalled. Anybody in the future who'd like to start work on any new engine, and wants the source to be publically available, is welcome to share SVN space on the project.

Finally, two screenshots from the later Infocom games, that used a combination of graphics and text:

Cruise for a Corpse Complete

After many months of work, the Cruise for a Corpse engine plays the PC version of the game all the way through without any bugs.. I was also able to figure out and implement music and sound effects as well, although currently only the PC Adlib player is supported.

The Amiga and Atari ST versions of the game will probably play all the way through, although music and sound effects handling will need to be implemented for them.. I'll leave it up someone else more familiar with those systems to take care of that sometime in the future.

It's when you're diving into fixing and extending engine code like this, the old maxim 'The devil is in the details' comes to mind. Even the smallest mis-print or mistake in the code can cause errors that are hard to track down. It's actually kind of a relief that, as far as I know, it's all over and done with now.

Anyway, I plan to spend the rest of my vacation time (I'm on holiday until the 22nd) getting in some R&R, and some more generic mucking around on ScummVM - this will probably include some time spent working on the MADS disassembly, so people can look forward to further work on Rex Nebular in the near future. :)

Foray into Cruise for a Corpse

Hello everyone. It's been a while since my last blog posting.. I really should get into a better habit of posting updates more often.

Having largely finished adding Discworld 2 support to the ScummVM Tinsel engine some months ago, rather than immediately returning to work on MADS, or some other project, I decided to take a detour and work on the existing 'Cruise' engine, which plays the game 'Cruise for a Corpse'. This was an existing incomplete engine in the ScummVM SVN, which had been languishing for a while without any significant progress being done.

Having been working on it since late February, it's now in a somewhat cleaner and more stable state than it was previously. A lot of bugs have been fixed, and I've also done a lot of cleanup of the code as well, such as giving structure variables more proper names, fixing up variable types, etc.

I'd originally hoped to have reached a milestone of having played the game all the way through to the end before I made this blog posting, but my debugging practices almost demand that I fix these bugs before carrying on with the game.. those remaining bugs tend to be annoying buggers.. I'm currently grappling with two really nasty ones:
* I've got an animation of a moving handle in the engine room that is drawn incorrectly for only two of it's frames.. it could be a problem with the transparency mask for the image, but all fixes I've tried so far screw up the decoding/display of every other image in the game.
* There's a bug in the path-finding code code that's particularly noticeable in the area below the top deck, in that you can walk through walls directly from one exit to another.

I was really on a roll up until I discovered those bugs.. I had reached the 1:30pm segment (the game is divided into time segments that only advance once you've done certain actions) and had fixed several crashing bugs, and was hoping the end of the game was in sight. Now it will have to wait until I've fixed these bugs.

I'm hoping to get Cruise to a nicely completable stage soon. The only other major remaining area in the game after that, apart from some minor ones like getting the game speed exactly the same as the original, will be the sound support. I was given a suggestion that I might be able to copy and paste the code from the previous version of the engine (cine), but whilst the formats seem similar, and I was able to get some sound playing in my experiments, the sounds played are incorrect.

As I've always been on record as saying, music handling is my least favourite area to work in. I may try some further experiments to get it working, and if i still have trouble, I may simply drop it completely, and leave it to anyone else who might be interested in taking it up in the future. At least they'll have a more solid game base to add onto.

On a final note, my holidays for this year were severely delayed, so I'm still looking forward to a month's holiday at some point. I anticipate some productive time spent happily disassembling and implementing games for ScummVM. :)

Discworld 1 Demo support added to SVN

Whilst it's nowhere near as spectacular as adding support for Discworld 2, the latest SVN code now supports the original Discworld 1 Demo.

This demo is somewhat interesting in that it was built at an early stage during the development of the first game. As such, it used a more primitive version of the source code used in the final game. Luckily, it didn't prove too hard to cross-reference a disassembly of the demo executable and identify commonalities between it and the DW1 v1 source code, and from there work out what had changed.

The demo version I used during development was downloaded from Adventure-Treff.

There were actually two demos released for DW1 - this first one contained only the two 'rooms'.. the Fishmonger's and Alley, and the single objective of getting the belt buckle. Please note that this version does not have any sound.

The second demo released apparently contained most of Act I, and featured full voices and SFX. If anyone knows where a copy of that version can be located, I'd be interested in making sure that that version also works with our Tinsel engine.

Discworld 2 support added to SVN

Well, it's been a little over three months since my last posting, and now my current efforts are finally complete.. as of last night, Discworld 2 support has been committed into the ScummVM trunk.

First things first - setup instructions will probably be added into the main README shortly, but for those of you who just can't wait to get it up and running need to do the following steps:
copy the contents of both CDs into a folder on your hard disk, and rename the ENGLISH.* files on both CDs into ENGLISH1.* and ENGLISH2.* respectively. That goes for other foreign language versions the same, with whatever the language name being.

Remember that Discworld 2 isn't officially supported by ScummVM yet. To play it, you'll need the latest daily build from at least 2/12/08, or build it yourself. We also don't have a Discworld category under the ScummVM Bug Tracker, so any issues would be best discussed in the IRC channel or on the forums.

Special thanks go to DrMcCoy, who pitched in and implemented the changes to the sound/music handling for Discworld 2. Also to the rest of the team who participated in the Discworld 1 development, who provided the occasional code additions and testing during integration of the Discworld 2 code.

In case anyone's been wondering about my progress on the M4 engine, well, my apologies, but wouldn't you know that barely a few days had passed after my last blog posting when we got the Discworld 2 source. So I never really had a chance to delve much further into the graphics system like I said I would. Never fret, though, it's still a long term goal to finish disassembling Rex Nebular and start adding support for it, although I'll probably put it on hiatus again if the team gets given the source code for any other game that needs implementing. As fun as reverse engineering is for me, it's nice to work on a project where you can see rapid results from your work.

What's next for me? Now that the code's been publically released, I plan to move onto adding support for the Discworld 1 demo. I've already been spending some off time working on a disassembly of the executable, cross-referencing methods against the Discworld 1 source, and it shouldn't be long before I can start adding demo-specific code to the Tinsel engine.

Oh, and of course, I've still got copies of LittleBigPlanet and Fallout 3 on the shelf waiting to be played. They've been calling out to me in the middle of the night, saying 'Play me, play me', but I've been firm.. I wasn't going to play them until Discworld 2 was finished. Now that it has, I expect to spend some quality time this Christmas traversing the wasteland, and blowing the crap out of stuff. :)

Well, it's been a little under two months, and now the Tinsel engine has been released to an eagerly awaiting public. I just hope people don't get too distracted playing it that they forego testing the other games for the 0.12 release. :) Currently Discworld 1 is supported, but not the demo. Kudos to everyone else involved in bringing the conversion to ScummVM to fruition so quickly.

On a more technical note, those of you who are proficient with using the debugging console may wish to experiment with the console in this game.. there are several commands, such as "scene", which allows you to jump to any particular scene number. Another nice one is the "sound" command.. I particularly like "sound 5931". :)

Given the amount of time spent on the Tinsel engine, I haven't had much time to work on the disassembly of Rex Nebular. So there hasn't been much to talk about on my blog. But now I'm back into it again. When last I left, I was starting to plunge into the depths of the dialog display code. This actually proved a useful starting point because:

1) The difficulty dialog is the first thing displayed by the game as it starts, which makes it easy and quick to trace to when running the game in the debugger.

2) We already more or less know both the screen and sprite format used by the engine, which makes it easier to understand and decode the related routines.

3) It also uses font display, which again, allows me to quickly identify the appropriate routines.

4) It allows me a starting point for identifying various other routines, such as mouse/cursor handling, event loops, and graphics routines.

As you can see, the dialog code provides a useful starting point for understanding core functionality used by the game. By identifying these routines, it will make it easier later on to understand other game routines that make use of them. The only problem is that the dialog display code seems to be unreasonably complicated - it seems they tried to used the same code to potentially handle various dialog text, such as headers, control options, and savegame names.

It's a real pleasure to be able to be able to return to proper disassembly work after the interval I had to spend writing the delinker tool. Subjectively, I know that writing the tool was a necessary step that would save me issues in the long run, but it was still annoying to have to write and then spend all the time fiddling with it to get it work, particularly since I'd never really bothered to look at the structure of executables, and was learning from scratch.

Getting stuck into Rex Nebular, I've started debugging it using the DOSBOX debugger. I was a bit unsure about using it at first, but it's turned out to be an excellent tool. Back when I was disassembling Lure of the Temptress, I made do with DEBUG, which wasn't bad, but obviously had issues with trying to debug graphics programs.. I'd actually had to hack the game executable to stop it setting graphics mode so that I could use DEBUG to trace through all the startup code. Now with DOSBOX, I can trace anywhere in the program, since the debugger itself is in a separate window, which is wonderful.

About the only real annoyance remaining is the RTLink library itself. Although I do have a full disassembly based on a processed executable, I still need to do my debugging on the original executable (if the game worked without the extra space it provides, they wouldn't have needed it in the first place). The issue is that due to the way RTLink works, a call through a proxy stub can actually unload the calling code, which then gets reloaded when the called function exits.. but not necessarily in the same place.

Which means that you might try stepping over a function call, and suddenly the entire game sequence will play out, because the location returned to after the function call may now be at another segment address. Confused me at first, until I happened to trace out of a method and realised what was happening. :)