The ScummVM Team is pleased to announce ScummVM 1.4.1, a maintenance only release that fixes several bugs in 1.4.0.

The most notable changes in this release are:

• Support for the Beneath a Steel Sky Enhanced Soundtrack by James Woodcock
• Slight graphical improvement for the PlayStation version of Broken Sword 2
• Several bugfixes for Lands of Lore
• More logical sound settings for SCI games
• A fixed crash in the VGA version of Quest for Glory 1

The full list of changes can be found in the release notes and the release binaries for many platforms are located on our downloads page.

Enjoy!

Today it has been announced that the latest official stable build of ScummVM has been released, with it featuring full support for my Beneath A Steel Sky enhanced soundtrack as part of my ScummVM Music Enhancement Project.

For point and click adventure fans, ScummVM is the perfect software that enables you to experience many of the fantastic past games of the genre on your computer, console or portable device:

http://www.youtube.com/watch?v=ek0uvGtG7YY

ScummVM 1.4.1 has been named ‘Subwoofer Release’. The ScummVM team were asking on their IRC chatroom for suggestions and I couldn’t resist offering Subwoofer – for two reasons really… Firstly, subwoofer eludes to the fact that there is an element of music involved and secondly Beneath A Steel Sky abbreviated is BASS. I thought that was pretty clever…

The ScummVM Team is pleased to announce ScummVM 1.4.1, a maintenance only release that fixes several bugs in 1.4.0.

The most notable changes in this release are:

• Support for the Beneath a Steel Sky Enhanced Soundtrack by James Woodcock
• Slight graphical improvement for the PlayStation version of Broken Sword 2
• Several bugfixes for Lands of Lore
• More logical sound settings for SCI games
• A fixed crash in the VGA version of Quest for Glory 1

The full list of changes can be found in the release notes and the release binaries for many platforms are located on our downloads page.

Enjoy!

Wow, two months passed since the last post; real life took me some time (as this did – sounds great! -), but I’m now getting into development again.
Anyway, here’s the usual list of notable improvements (which are a lot):

• Residual was renamed to ResidualVM, to match up with ScummVM (and because residual.org was already taken ).
• We have a new site, www.residualvm.org, and the forum was moved there.
• Following the rename, we are now on #residualvm on freenode, and the code is at www.github.com/residualvm/residualvm.

• We have a New engine! Myst3 is now supported, thanks to the work by Bastien (aka bgK). All hail to him! (I’m not into it, so don’t be afraid if you don’t hear of updates of it from me)
• Remember the last post, where I explained how to fix a bug in Grim’s data? Well, you can forget that, since Andrea (aka YakBizzarro) added a hot-patching system. No need to fiddle the data anymore, now ResidualVM’s code does the magic all by itself. Along with that other bugs in the scripts have been fixed.
• Similar to the entry above, now the official 1.01 patch is loaded directly as a .exe. You don’t need to extract it anymore, it will be loaded by ResidualVM as-is.
• TinyGL (the software renderer) now supports any color-mode and color depth.

These are the main things, but around them there are a terrific number of littler improvements and bug fixes.

I took this graph from Ohloh. It shows the number of committers over time. You can clearly see the boost that happened recently, and that imho is the most notable improvement the project had.

Stay tuned!

Filed under: Residual Tagged: grim, myst3, rename, updates

As promised in my last post, I will now talk about eos.

“What is eos?”, I hear you ask. Well, in short, it’s an open source project I started to portably reimplement BioWare‘s 3D engines, starting with Neverwinter Night‘s Aurora engine. Quite a daring task, and one I can’t begin to hope to finish on my own, especially since I’m not really that versed in all that 3D stuff. But working on it is fun and scratches an itch, and maybe more people will join me in that particular quest some day.

Here’s a quick rundown on the current state of eos:

General

Working:

• “Engine” framework
• Global configuration subsystem
• Debug console with readline-like abilities
• Reading classes for a shockful of BioWare file formats, including archives, images, GFF formats
• Resource manager
• Basic manager classes for 3D graphics and sound
• Playing of Bink videos (decoder courtesy of the FFmpeg project)
• XMV demuxer (which we then reworked to fit into FFmpeg)

Missing:

• Animation subsystem
• 3D positional audio
• WMV p-frames

Neverwinter Nights

Working:

• Partially working main menu
• Loading of modules and areas, including placeables and creatures
• Moving around in areas
• Interacting with doors
• Talking to NPCs
• Script execution

Missing:

• Area lighting
• Most script functions
• Proper “segmented” models (each body part a separate model)
• PC, walking, combat, inventory, journal
• Script triggers

Knights of the Old Republic (1 + 2)

Working:

• Very stubby main menu
• Loading of areas, including placeables and creatures
• Moving around in areas
• Unswizzling Xbox textures

Missing:

• Interacting with objects, dialogs
• Scripts
• PC, walking, combat, inventory, journal
• Area lighting
• Proper materials, including metallic reflections

Jade Empire

Menu loading works partially, everything else is still missing.

Neverwinter Nights 2

Model loading works partially, everything else is still missing.

The Witcher

Model loading works partially, everything else is still missing.

Dragon Age: Origins

Texture loading works, everything else is still missing.

Sonic Chronicles: The Dark Brotherhood

HERF archive reading and texture loading works, everything else is missing.

Dragon Age 2

A potential target, but made difficult due to the changed archive format which doesn’t include file names anymore, only their hashes.

 

As can be seen, the current focus is mostly on Neverwinter Nights and Knights of the Old Republic, but even there, a lot is still missing and the games are of course far from being actually playable. I am mostly working alone on that project, with help from clone2727; chances of eos ever becoming usable are next to none this way.

If anyone out there is interested in helping, this would increase said chances and we’d be overjoyed. I’m especially looking for someone with actual OpenGL experience who could probably completely rewrite my graphics code to be far more effective. Of course, there’s a lot of other places that need capable hands. A quick and dirty TODO I’ve written a while ago can be found here. The project itself is located on github, here.

Well, it’s been a year since you’ve last heard from me, so I thought an update on what I’ve been doing is in order.
As this will be a tad longer, I’ll do that in two parts: This here first post will cover ScummVM-related things, while the next post will talk about eos (which you might not have heard about yet).

So, without further ado, let’s dive right into ScummVM with…

Urban Runner

Since my last post on Urban Runner, a lot has happened: The hotel lock-up has been fixed (thanks to SylvianTV), saving has been implemented and a handful of glitches has been stomped. As of ScummVM 1.3.0 (May 28, 2011), Urban Runner is fully working and supported.

If you watch the video, you can see one tiny remaining glitch: A few video frames are corrupt, filling the screen with garbage. Unfortunately, this is not exactly a bug in ScummVM, but the videos in the data files are really broken. When taking the raw Indeo3′d video data from these frames and decoding that using a vanilla Indeo3 decoder, it displays as garbage too. However, the decoder the game uses somehow “detects” where the frames are broken and just stop decoding that frame. If you run the original Urban Runner EXE, you can actually see that happening when the background noise stops moving for that one frame. So far, we have been unable to duplicate that detection so that it works for all cases and doesn’t break anything.

Another problem that showed later was that saving and loading didn’t work on the PSP. After investigating the issue, we found the cause: the number of file handles on the PSP is severely limited. Since I’m opening all manually open all archive files on startup — the CD detection script doesn’t work when all data files are in one directory and the NO_CD mode requires all data files to be present in CD1.ITK — this already maxed out the available file handles. Luckily, I was able to resolve that by not manually opening CD1.ITK; the scripts already open it, but I, wrongly, feared they might try to close and reopen it.

Adibou

After Urban Runner was working, I started investigating the script opcodes needed for the Adi and Adibou (Addy and Addy Junior in German) educational games. Among them are opcodes to read string and integer values out of INI and xBase database files, for which I wrote quick loader classes. After a few days, I managed to get the environment CDs (which ship with each game to serve as a hub to start the individual lessons and provide some quick games to play in between) partially playable. With a lot of glitches, of course.

Most noticeable are the missing animations, but that’s far from being everything that’s missing.
Please note that it also only includes second generation Adibou games. Third generation ones are still completely unplayable (and actually use a different scripting language altogether, so support is questionable at best). And fourth and later generations are not even Gob, so completely out of scope for this ScummVM engine.

Geisha

The next Coktel Vision game I’ve turned to is Geisha, an erotic puzzle adventure (or rather, a lot of puzzles embedded into a thin layer of adventuring). Under the hood, it’s very similar to Fascination, so it seemed like a low hanging fruit to finish. In fact, it is now already completable in ScummVM. The only thing missing is two hardcoded minigames, Diving and Penetration. I also already implemented about half of Diving; Penetration, however, is still completely unimplemented.

Still missing as well is a player for the AdLib music format MDY/TBR (the former containing the track, the latter the instrument definitions). Like in Fascination, there is exactly one MDY track in Geisha, the title music. And like in Fascination, there is a PCM-based alternative, which is normally played when there is no AdLib compatible sound card, and on the Atari ST. Right now, ScummVM always plays that alternative in both games, but it would be nice to have the AdLib music working too. Strangerke already started writing an MDY player, but it’s currently still not working properly.

Being an erotic adventure, it does feature full nudity. I’d like to keep this blog somewhat family-friendly, so I’m not embedding any videos or screenshots.

Dark Seed II

One game I did not make any real progress on is Dark Seed II. The scripts seem to work somehow differently to how I thought they would. Right now, they lock up in at least two places early on: when talking to the fortune teller and when entering the mirror labyrinth (both located on the carnival grounds). Moreover, I can’t seem to understand the numerical parameters accompanying a lot of the opcodes, and I’m not sure about the evaluation order of the different functions.

Likewise, the walking code is still wrong, as I can’t find the correct ways to evaluate the walkmap scaling parameter, and the character scaling factor. The algorithm I use is also probably not the optimal one for the provided walkmaps.

Nearly all the code (except the archive decompression) I have written is not based on reverse engineering, but educated guesses, and in those cases, I apparently guessed wrong and am not “educated” enough to guess correctly. To fix this, I will have to actually reverse the binary.

As an interesting side note, we found out that there is a Japanese Sega Saturn version of Dark Seed II. The archives are organized a bit differently, and the movies are Cinepak instead of MSVideo1 and Indeo3, but adding support for the former was easy and clone2727 already had a decoder for the latter, so the state of the version in ScummVM is similar to the DOS versions. The only missing features are proper line wrapping according to Japanese grammar rules (instead of just allowing wrapping after each character), the different dialog interface (the Japanese version plays more like a Japanese graphical novel) and the Saturn-specific music format. If anyone has any information on that music format, I’d be very much interested.

Update: Thanks to peres for informing me that the last character in each line was wrong (I can’t read Japanese, so I hadn’t noticed). It turned out to be a bug in my line trimming functions and is now fixed. The screenshot above has been changed to reflex the fix. For comparison, here’s the broken version.

Conclusion

2011 was a bit of a slow year for me when it comes to ScummVM. I fixed a few bugs, started a few things, but didn’t really finish anything (except for Urban Runner, but the lion’s share there was done in 2010).
I’ll talk more about what I’ve done in the other big project I was involved in in the next post.

No, not that force, it's Blue Force. Jake Ryan has just graduated from the Policy Academy, and it's up to you to guide his actions as he starts his police career. He'll quickly become involved in solving a series of crimes which, unbeknownst to him, are inextricably entwined with the murder of his parents when he was a child.

The ScummVM Team is proud to announce that Blue Force 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.

Well, hello there. Been a few months since I posted here. Figured I'd post about something, y'know.

Had a busy summer... busy fall too. Played a few games recently, including one classic game -- The Journeyman Project: Pegasus Prime. Let's reminisce a bit (WARNING: Contains spoilers; just skip to the very bottom for the good stuff).


The essential title screen; usually in most games. Let's move onto gameplay.


We should probably wake up, and not be late for work.


Too late! The commissioner doesn't look too happy. Also, bad temporal rip incoming and whatnot.


Time to go recover that log and not jump off the cliff though!


Avoid dinosaurs too, always good. Let's go to Mars instead.


Watch out! (Aside: For fun, you can try to attack this guy with any inventory item -- I bet you didn't know that!)


Freeze the lock, let's take a look at that bomb. Don't just pry it out though! Now, let's get out of here.


The maze isn't the same without the original music, but it's still enjoyable. Let's go catch that robot!


Bang bang! Pew pew! Now, tractor her in and board her!


Need to stop a robot down under too.


Being under the sea more to your liking? This guy doesn't seem to think you're much of a match for him, though. Probably should stay out of his way or maybe crush him or something.


I hope you don't need a map to solve this one.


Watch out! Robot on the loose!


Who needs lockpicks? Let's just blow the door open.


Why are there no tasers in the future?


How come James Bond never had to go through this level of difficulty when diffusing a bomb?


Mission Accomplished!


















Well, that was a fun little aside don't you think! Talking about a classic adventure game randomly, just like that. Or was it really random? Maybe there's something common about those screenshots; no, not just in PNG format. They're all taken from within ScummVM. Yeah, you heard correctly. This is definitely happening, and I'll hopefully be done fairly soon. Ah, now you see what I'm getting at? There's still some graphical glitches with the videos, but it's in very good shape overall.

Oh and it's even completable.

More updates to come soon (And no, this code isn't on my github account yet, but will be soon).

And, of course, much thanks to Presto Studios for making all this possible and providing the original source code!

Take a little break and compose yourself. After tireless weeks of work, the ScummVM team is proud to announce support for two children's adventure games — Gregory and the Hot Air Balloon and Darby the Dragon — And on top of that, you can also play some interactive books from the Magic Tales series. So, if you can find your childhood spirit, dig out your copies and enjoy those adorable games.

To play these, you'll need a daily build of ScummVM. Any lurking bugs you find should be reported using our bug tracker, and along the way, please consider making few screenshots, following our guidelines.

We are also looking for additional information on localised versions and Magic Tales books. If you have one which is not recognized by the latest ScummVM daily build, please follow the guidelines here and report this to the team or as a bug.

Have fun!

Today I am happy to report that my enhanced soundtrack for Touché: The Adventures of the Fifth Musketeer is now 95% complete as part of my ScummVM Music Enhancement Project.

I am hoping that in early 2012, you will see my enhanced soundtrack working within ScummVM – however until that day arrives here are a few tracks to enjoy…

Touché: The Adventures of the Fifth Musketeer Preview Samples

Below are three samples from the entire soundtrack that I haven enhanced:

• Track 01
• Track 13
• Track 16

As always a big thank you goes to the original composer of the soundtrack that featured in the game, in this case Ben Daglish.

Just finished enhancing the music to Touché: The Adventures of the Fifth Musketeer, examples here bit.ly/sQXkky Release early 2012!

— James Woodcock (@JamesWoodcock) December 14, 2011

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.

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.

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).

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 :)

Today I have updated my Simon the Sorcerer enhanced soundtrack for use within ScummVM. The second song (track02.ogg) had a single note that was out of place, which has now been fixed in this latest release.

To download the updated soundtrack, click the link below:
> Simon the Sorcerer Enhanced Music Version 2.1

More than a month has passed since the last (and first) entry of this series. I’ve been a little busy with other things, but that doesn’t mean Residual development was paused.
First of all, two new contributors stepped in to help the development:

• DarthJDG added antialiasing support. Add to your Residual config file the line antialiasing=$samples, with $samples equal to 0 (that is, no antialiasing), 2, 4, or whatever your graphics card supports, and enjoy the improved and smooth graphics!
• juj worked hard on the bugs 31 and 247, regarding wrong head orientations, and made a pull request that fixes them. It is not in master yet, since there are some things to improve first, but the main code is there!

Aside the usual bugfixing in the Residual code I looked into a bug in the game scripts, a bug that existed since the Release in 1998 and that even Tim Schafer didn’t know of! This bug prevent(ed) a critical dialog with Domino at the end of the world to play, a dialog that explains the main plot!
I’ve explained what’s the problem behind the bug in the forum, with a possible fix. However, somaen recently added in Residual the support for a new lab file, called datausr.lab, which takes precendence over the others. This allows for a better fix, not needing anymore to replace data000.lab. These are the needed steps:

1. Compile the tools mklab, delua and unlab from residual-tools;
2. Unlab data000.lab to a directory and delua the file dlg_dom2.lua;
3. Copy the “deluaed” file to a new directory datausr, keeping its name dlg_dom2.lua;
4. Modify its first line to CheckFirstTime(“dlg_dom2.lua”);
5. Create datausr.lab from the directory using mklab and put it where you have the other lab files;

Now when you run Grim you should see a dialog like this:
Now click OK and you’re up and ready to hear from Dom’s words his evil plans

Filed under: Residual

Beneath A Steel Sky has been playable through the ScummVM software for many years and I am pleased to announce that version 1.0 of my enhanced soundtrack is now available for you to use within the game, which will give everyone superior sounding music and not just those with powerful MIDI equipment.

A big thank you for the countless emails and tweets I have had about this particular release and of course to the ScummVM team for implementing the external audio files I have created – allowing my enhancements to be released for your enjoyment.

To install, extract the music from the zip file and copy it to your Beneath A Steel Sky folder on your hard drive. Make sure you have the latest daily build of ScummVM from their website or version 1.4.1 or later (when it is released). For best quality (although not mandatory), start the ScummVM program and select Beneath A Steel Sky. Now select [Edit Game], switch to Audio tab, tick the ‘Overide Global Audio Settings’ and set Sample Rate to 44kHz.

http://www.youtube.com/watch?v=ek0uvGtG7YY

If you enjoy my enhancements, please consider donating.

To download the soundtrack, click the link below:

• High Quality – OGG Vorbis – Stereo (37MB)
  Beneath A Steel Sky – Full Soundtrack Version 1.0 (14th November, 2011) (1955 hits)
• Low Quality – OGG Vorbis – Mono (13MB)
  Beneath A Steel Sky – Full Soundtrack Version 1.0 (26th November, 2011) (88 hits)

Webmasters: Please do not link to the files directly, instead link to this page!

You can also legally download Beneath A Steel Sky both floppy (with subtitles only) and CD-ROM (with speech) from the ScummVM website.

Since our last update, there has been a quite a bit of development, 340 bugs have been fixed in our issue-tracker, and although quite a few still remain, development continues. Those interested in a bit more detail, can take a look at giucam's blog

One of the more interesting bugs found and solved, was the one about missing dialogue in Year 3, which actually was as old as the original game.

On another note, our forums has had an interesting turn of events, quite a few of the members have joined together to work on improving the original graphics of the game in a project called Grim Fandango: Remastered JohnnyWalker2001 has set up a blog where updates on this effort are posted.

Grim Fandango support still remains in active development, and a little bit of work has been done on Escape From Monkey Island. Now you can atleast play the intro video in the demo. Still, no promises on the EFMI improving any more any time soon.

As always, any contribution is greatly appreciated. If you wish to help, we can be contacted on #residual (freenode), or in our forums.

The residual-tools repository was born on April, 7th this year. From the very first moment I felt its build system was broken, mainly for these three reasons:

1. to build a specific tool you must run “make tools/foo”. The repo is called residual-tools, there should be no need to specify “tools” in the make call too;
2. there isn’t a single line of Makefile code shared between the different tool targets;
3. each submodule of tools/, like tools/lua/module.mk, needs to be added in Makefile.common. I’d like a way to set it up into tools/module.mk, with a parent-child relationship.

So some days ago I decided to try to improve it a bit, even though I never wrote a single line of a Makefile.

My first try was to work on rules.mk: I modified a bit the code that created a target from the value of TOOL_EXECUTABLE and of some other variables. After some trial and error I came up with a piece of code that allowed me to put in tools/module.mk, for each tool, something like this:

TOOL_EXECUTABLE := unlab
MODULE_OBJS := unlab.o
include $(srcdir)/rules.mk

TOOL_EXECUTABLE := vima
MODULE_OBJS := vima.o
include $(srcdir)/rules.mk

....

Quite ugly, but still better than before.

Then I started working on 3. Long story short, I couldn’t come up with an acceptable solution.

Then an heretic thought passed through my mind: CMake!
I really like the add_executable and add_subdirectory functions of CMake, but I know that porting to CMake would require a big effort, since it doesn’t work out of the box on all the platform configure currently supports.
So I started thinking: configure works perfectly, I just need a way to confortably generate a bit of Makefile code. configure is an sh script, why not just use sh?

So I wrote a script, makegen, with the functions add_executable and add_subdirectory.

add_subdirectory() {
    MODULE="$MODULE/$1"
    . $srcdir/$MODULE/module.mg
    MODULE="${MODULE%/$1}"
}

add_executable() {
    echo -n "$1_SOURCES := " >> $builddir/Makefile.modules
    for f in $2; do
        echo -n "$MODULE/$f " >> $builddir/Makefile.modules
    done
    echo >> $builddir/Makefile.modules

    echo -e \
"build: $1
$1_DIRS := \$(sort \$(dir \$($1_SOURCES)))
$1_dirs:
    \$(QUIET)\$(MKDIR) \$($1_DIRS)
$1: $1_dirs \$($1_SOURCES)
    \$(QUIET)\$(MKDIR) \$(DEPDIR)
    \$(QUIET_CXX)\$(CXX) \$(LDFLAGS) $3 \$(DEFINES) -I. -I\$(srcdir) \
    \$(filter %.cpp %.o, $+) -o \$@\$(EXEEXT)
EXECUTABLES += $1\$(EXEEXT)
clean: clean/$1
clean/$1:
    \$(QUIET)\$(RM) \$($1_SOURCES) $1
    \$(RMDIR) \$($1_DIRS) \n" >> $builddir/Makefile.modules
}

This script is called from configure and it does simply generate a file Makefile.modules with the targets for the tools.

Now, adding a new tool is simply a matter of adding in tools/module.mg

add_executable toolname "toolname.o foo.o bar.o"

You’ll then be able to call make toolname.

This is not finished and still experimental, and I can’t know if it will ever be actually used, but I would like to hear some thoughts.

Filed under: Residual

Yesterday I was chatting with Md5 about the recent progress in Blue Force, and I thought to myself that I should make a blog posting. Looking back, it seems it was June when I made the previously posting. I hadn't realised that it was that long.

As those of who frequent the IRC channel or forums would be aware, Ringworld was completed, and will be part of the upcoming official 1.4 release. We'd already had a successful testing period, with several bugs identified and fixed. It'll be nice to see another game I've worked on added to the trunk and become officially supported.

Now, onto more recent developments. As of yesterday, Strangerke and I have reached two more milestones in the progress of the TsAGE engine.

The first is that I completed the first complete play-through of Blue Force. This had been a gradual process over the last few weeks, as we identified game stopping bugs and fixed them. The save format also changed several times during this period, as we implemented the final few game scenes, and added missing game state variables. Yes, clone2727, the game is completable. So nyaaa. :)

The next step will be for us to start playing the game again from the beginning, comparing it against the original and looking for any minor graphics glitches or problems that we missed. We will also ensure that none of the fixes done for the later game scenes had any adverse effect on the earlier scenes. This includes a variety of minor issues that we identified during the first play through, but were deemed too minor to immediately worry about.

One of the more amusing glitches I came across was a scene in day 2 of Blue Force where a police inspection is done. This particular scene seems to use animation sprites different from anywhere else in both Blue Force and Ringworld. Likely some as yet un-handled flag or sprite offset - the result being that all the officers get drawn with their bodies on top of their head. Picture if you will headless officers walking around balancing on their own heads. :)


The second milestone is the commit of the beginnings of the ‘Return to Ringworld’ game - the third and final 2-D TsAGE adventure. I’d previously spent some time on the side starting to look at a disassembly of the game, and identifying all the common engine functions against my disassemblies of Ringworld and Blue Force, and got to the point where all the core functionality had been identified. I started on adding the game classes about a week ago, and have got to the point where I can at least display the first in-game scene.

I had been holding off on committing this to trunk until after the branch, since it affects a lot of the files, but now the 1.4 branch has been done. It also invalidates the current Blue Force savegame format (but not RIngworld) - since both of them share mostly the same UI code, it made sense to encapsulate it in a common base class. Given that Blue Force isn't official yet, it was easier to break the existing savegame format for it as part of this, then to try and maintain the savegames intact. So it was good that I’ve now completed the first play through of Blue Force, and can start from the beginning of the game again.


I have a tendency, for games I plan to work on disassembling, not to play them through using the original executables. That way I can have the fun of gradually playing through the game as I implement the code for it in ScummVM, and get the enjoyment from playing it for the first time in code that I’ve written. It also serves as an inducement to work hard, so I can see what happens in the game. I’m eager to see what happens to Quinn, Miranda, and Seeker in their second foray to the Ringworld.

Once we've cleaned up the Blue Force code-base a bit more, then work on Return to Ringworld will begin in earnest. Hopefully there won't be too many core engine changes, and work can proceed on it as rapidly as was done for Blue Force.

On a final note, for those of you wondering about Rex Nebular, I did start to return to looking at it, but I've been away from working on it in earnest for too long. There are still parts of the game not yet dis-assembled, and I'd need time to complete that and re-familiarise with the existing code. So it really needs some time when I'm not actively working on some other game. I'll have to see how I do when the TsAGE games are complete.

There hasn’t been a lot of visible changes since the last status update, but a couple of small graphic problems have been fixed:

• Alpha transparency drawing is implemented (resulting in correct drawing of ok/cancel buttons)
• Default menu cursors are now shown properly
• Dialog box messages with no message type are displayed properly
• Button highlights are drawn in the correct order (Common::sort is unstable, resulting in an incorrect drawing order when images have the same priority)

Behind the scenes though, a lot has been done: most of the Pompeii game logic is now implemented, along with proper timer handling and there has been some work done on movies, sound and the 360° view.

This is the first installment of a periodic (I don’t know the frequency yet, could be weekly or monthly, or a mixture) series on what happens around Residual.

First of all, if you don’t know it already, there has been some ferment recently around a project born on the forums aimed at improving the graphics quality of Grim Fandango, both improving texture quality, models and even making Grim widescreen!
You can read more about this on Johnny’s blog.

As regards the code, Einar (aka somaen) refactored the Smush code, making it more clean and maintainable. I finally implemented collision handling between actors when walking to a point. No more Manny walking through the signpost or Velasco or Glottis! Another worthy point, the savegame format changed, so if you had some saves made before the 3rd, say bye bye to them.
(Or don’t update Residual.)

That’s it for now, stay tuned for the next updates!

Filed under: Residual

Just a quick update to say that several graphic problems have been fixed since the last status update:

• Most images are no longer drawn at wrong coordinates (for example the dialog boxes or some screen elements in the preferences)
• The first line of images is now being drawn properly (fixing corruption that appeared in some cases)
• Some 32bpp images are now shown properly (it converts them from 32bpp to 16bpp on the fly until we get full support for 32bpp screen surfaces), but with graphics problems when the game is expecting alpha transparency
• Image cursors are shown with the correct coordinates/colors (downsampling from 32bpp to 16bpp here too)
• Highlights now work on menu entries and dialog options
• AND the decompression problem has been fixed (by a single line change…) !

I’ve recently spent some time on the asylum engine, implementing the missing logic and display code and fixing problems in the already implemented code.

The logic and actor code is now almost complete and most of the puzzle-specific code has been implemented.

Quite a bit of time has been spent on the drawing code and Max is now drawn with the correct priority. Masked blit has also been implemented, although it is still very buggy (as can be seen on the screenshot). Palette fading is present now (with some small bugs left to fix), making transitions from the menu to a new scene or a movie a lot nicer.

We also tracked down several major bugs, making the text drawing orders of magnitude faster and finally allowing Max to leave his cell. Alexander (midstream) and Alex (alexbevi) contributed quite a bit (implementing almost all the functionality for the missing puzzles and debugging and fixing several problems).

I’m going to be back on Ring for a bit, but the amount of work needed to put the engine in a mergeable state is now a lot less.

Since the first commit at the end of January 2011, the ring engine has come a long way. Most of the shared engine code for Ring and Faust has been implemented, along with the whole logic for Ring and a sizable chunk of logic for Faust.

The main game view (the 360° view) is not yet implemented, but there is enough display code present to show the game menu in Ring (as well as several submenus). As you can see in the screenshot, there is some image corruption present, due to problems with the image decompression.

And that brings us to the compression algorithms used by the engine: one thing is clear, the original developers loved coming up with new compression types (I’m thinking there was a bet on how many such algorithms they could fit in a single engine). BMP, TGA, WAV (compressed as a whole or streamed), CNM (movies), AQC (360° view data) each use a different variation of the algorithm (with a large amount of duplicated code of course of course, it wouldn’t be fun otherwise!).

And for the next games in the series, they decided to share a single compression format for all images in archives. So in addition to the old compression formats from Ring, Faust introduces a new format, also used for movies…

The new compression code also uses floating point, which makes it quite a bit harder to reverse-engineer. And since most images are inside archives, Faust and the following games are not displaying anything yet.

I’m currently working on implementing the new set of “widgets” used by Pompei and Jerusalem. It includes a dialog selection widget (mostly done) and a hyperlinked encyclopedia (only started reverse-engineering in IDA).

Most interested people will have realised that my ScummVM backends (GP2X, Wiz, Caanoo and OpenPandora) missed the entire 1.3.* release cycle leaving the official releases stuck back in the old 1.2.* cycle.

There are a number of reasons for this (all my fault) but rather than dwell, lets just say I am trying to get them all back into shape for future releases. With that in mind I am going to start doing test ‘point in time’ builds of the code for various devices when things reach a point that I would like some community testing done.

The first of these test releases is for the GP2XWiz and Caanoo. The GP2X build will follow once I nail the last annoying little input bug that is causing the cursor to go off for a wonder on it’s own (simple bug I am sure but you know how it is when you stare at something). Then I will turn to fixing up the OpenPandora backend.

They have been built from the main ScummVM GIT (Revision:  6b8fb196cbd58e20ef57bf367d5ecbf0ee2ebdad).

These builds exist purely to get some feedback and testing from the community so I can try and get a good solid release done when we get into the next official ScummVM release cycle.

If your not interested in testing and providing feedback (and dealing with the odd issue) please stick with the old 1.2.* releases. These are not robust, fully tested release builds but I am also pretty sure they will not eat or damage your GPH device.

Note: Please don’t mirror or hotlink these preview/test/alpha etc. releases or put them on download services but rather, direct people to this page.

This helps me ensure that users always have the most recent versions and cuts down on me being requested to support ancient releases.

Also note that these test releases are not officially (or unofficially) supported .

They are built from the new unified ScummVM backend for all the GPH devices (to make supporting them somewhat easier for me and to cut out the rot that had set into the old dedicated stand alone GP2X backend).

All the engines enabled in configure are included in this build but I make no promises about the usability of any WIP game engine.

Specific restrictions:

GP2XWiz: My GP2XWiz has died so this build is totally untested but before the Wiz died the builds had been working well and there is so much in common with the Caanoo that I am fairly sure this build will work. Please test it and give me some feedback.

If you selling a Wiz cheap I also want to talk to you .

Caanoo: The build seems fairly solid. If you find issues please report them.

Providing feedback:

If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in official places.

• Bug Reports (ScummVM’s Sourceforge bug tracker)
• Feature Requests (ScummVM’s Sourceforge feature tracker)
  • Source Code Patches (ScummVM’s Sourceforge patch tracker or  github pull request)
  • General Forum Feedback (ScummVM’s GPH Devices forum) – I also check Comments on these posts.

Downloads:

Please ensure you download the correct version for your device:

• GP2XWiz: download
• Caanoo: download

Extract the contents of the zip to the game folder on your SD card, ensuring that you have a “scummvm.ini” in your game folder and the rest of ScummVM in a “scummvm” subfolder.

Launch “ScummVM” from the main launcher menu to run.

Review the README-GPH for more information.

Regards,

John

Another week pass, with a lot of breaking and fixing. The good part is, I am really getting used to this.