The first thing I’ve worked this week was trying to display the game’s intro. This required removing some code that had not yet been implemented and fixing problems with the new implementations of font loading and of the Bitmap2D class. One interesting problem that came up while loading the game’s assets, was that one of the required images caused the error “libjpeg: Unsupported color conversion request”. This turned out to be caused by the image having four color components (red, green, blue and alpha), while the loader tried to load it as a 3-component image. Since jpeg doesn’t normally support the alpha channel, the four components are specified as being CMYK (cyan, magenta, yellow and black, key in the acronym), a color space usually used in printers. The solution was then to force the decoder to decode 4 component images as CMYK.
After the previous problem was solved, there were still two more problems, both related to transparency. The first was font rendering, in which a character’s border were showing, covering up details of the characters that came before, instead of being removed by transparency. The problem was caused by the fact that, in the original engine, the TGA images containing the character data were converted implicitly to RGBA and the alpha channel was set manually as equal to the red component, resulting in completely transparent black areas (where all the color components are 0) and no transparency for the white areas (where all the color components have the maximum value). I had removed the relevant code thinking that it wasn’t necessary, not yet understanding the color space conversions that happened implicitly, but it’s now back as a method in the Bitmap2D class.
The second problem was related the loading of BMP images, of which the first visible artifact was the menu’s cursor but that would also have affected all the other cursors used throughout the game. At first, I thought that the image lacked the alpha channel and that at some point it would be set in a similar way to the characters discussed above. This sent me looking through the codebase finding nothing and being very confused about it. In the end, it turned out that the images did have an alpha channel, but this wasn’t decoded by the BMP loader. This has now been temporarily fixed by forcing the loader to consider the alpha channel, but a more permanent fix will be implemented in the future.
The next thing I worked on was the input system which I was able to complete without issues since it’s not too complicated. This system still requires some cleanup to remove unnecessary conversions between ScummVM’s event codes and the event codes available in the engine. For now, thought it was easier to just keep them and start working on the next thing. This is also a good example of how my initial plan has changed. Initially I thought that I would focus on one system at a time until it was completed, but now I think the better strategy is to get everything working as quickly as possible, postponing all unnecessary work so that when new components are added or modified there are more opportunities to test the changes.
The last thing I worked on this week was bringing in the physics code. The engine uses the newton dynamics library, which is still an active project. Unfortunately, the API has not remained the same and the latest versions use GPU acceleration, so I had to settle for an older version of the library (2.36). This version is newer than the one used in the engine and still has some differences in the API but I was able to hopefully resolve them – thought I haven’t yet tested anything – by using another restoration project (https://github.com/zenmumbler/HPL1R) as reference.
Next week I will work on hopefully getting the game in a semi-playable state (without shaders or audio) by implementing the scripting system and solving the problems that will likely come up.
Thanks for reading.