Month: June 2008

Nothing especially interesting to report lately. I’m still working on the sound and file implementations, and hoping to have them done by the end of this week. Spent a while today trying to figure out how to create a wrapper for Scumm’s write drivers that mimicked fprintf, so that I could simply find-replace away some of the fprintf calls in the FreeSCI source. Eventually discovered the vsprintf/vfprintf functions, which made things a lot easier.

Then we move on to dealing with configuration.

I’ve started uploading some of the my code to a darcs repository.

I ordered a few games to test things with. In the meantime, I’ve been using the Space Quest III Astrochicken demo to test the basic sound code. This means I’ve spent a lot of the past week listening to chickeny music, puncuated by the occasional explosion.

Wikipedia’s article on “Astro Chicken” begins thusly :
This article is about the hypothetical self-replicating spacecraft concept. For the side game from Space Quest III, see Astro Chicken.

So we do that, and learn the following:

In the fictional storyline of SQ III, the Two Guys from Andromeda were enslaved by ScumSoft. ScumSoft, in the game, is an evil software company, maybe partly inspired by SunSoft^{[citation needed]}, but also the Lucas Arts adventure games (the engine was called SCUMM)^{[citation needed]} and Microsoft (some claim Elmo Pug was a caricature of Bill Gates^{[citation needed]}). At ScumSoft HQ, they were forced to create games such as Astro Chicken.

So that’s kind of ironic.

Adlib driver seems to be working pretty well now, so we just need to modify the open() callback for each of the sound card/patch formats.

Here’s a diagram jvprat made. It shows the basic flow of MIDI info:

I picked FreeSCI’s file handling as an initial target because it looked like it would be fairly straightforward: replace anything in the FreeSCI code that used file IO with invocations of the ScummVM file and savegame classes. In the process, it would be possible to get used to the ScummVM and FreeSCI source code, making future tasks easier.

This gets complicated when one adds the additional goal of keeping the source code as close to the FreeSCI main branch as possible. Simply going through and replacing anything with a FILE* near it results in a lot of changed source code. This means that incorporating any future changes to the FreeSCI main branch into our code will be a bit of a pain.

One option is to build an abstraction layer into FreeSCI; this layer would encapsulate both the FILE* implementation and the use of ScummVM classes, so that one could choose between them. This is similar to the approach that FreeSCI’s graphics code uses to allow for different means of outputting graphics. An alternative is to keep copies of the relevant files and pick which one we want at compile time, depending on whether we’re compiling as a standalone copy of FreeSCI or a ScummVM engine.

Either way it involves a change to the FreeSCI base, so we’ve been getting feedback from other developers. Until it gets sorted out, I’m devoting some attention to the sound output.