Tuesday, July 25, 2017

Summary -- Week 7

So most of the week was spent on rewritting the game loop to implement animations as shown above and fixing the bugs introduced by it..
The animation system is simply implemented by setting a timer that when it expires causes the room specific animation() function to be called. (1, 2, 3, 4)
Besides that,

An interesting discovery for me was that although the text rendering code is correct it shows artifacts when drawing umlauts. As the game strings were copied directly from the cp437 encoded source I expected the character value to be encoded in a single byte as characters in extended ASCII don't exceed 0xFF. What I didn't consider is that UTF8 is only backwards compatible to basic ASCII (0x00 - 0x7F) and anything above takes at least two bytes, what causes the corruption as seen above ("Triebwerke funktionsunfähig"). That's why umlauts in the German original will be substituted by their equivalent octal value as already done here.

For the coming days the first act should be made playable by implementing edit() so the sleeping cabin section works correctly and adjust the game loop for dying and implement the 'death screen'.
After that implementing the remaining game logic takes priority especially now that the animation system is working.

Tuesday, July 18, 2017

Summary -- Week 6

Sorry for the delayed report this week but I really wanted to add a video finally walking through the empty hallways of the starship Supernova. Moreover...

ūüéČ The GUI is finally working! ūüéČ

Probably the most noticeable improvement is that GUI is now actually rendered correctly and interaction with the environment is finally possible without everything glitching out. Although, there are still issues with Give and Use command that will be addressed next.
Besides the GUI there have been improvements on every front.
  • Wrapping GUI elements in a state class (1, 2, 3)
  • Fixing font rendering
  • Correctly handling and rendering object state (1, 2, 3, 4)
  • Improvingn mouse input handling (1, 2)

Coming up next will be implementing timers for handling events and animations. There have been talks about starting translating but depending on how things go it either has to be pushed back or will have a lower priority.
Of course fixing a bunch of bugs along the way would be nice too :)

Monday, July 10, 2017

Summary -- Week 5

Sorry for the delayed update due to injuring myself while sleeping..
The input code still gives me quite a headache and will be partially rewritten when there's time. I am now in a place I wanted to prevent ending up in but for now, getting things running has priority.

As I said getting the input code working was my goal for this week additionally to fixing some GUI issues and rendering static GUI elements like the minimap, inventory, command row and status line.
I expected this part to be more difficult, as the original code is quite intertwined but I completely misjudged the effort needed for porting and debugging.

For this week I want to keep fixing the GUI and implement stubs
so the remaining game logic can be implemented without too much trouble.

Friday, June 30, 2017

Summary -- Week 4

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

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.

Monday, June 26, 2017

Drawing the Cursor

Seems like our Chef Horst Hummel got impatient and sliced the hourglass cleanly in half..
The 16x16 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 swapped = (i >> 8) | (i << 8).
Wait a second....

The disassembly shows the critical part for drawing the black outline
          mov cx,dx

          shl ax,1
          jc skip1
          mov byte es:[di],0
          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...


Friday, June 23, 2017

Summary -- Week 3

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

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

Image Rendering and Animation

Let's hope not all humans are that ugly  --  probably some Axacutian

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 640x480 and only monochrome colors, instead of 256-colors palettized 320x200. 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 320x200 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.


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'