MADS disassembly is back on track

Since it's been a month since my last posting, I thought it was time to post a status update. The work on disassembly of the MADS (Rex Nebular) engine has been going well.. I've made a lot of progress on various areas of the game logic.

I haven't actually added much code to the ScummVM engine yet, since I decided it would be better to fully understand a given area before I implement it. At the moment, my reverse engineering has been some undirected - it's obviously more effective to work on whatever areas you can find that are easiest to disassemble, which in turn may make other areas easy to disassemble later on. However, it does mean that there are bits and pieces across the entire engine that are now understood better.

One area of the game engine that's going to prove interesting is all the hard-coded game logic - each scene has several routines associated with it for scene loading, scene animations, and handling interaction with elements. Obviously it would be preferable not to completely reimplement these in code, since it would take a lot of code space, and there are two other games whose code would also need to be reimplemented.

What will probably need to be done is to create some kind of basic script interpreter engine, and convert the various scene routines to an interpretable script. Luckily, most of the routines seem to use a fairly simple subset of x86 instructions, so it shouldn't prove an impossible task. In any case, that's something for the future, when I fully understand all the various routines the methods call. For now, I've set a short term goal of manually implementing the logic for the first game room, and will return to the idea of scripts at a later date.

On a final note, for those of you who like pictures, see below for an example of the scene walkable areas for the fist scene of Rex Nebular. It also has a slightly weird sprite frame from Rex inserted into the picture - Rex isn't movable yet, though.. it's just a test from some of the loaded sprites:

Roadblocks in the path of tSage

Those of you who have been following the IRC channels will know that I made some real progress in the disassembly of the tSage engine, used by the Ringworld - Revenge of the Patriarch game, as well as several others. I hadn't really gotten into any of the game logic, but I'd made great strides in decoding the image formats and graphics display, so much so that my engine on Scummvm-misc could display test dialogs, as well as the right-click game dialog with proper highlighting and everything. Sample screenshots below:





However, given the perversity of life, I should have known better than to announce on the channel that I was making real progress. :(. Because as I was getting into the game execution logic, I began to realise just how complicated they made the engine. Whilst using C++ has it's advantages from the perspective of RE, since it does group related functions close together with the variables they use, in this case, they seemed to go overboard with it.

A preliminary look at the main event loop of the game shows they implemented a stack of "action objects" - multiple independent event handlers can be registered and control swapped form one to the other. I'm not sure, but I presume that this is to allow for things like cutscenes, where standard game operation is superseded.

For even more complexity, they went with a class hierarchy for the action objects which is at least four levels deep!.
The classes, as far as I've been able to determine, are as follows:

• They have a core 'SavedObject' class, which has some internal logic for registering each object instance in a central list. I presume this is for automating saving and loading.
• A child class which I'll call "SmartPointer". This class seems to encapsulate a pointer to a secondary object, and provides core logic for 'fixing' up the pointer reference. I can't be sure yet, but there's a lot of 'fixup' code in the engine, which I presume handles restoring pointer references between objects when a savegame is loaded, and all the objects are re-constructed. This class also implement a basic virtual table of processing and dispatch methods that automatically defer to the foreign object if one is set
• Yet another child class which introduces basic event manager functionality amongst other things
• A concrete fourth child class which seems to further override some of the event manager functionality, and is what gets added to the game's "action list".
  

As you can imagine, all this makes it somewhat different to understand what the blazes is going on. I've also examined the engine from some other points, such as scene loading, and even that seems to be overly complex, with method calling method - they really went in the direction of generalised/generic functionality, with the result that the code seems to be much more complex than it should otherwise need to be.

</whinge>

In any case, the tSage engine was only meant to be a part-time RE effort for when I needed a break from the MADS engine. I did somewhat get carried away with it for the last few weeks, but that was only because the areas I was looking at proved so easy to reverse engineer. Now that I'm running into more complex code, I've decided that the break's over, and I'm returning to work on the MADS engine again. For that, at least, the code seems somewhat simpler, even if it can be a pain to run in the DOSBOX debugger because the segments keep getting shifted around in memory. ;)

For those of you who are Ringworld fans, don't worry, I'll still be working on the engine. It's just there won't be as rapid a progress on it as I'd recently hoped.

Working on Rex Nebular

The Scummvm-misc listing welcomes the new work in progress Dark Seed 2 engine by DrMcCoy. It looks very promising.

I've returned to spending a lot of my time working on the disassembly of Rex Nebular, and implementing it's functionality into the M4 engine. It's likely going to be an extended process, because the game engine is unbelievably complex. It likely comes from the MADS engine being designed as a generic game engine rather than just for single games specifically.

For example, I only just last night disassembled some of the code associated with displaying messages. Any given message is represented by a unique 'Message Id', which in turn loads a message resource that can contain an entire series of control elements for formatting dialogs. A sample message resource for looking at the curtains in the starting room is as follows:

[title25][sentence].Wincing at the "Drapes Of Wrath", you swear
to use them to light the fire when
you burn your ex-decorator at the stake

I'm dreading how complicated the actual script interpreter is going to be. :P

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.