More seriously, the good news came very recently: in less than two weeks, with the impressive help of SylvainTV, all the versions of Fascination became playable and completable, or at least all the ones I possess.

The main thing missing currently, only used by PC versions of the game, is the AdLib player (and IMHO, the SoundBlaster sounds a lot better). There’s a wrong delay (too short) between rooms in several places of most versions. This seems to be caused by the delay required at the time to load from the floppies, and it’s easily patchable.

Last detail, the (rare) CD version still requires a tool for the STK extraction. joostp is cleaning it up, and will commit it when it’ll be in a good state.

Maybe it’s a good time now to grab your originals and send us some feedback on the game, specially if you find some of those too short delays!

Here are some screenshots of the CD version.

Stay tuned for further news! I promise I’ll try to give some before this summer

The problem was, of course, my own damn fault; I misunderstood the nature of cursor resources. They’re not, as I assumed, plain cursors, one by one each taking up a resource entry. Instead, there are cursor groups, each capable of possessing a variable amount of cursor images. That isn’t even a quirk of NE files, it’s like that in PE files as we well, so my complaining about the executables being in that old format doesn’t apply either. Mea culpa.

In Dark Seed II, the cursors are embedded into the resource part of the Windows 3.x (NE, “New Executable”) executable dark0001.exe. Specs are available on the Microsoft website, but they don’t quite match the executable, which claims that each cursor is only 32 byte big.

I did manage to extract the cursors in the end, with the help of the great tool “Multi Ripper” (a project that sadly appears to be dead). But when I then began to look for the resulting cursors in the Dark Seed executable, I couldn’t find them there, at least not directly: The headers are, only partly though, in the resource table, where you would expect them. However, the cursors’ data are at a completely different place, a place that I couldn’t construct with any of the offsets I read from the various tables. So I am completely at a loss.

Running Multi Ripper through a disassembler didn’t really help either, since it’s either deliberately obfuscated, or just completely unreadable due to it being written mostly in Clipper (yeah o_O). The link to a wine resource compiler Fingolfin send me didn’t help either (thanks again for looking, though); that compiler agrees with neither the specs, nor with the executable.

Since I was able to at least extract the cursors, I did what I had to do: hard-code the cursor data. So right now, the Dark Seed II engine comes with about 10kb of static cursor data. Not much of a problem, but certainly not as “nice” and clean as I’d like.

Well, if any of you happens to know a thing or two about resource tables in New Executables, please, pipe in and tell me what I did horribly wrong.

So, what have I been doing the past months? Apart from some RL stuff I’d rather not talk about, and playing Dominion (seriously, check that out, it’s really great), I didn’t do much concerning gob. Sorry. Instead, I started a new ScummVM engine, for Dark Seed II.

For those of you not familiar with Dark Seed II, it’s a fun (in my eyes, at least ) little horror-ish adventure game, using graphics by the great H. R. Giger. In fact, it’s been one of my favourite adventures, despite some flaws, and I always wanted ScummVM to run it .

So, one day, 1.5 months ago, I, just for the heck of it, looked at the files on my Dark Seed II CD: The videos were immediately apparent to be standard AVIs, using MSVideo1, MSRLE and Indeo3 codecs, the music standard MIDIs. No problems on that front. There were some other files, following the name convention “gl00*.000″ that looked suspiciously like resource archives. So I checked gl00__da.000 with an hexeditor:

Now, that looked rather simple. This looks like a file name:

This number, read as a little-endian 16bit value, correspondents with the number of visible file names at the start of the file:

Since the files in this archives are apparently WAVs, I expected to find fitting magic bytes:

And the offset within the file fits with one of the numbers at the beginning of the file:

A quick calculation showed that the other number is apparently the size of the resource file within the archive.
It seems that I managed to guess the archive format in a few minutes. Nice . I hacked together an extractor and it actually worked, giving me loads of standard WAV files, the dialog lines.

Extracting gl00_sys.000 yielded a file OBJ_9999.DAT, which looked like a game script for the inventory objects in plain text. That came as quite a surprise. However, it would make a possible reimplementation a lot easier.

One problem crept up, though: Some archives files didn’t fit with my guessed format. For example, gl00_001.000:

A sole file name was readable, then some garbage. Might be a compression. Some digging in the disassembled executable and I had that down too. And what I saw made me hopeful: Script and conversations are really plain text, images BMPs (+ WAVs, MIDs and AVIs for sound, music and videos).
After thinking about it for a bit, I decided to implement a ScummVM engine .

As I went along, the engine began taking form:

In the current state, the game is already basically playable, with the following caveats:

• No pathfinding
• No walking, Mike teleports
• Several unimplemented special variables, like SysRandom
• Some script lock-ups in the carnival
• Siamese twins conversation doesn’t start (some unknown command)
• No saving/loading yet
• Graphical glitches:
  • Wrong drawing order
  • Sprite clear/stay
  • Animation speed
  • Unimplemented scaling

Also, there’s still an inconvenience with the cursor, but that’ll have to wait for another post.

Next up, I’ll probably tackle walking and pathfinding (I’m thinking of implementing IDA*), then I’ll look into the drawing order stuff (I have an idea there, which needs another rewrite of the rendering queue), and then appears to me the right time for saving/loading. I might have Dark Seed II working completely relatively soon .

Let’s focus on the Playtoons games! They can be separate in three categories:

- Playtoons (5 titles) contain an interactive story, an intro of some other stories available and  a construction kit. A bundle exists : it contains Playtoons 1, 3 and 5.

- Playtoons Construction Kits (3 titles) contain an intro of the 5 stories and a construction kit

- Bambou is… Bambou! It’s some kind of Limited Edition of Playtoons developed by a subsidiary of Coktel (CUC Software International) and as far as I know only released in French (nevertheless we are still searching for localized versions). It contain no construction kit.

So far, the interactive stories are fully playable (when available), with some non-blocking issues (imperfect animated icons behavior, incorrect video behavior when skipped, text not showing in some part of the Playtoons titles), and Bambou is the less imperfect of all those titles.

Hereafter are some screenshots from ScummVM. Hopefully the story modes will be fixed soon, … the construction kit will be “a bit“ harder/longer. Adi 2 too, by the way

If you want some other Playtoons screenshoots, just ask: DrMcCoy and I already bought all the French titles, 3 Deutsch titles and 2 English ones. Spanish and italian titles exist too but are either not for sell or far too expensive.

To give some other (old) news, Fascination plays now until the first screen, which is more or less playable but not achievable due to the missing implementation of the unique window system used. So it’s not hopeless, even if there was no progress during this last 2 months.

One last word concerning  Myst/Riven in general and clone2727 in particular: clone2727 thinks that nobody (except me) is interested in his splendid in-game videos. Show him he’s wrong! Show him you care and add a video request here!

Script variables

From the engine’s viewpoint, the whole of the script variables is just one huge blob of memory. The scripts can then ask the engine to write into or read out of this memory area either:

• a 4 byte value at an offset divisible by 4
• a 2 byte value at an offset divisible by 2
• a 1 byte value at any offset
• a string at any offset
• a multi-dimensional array of any of these above

Moreover, some variables are also indirectly accessed by the engine, by having some structs overlain with the variables memory. For example, the objects’ animation parameter structs are directly mapped onto the variables memory, so that both the engine and the scripts can easily change the current animation frame of any object.

No index for which offsets are used how exists, so the engine only knows the type of a variable when it’s accessed.

Saving in the original engine

Like the variables organisation, saving is almost exclusively handled by the scripts. The scripts assemble the save name, which saves are already there and the like and give simple read and write orders to the engine. All save slots are written one after the other into one file. All screen shots, if the game made them, into another file.

Saving commonly looks like that then:

1. Write 500 bytes out of variables offset 1234 into file “CAT.INF” offset 0 (header, containing stuff like used joker count
2. Write 1200 bytes out of variables offset 5678 into file “CAT.INF” offset 500 (slot names)
3. Write 50000 bytes out of variables offset 0 into file “CAT.INF” offset 51700 (save the whole variables blob, second slot)

The old save system in ScummVM

Since for ScummVM, we don’t want all slots pasted into one big file, but one file per slot, including screen shots and the like, I had to hook into the reading and writing opcodes. Generally, ScummVM now looks for know file names, caches the header and index, calculates the slot number from the whole block dump offset and then saves everything into a slot file.

Special care is given for reading the index, which the original already loads for determining which slots are filled. ScummVM simply iterates over all slot files and reads the name.

I messed up there, though. I didn’t think I had to change the format any time in the future, so I didn’t add an own header into the slot files. For Gobliins 2, they’re simple the slot name and the variables afterwards, for example.

The first problem I faced was that of big endian systems. The single variables are always written in native endian into the variables memory, so it was not possible to exchange saves made on differently endianed systems. So make that work, I encapsulated variables access, noting the size of each variable. Then, at saving time, I used these sizes to force all variables to little endian. This seemed to work, at first.

The second problem I noticed was that of Mac and Amiga versions of gob games, i.e. ones that run natively on big endian systems. Sometimes, the scripts depend on variables being written in big endian, breaking support in ScummVM on little endian systems. I then saw that it’s better to change variables access to always write them in the endianness of the original game. Not wanting to break save game compatibility, I still kept the variable sizes.

Unfortunately, I must have messed up there as well, since these two systems didn’t work together correctly, creating save files that couldn’t be exchanged between differently endianed systems anymore. Which was the main reason for me to finally create a better, non-broken save system.

The new save system

The new save system brings in some big changes:

• Save parts (variables, name, …) are now in an IFF-like container
• There’s a header, noting the game and game’s endianness
• Variable sizes don’t exist anymore

Basically, the new system fixes all problem that existed in the old ones. Saves can now be freely exchanged between different systems again. It’s quite a lot bigger in code size, though.

Old saves in the new system

And what does it mean for old saves? I’ve included a converter, that tried to convert old saves on-the-fly while loading. The old saves aren’t touched, but most of them can be loaded and then saved in the new format. Did I just say “most” of them? Yes, unfortunately, saves made on big endian systems are fundamentally broken and can’t be used anymore. There’s no header in the old saves, so I can’t even tell whether it’s broken beforehand and try to fix it too.

The marginally good side is that you can’t accidentally keep using a broken save: if it’s broken, it’s broken completely and you can’t even access the menus anymore. You will have to restart ScummVM.

In conclusion, I’m sorry for the inconvenience brought in by my short-sightedness when I implemented saving at first. I should be fixed now, and if there’s again something broken, it can be more easily changed without breaking compatibility.

Now, I happen to think that this is a bloody stupid name (no offence to the original team meant, of course). People around me seem to agree.

Also, I’ve gotten used to “gob” and this blog’s name wouldn’t work with “DEV” . Therefore, the engine in ScummVM will keep being called “gob”. For now, anyway .