Explosive decompression

Looking back, despite my earlier promises of posting more regularly, it seems I've been a bit tardy in posting updates, and quite a bit has happened. So lets get up to date with what's been happening with me. Firstly, we finally got some proper bug reports for Return to Ringworld, and have been working to fix them. Well, moreso Strangerke than me, so thanks go to him for his work in fixing bugs when he has the time.  As of right now, the card mini-game still isn't fully functional, but at least the main game is that much more polished now than it was.

Secondly, as of Monday, I finally merged the next game I was working on, Voyeur, into the project's master branch. This is a weird little game that Strangerke put me onto, because the original DOS executable had debug information embedded in it, which made it somewhat easier to implement. Still a lot of work to understand the contents of methods, reimplement them, and get the game in a stable state. But it made a nice change of pace from all the TsAGE work, where we had to disassemble everything from scratch. As of right now, the Voyeur engine only supports the DOS version. Apart from DOS, there were also CDi and Macintosh versions released. The Mac version at least may be supported at some point in the future, although there is some extra complexities we'd have to worry about due to the Mac-specific data in it, such as rasterized fonts that the PC version doesn't have. Adding support for it might make a nice future mini-project for a Mac enthusiast.

So what's next? Apart from further bugfixes for both Return to Ringworld and Voyeur, I'm already onto my next project.. once again tackling the white elephant of Nex Nebular, for the 3rd time. This time, though, things will hopefully be different. Using my experience with disassembling the TsAGE sound system, I tackled the sound system first, which was the major previous remaining stumbling block. And as of last Sunday, I finally got it working! That's right, my new embryonic MADS engine was able to play back the explosive decompression sound you get when you fail the copy protection check. It was a wonderful feeling, after spending a week reverse engineering and then implementing the code, then having spent an afternoon trying to debug my code and compare bytes being written to the ScummVM FM_OPL driver against the port writes in the original running under DosBox, to finally get everything right, and hear the sound coming out of my speakers.

 It turns out that despite some funky assembly tricks in the player that I had to work around, the player itself is actually a fairly compact, simple implementation. I'm no sound expert (as my frequent prior complaints make clear :) ), but I understood enough to give the various methods in my code halfway decent names, and name at least some of the fields. Hopefully a further analysis, now that I have cleaner C++ code, will help me better understand what's going on, and give the rest of the fields more proper names.

Now that the issue of sound support is taken care of, how am I going to proceed from here? I have a lot of code back from the earlier combined m4 engine which had code from both Rex Nebular and Orion Burger. Part of the trouble with the earlier attempts, I think, was that we were overcomplicating matters. As such, I'll only gradually put in code as I need it, and not worry so much about M4. That'll help me keep the focus more on getting Rex Nebular to work. Not that I'm going to just chuck out all M4 code from the engine. I've already started work on making the core classes, such as the previously named 'M4Surface' class, having a cleaner structure more suited for multiple games. For example, it'll now have it's own class factory, which will abstract having a base MSurface class that will have different descendants that implement the various game specific load/display logic. That seems cleaner than littering the code with "if isM4()" checks, and having methods like "rexLoadBackground". As far as a caller is concerned, they'll just initialise a surface, and the factory will take care of giving them the right kind for their game.

With a cleaner separation of game logic into descendent classes, I'll be able to, for example, keep in place special cases we'd already figured out for Riddle of Master Lu, and make it that much easier to implement support for it later. So that should keep a certain team member who shall remain nameless happy.  :)

At the moment, I'm currently aiming for getting all the initial engine setup sorted out, and playing back the animation sequence for when you get the copy protection answer wrong. As I mentioned above, this will involve pulling some code from the old project to save time, but I'm also already doing a fair amount of refactoring and cleanup, such as changing char *'s to Common::String, using Common::Point's, properly commenting the code, and so on. Given the amount of previous work done on the old M4 engine and the mostly complete disassembly I had of Rex Nebular, we can hopefully expect rapid progress in functionality, and eventually enjoy Rex's escapdes as he quests for the vase he's been sent to find.

Thanksgiving with a Ring.

"They said it would it would never be done. They were wrong." After a slight hiatus at the start of the year, work has finally finished on our next TsAGE game, Return to Ringworld. The only remaining work still in progress is a card game available on the in-game consoles, and is completely unrelated to the main story.

This is a direct sequel to the original Ringworld game.. after saving the puppeteer race from extermination and uncovering some powerful ancient technology on the first game, Quinn, Seeker of Vengeance and Miranda Rees find themselves searched for as fugitives by all three major species, so they plan to go to Ringworld to hide. But it turns that their ship has suffered problems. And fixing them and getting to Ringworld will only be the start of their problems..

The ScummVM Team is proud to announce that Return to Ringworld is now playable in ScummVM using the latest daily builds, and ready for testing. As usual, all bugs should be reported to our bug tracker following our bug submission guidelines. While you play through the game, we would also love it if you could take some screenshots for us.

Return to Ringworld code play-through complete

A great milestone has been reached with support of the Return to Ringworld game by the TsAGE engine. As of today, I've completed my first code play-through of the entire game! That is, my style of implementing games is to implement game scenes in the same order as the game is played. And although the savegame format has changed many times over the course of implementing the game, I've had a continuous savegame sequence for an entire play-through of the game.

The game is likely now completable, although given the number of changes that have been over time, it'll need further testing to ensure that the game has no newly introduced blocking bugs.

So what's the plan next? My initial play-through concentrated more on ensuring the actions needed to complete the game were working. I had a tendency to ignore miscellaneous actions that could be done in a scene, not to mention certain graphic glitches that occurred in some scenes, as well as some special effects and character shading that the game introduced that I hadn't implemented.

So now I plan to start working my way through the game again, doing further cleanup of the scenes code, and concentrating on ensuring each scene is graphically correct. And I may even put in some more options to skip some of the more annoying mini-games as well. :)

DreamMaster.

Hopkins FBI Linux completable

Another two weeks, and another milestone has been reached with the Hopkins FBI engine. The first play-through of the full Linux game has now been completed! All the blocking bugs have been resolved, and I've been able to finish the game.

That's not to say there aren't still some various graphical errors and things that still need to be tackled. Only just last night, for example, I fixed a particularly nasty series of graphical glitches with a lift scene that turned out to be a simple case of not clearing a flag when the animation manager class is created. So much grief trying to track down what looked like massive frame refresh issues or bugs in the animation player code. Thank goodness I was able to play the original inside gdb and easily set breakpoints to find out what values were set in the screen buffers, and when.

One of the biggest remaining graphical issues occurs near the end of the game. I'm not going to spoil anything, but you end up controlling multiple characters. There are currently issues with the icons for changing character not appearing all the time and, likewise, the chacters not always appearing on screen when your player character is in the same scene as them. I'm likely going to look into fixing them next.

After that it will be time to begin a more detailed play through to see if any noticeable differences can be seen between the original running in Linux against our game engine.. identifying and fixing any remaining minor issues as they occur. There may even be some further chance to fix issues in the original. For example, certain special scenes when you can access your inventory via the icon in the top left corner, the original doesn't let you use the 'I' key like you can in most other scenes in the game. That particular problem made me think there was something wrong with the ScummVM engine, before I realised you couldn't do it in the original, either. :)

Apart from that, we still need to start looking into supporting the PC version, since it's a lot more common than the Linux version. Hopefully we can get the sound decoder issues sorted out, and start testing that version in earnest as well.

Speaking of the PC version, I've mentioned previously that whilst I had the game, I'd never previously gotten around to playing it. And playing it now as the ScummVM engine was developed, how bizarre I found the game. What starts as what seems to be a straightforward cop-style investigation game rapidly becomes more and more bizarre. That was brought home when I was watching a play through of the PC version from Youtube, which I was using to check how the graphics are meant to look. It seems like the original PC version, in an underwater base you have to explore, they grafted on a clone of Wolfenstein 3D!

That's right. Whereas in the Linux version you are just shown a map and can select from various destinations, it looks like the PC version forces the player into a first person shooter and makes them battle their way from area to area. I've gotta say that whilst overall the game is fairly good, it's no longer just merely weird.. it's down-right freaky. :) Needless to say, there's every likelihood that we won't be implementing it. We'll likely just use the existing Linux version code, and provide a similiar map image as the Linux version.

And of course, there'll still be various cleanups to do. There's various memory leaks identified by Valgrind that we'll need to look into. And there's also general code cleanup, which both Strangerke and myself have made somewhat of a start on.

DreamMaster.

Hopkins FBI is WAVing

Another two weeks have gone by, and we've seen further development in the Hopkins FBI engine. The first is that the entire sound system is now implemented. In fact, the bulk of it was implemented in only a single day. Despite my concerns to the contrary, the implementation of sound in the game was extremely simple.. everything is implemented as WAV files, even the music.

Which made it  very easy to code for, since I could use the existing ScummVM WAV audio stream class to implement the playback. Most of the complexity, in fact, came to setting up the necessary sound arrays and queing/status code that the game uses, rather than raw sound code itself . In fact, the game uses an interesting compression tactic for music playback.. it splits up a given music track into multiple different WAV files, and has an index of the order to play the set of fragments in, allowing it to repeat the same WAV file multiple times during the song playback.

So now sound is working, and you can hear all the music and in-game sounds just like in the original. :). The only minor downside is that it's revealed that the different versions of the demo and full game (Windows demo, and both Linux and PC full versions) use different sets of music files, at least for the initial introduction sequence and menu. So we're going to have to have different versions of the different start-up code.
 
This is what Strangerke is currently concentrating on. He's been able to obtain the Linux full game, and has just finished implementing all the remaining methods that it uses that the demo didn't have. He's now going to start working his way through the game to see if everything works. We'll likewise have to determine any changes for the Windows version in the near future as well.

As for me, I'll be doing some further playing around with the demo to identify any minor remaining issues and trying to fix them as I find them. And of course assisting Strangerke as necessary. Hopefully we'll soon have a completable full game with full sound support. ;)


DreamMaster.

Hopkins FBI Linux Demo is now completable

Well, another milestone has been reached in the development of the Hopkins engine. The Linux demo, upon which I've been basing the engine implementation, is now officially completable! Yes, you can now guide the intrepid FBI agent through the start of his case, and deal with a bank robbery. I think it's a considerable happy achievement, given how recently I started work on it, and how little time I've had available to spend on it, given work commitments,

So what comes next?

Well, there are still some graphic glitches to sort out. For example, implementing proper savegame thumbnails, and the cursor drawing of actively selected inventory objects isn't clearing itself correctly when the cursor moves. I'll be concentrating next on identifying the cause of these problems and resolving them, which hopefully shouldn't take long.

There is also a need for refactoring. Now that the engine has stabilised into a usable state, I need to start reviewing code and giving proper names to all the structures that currently have names like 'field2' and 'field4'. Likewise, method parameter values and locals will also need better names. I also need to review the current separation of code I've done into various manager classes and move methods more appropriate to different managers into their appropriate manager.

Those two are the immediate short-term goals. Once they're done, there are still the two big ones remaining:

Firstly, supporting the actual full game. Whilst the game does have some basic scripting mechanisms, the bulk of the code seems to be in a massive method called 'Traduction', at least in the demo. This method consists essentially of a massive switch statement that handles all the game logic. It'll be interesting to see if this is done the same way in the full game as well. Strangerke is currently looking for someone with a copy of the Linux version of the game, that we can use as a basis of comparing against the demo version to get the changes. Hopefully, the core engine will remain pretty much identical, and we can just drop in a full game 'Traduction' method to properly support the full game.

And secondly, of course, there's the old hairy chestnut of sound support. I'm hopeful that the music, voice, and sound effects are in a standard format and that, similiar to what was done in Tony (and other) engines, I can use existing ScummVM functionality for sound playback. I really don't relish an extended period trying to re-implement sound drivers for Hopkins, like I had to do for tSage.

So, all in all, we should hopefully soon have Hopkins in a fit state as yet another game playable under ScummVM. :)

Making progress in Hopkins

Well, the last few weeks have been very busy for me at work, and it looks like things will be getting even busier as we get towards the end of the year. Despite this, I've made rapid progress in converting over the disassembled source code. I've now reached a point where I've done an initial conversion/implementation of all the method relied on by the demo, with the exception of the sound routines, which I tend to leave to last, since large chunks can frequently be replaced by existing ScummVM playback code.

There is, however, a bunch of code left in the executable that isn't directly called. This is particularly noticeable due to the way I did the conversion - starting with the decompiled code, I converted the single main method, removing it from the decompiled source file,, then added it into the ScummVM project and created stubs for any sub-method that that method called. I then proceeded to gradually convert those stubbed methods, creating new stubs as necessary. That way, for each method I converted, I could ensure that the code correctly compiled before moving onto the next.

The result of this is that at the end of this process, I have a decompiled source file that still has a lot of code remaining in it, even ignoring all the sound methods that I haven't implemented. I haven't done any analysis of it yet, but I'm presuming that some of the code is related to the full game executable, and whatever compiler they used didn't actually remove it when the executable was required.

Since I've spent the last week cramming the conversion, I figure to leave the unused code alone for now, and return to working on running the code and fixing bugs in the result. I'll also start doing renaming of the data structures as I understand things better. I'm hoping that despite my haste in converting the methods over, I'll be be able to rapidly see some in-game results.

I'll try to make more frequent progress reports to make up for the previous absence of postings. :)