joefish: ScummVM Google Summer of Code

This week only a few changes made it to the repo but progress is progress.

• Drawing mouse cursor and hourglass (1,2)
• Buffering image sections on startup (1)
• Playing game music (1,2)

Unfortunately there still seems to be a bug in either my conversion code or in the protrackerStream implementation. The top video is from criezy’s blog post on converting the Mission Supernova music to MOD files and the one below shows my implementation.

Right now, it works well enough but should be fixed before GSoC ends. At ~30 seconds in you will hear the reverb is missing in my video and other glitches.

(Source: https://www.youtube.com/watch?v=SoO5FJuXySQ)

(Source: https://www.youtube.com/watch?v=Sj7up82__y0)

Seems like our Chef Horst Hummel got impatient and sliced the hourglass cleanly in half..

The 16×16 cursor image is stored as a bitmap like the newspaper images I described in my previous post on graphics and animation in Supernova. The black outline and red filling are rendered seperately, both taking 32 bytes.

I skimmed through my code and could not find a shift that possibly corrupted the cursor data. But how to fix it? Well, it seems the image is split right at 8 pixels and since they are represented by one byte we could just do a wordRoll that swaps its bytes like wapped = (i >> 8) | (i << 8).

The disassembly shows the critical part for drawing the black outline

next_line:
          lodsw
          mov cx,dx

next_pixel:
          shl ax,1
          jc skip1
          mov byte es:[di],0
skip1:
          inc di
          loop next_pixel

          add di,320
          sub di,dx
          dec bh
          jnz next_line

lodsw… The first endianess bug in this project that I got stuck on…
At least now it’s working and I can keep going with more important stuff like actually making it playable and hopefully won’t get distracted by those small things again…

Unfortunately there won’t be pretty pictures for this weeks summary but I finally released by blog on the graphics and animation of Supernova.

I’ve been working mostly on converting the game logic for the first act and extending the engine (e.g. renderText(), renderMessage(), save/restore of screen sections, …)

More noteworthy commits were:

• Implementing of Room Data Structures
• GameManager class
• Conversion of game logic for first act

This week I will be getting the engine in a ‘coherent’ state before the first evaluation on June, 26th. While rendering images and animations work, playing audio samples and the game logic for first act was converted, all those features do not yet play together.

The goal will be rendering the starting room with the ability to interact with objects in some form. If everything works fine that’s how it will look like

This post will be about the compression algorithm used for the graphics and how it plays into the animation system of Supernova.

The images consist of a custom palette of 239 colors and divided up into sections that define its size and a pointer to the image data. An exception to this are the newspaper articles, seen in the intro of the game.

Those bitmap images have dimensions of 640×480 and only monochrome colors, instead of 256-colors palettized 320×200. The difference in their encoding can be seen here in the code. So, for the mode 0x11 images I mask the bits of a byte and depending if the bit is set 0 (Black) or 11 (63% White) is written. It is safe to use palette colors as the first 16 colors of the default palette, defined here, won’t be overwritten by an image’s custom palette.

Mode 0x13 images that make up the rest of the game’s graphics are compressed in a run-length encoding (RLE) and are 320×200 256-color palettized. The following describes the structure of the file format:

The image decoding part can be found here. It works more or less like this:

The encoded image is read into a variable ‘input’ byte by byte

• If input < numRepeat, write the next value read input-times
• If input < numZw, write the (input – numRepeat)th value of ‘twin-value array’ twice
• Otherwise, write input value directly

The success of this simple way of compression depends on how monotonous the image is. The less color changes happen in a scanline the better the compression.

(Source: https://www.youtube.com/watch?v=f1V0fki_zjo)

Sections, as already mentioned, describe an image section that most of the time shows objects in different states of interaction, like an opened or closed door, by redrawing only part of the base image (section 0).

As you can see in the video, sections 7, 8 and 9 are the frames for the animation of the ‘slide door’ to the airlock. And that’s the whole trick. Well, a door sliding open in 3 frames is not that impressive, so I composed a video with 3 scenes from the game that meet your expectations a bit more when you hear the word ‘animation’

(Source: https://www.youtube.com/watch?v=ezjaOoF80Jo)

Another week I have to start with an apology for delaying the blog post on the game audio. But I brought pretty pictures, so I hope we are even 🙂

(Source: https://www.youtube.com/watch?v=wWe6onhVMYk)

(Source: https://www.youtube.com/watch?v=ezjaOoF80Jo)

As you can see lot of things improved since last week, most notably

• image palette fixes (1, 2, 3)
• text rendering,
• extension of renderImage() to render sections that are needed for animation and interaction

My start was bumpier than I hoped. Nevertheless, there is progress that I will show more regularly in the coming weeks.

Yes, sometimes progress shows in the most obscure ways. But after a day of segfaults, this felt gooood. It is supposed to be the title screen, that obviously got corrupted along the way. More bugs and a psychodelic strobe palette later I ended here:

(Editor’s notice: unfortunately, the image that was included here is lost and not available on archive.org)

Thanks to criezy and Strangerke the palette bug could be fixed that happened by using uninitialized values. Unfortunately, the palette is still not correct as the color fading code is yet to be implemented and text rendering is missing.

For now let’s consider it modern art.

In the coming days I will focus more on implementing game routines so that I can iterate on basic functionalities once the most crude bugs are ironed out. An important decision yet to be made will be how the data structures will look in detail for either parsing the game logic or reimplementing it in the new engine.

Also, a blog post on audio samples in addition to criezy’s post on the music will be released shortly.

There have been many games I enjoyed over the last decades and some of them would have been already lost if it weren’t for enthusiasts writing emulators or go as far as rewriting engines themselves.
Personally, I haven’t done much in that regard other than poking memory for infinite gold or a simple reversing challenge. However, when the organizations for this year’s GSoC were announced one particular project caught my attention.

I have fond memories diluted by nostalgia, of point and click adventures like Day of the Tentacle, Loom and others. Despite the genre’s revival it has been mostly off of my radar for quite some time. So far it has been a great experience contributing to the project. Not only can I finally put my DOS knowledge and reverse engineering to use but the community has been welcoming, helpful and overall a great place. The ScummVM project ports point ‘n’ click and since recently also RPG game engines to their ecosystem so that they can be played on a variety of platforms. (shoutout to criezy going through 30 revisions of my PR deep into the night…)

I have been fortunate to be selected to port Mission Supernova over the summer and translate the game from German to English. Anyone interested in the progress of my work, keep an eye on my repo and this blog where I will write about the progress of the project, its difficulties and technical details I find interesting.

Thanks again to the ScummVM team and Google for giving me this amazing opportunity.