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.
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
next_line: lodsw mov cx,dxnext_pixel: shl ax,1 jc skip1 mov byte es:[di],0skip1: 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...
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
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'
Currently, I have been working on getting game logic into the game, starting with setting up the data for the rooms. Once I am comfortably ahead on that front I want to finally push out my articles on graphics and audio I'm sure everyone has been waiting for eagerly.
For the coming week my main focus will lie on implementing the game logic and wire it all up so some interaction may be possible. Despite wishful thinking I know there will be bumps in the road for me, so getting the data structures straight is what my attention is directed to right now.
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:
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.