{"id":272,"date":"2022-09-26T09:42:35","date_gmt":"2022-09-26T09:42:35","guid":{"rendered":"https:\/\/blogs.scummvm.org\/quote58\/?p=272"},"modified":"2022-09-26T09:42:35","modified_gmt":"2022-09-26T09:42:35","slug":"gsoc-final-report","status":"publish","type":"post","link":"https:\/\/blogs.scummvm.org\/quote58\/2022\/09\/26\/gsoc-final-report\/","title":{"rendered":"GSoC Final Report"},"content":{"rendered":"

Welcome!<\/h2>\n

Google Summer of Code 2022 has now ended, so this post will wrap up everything that’s been done and what is left to do.<\/p>\n

The branch of my repository with the latest code for The Immortal can be found here: https:\/\/github.com\/Quote58\/scummvm\/tree\/immortal\/engines\/immortal<\/a><\/p>\n

\n

What has been done<\/h2>\n

– Initial analysis of the source code and ScummVM engine skeleton [relevant post<\/a>] [relevant commit<\/a>]<\/h3>\n

The original plan was to continue the implementation started in a previous GSoC for the DOS version of the game, however after taking a look through the source code for each version and discussing it with my mentor, the plan changed and I began work on implementing the Apple IIGS version instead.<\/p>\n

– Support for ProDOS with Common::Archive [relevant post<\/a>] [relevant commit<\/a>]<\/h3>\n

The first challenge that presented itself when I began work on the Apple IIGS version was the file format for the game itself. The Immortal was originally packaged as ProDOS disks, which was an issue because ScummVM did not have support for reading this file format at all. Adding support required learning about and understanding the way ProDOS files work, \u00a0and experimenting until I had code that could parse the entire disk and list the files within. Once it was possible to get and return files from the disk with a file name, I was encouraged to integrate this with the Common::Archive class in ScummVM, and proceeded to do so.<\/p>\n

– Compression Routines [relevant post<\/a>] [relevant commit<\/a>]<\/h3>\n

Once the file could be read by the engine, I decided to begin by tackling something that looked fairly self contained. The compression\/decompression routines did not seem to be tied in to any other functions within the engine, and so could serve as a way to get comfortable with what I would be doing in the rest of the engine, through something with a clear purpose and input\/output. In the linked post, I talk about the process of beginning to translate the assembly of the engine into C++, with the compression routines as the example.<\/p>\n

– Initial engine and subsystem skeletons [relevant pos<\/a>t] [relevant commit<\/a>]<\/h3>\n

\"\"<\/p>\n

After the compression functions were written, the next step was to start analyzing the files in the engine and begin to understand the main path of the game logic, the connections between different files, and ultimately create the initial engine skeletons. This meant creating the outline of immortal.cpp, kernal.cpp, and logic.cpp, and creating the necessary function stubs for everything along the way.<\/p>\n

– Palette processing [relevant post<\/a>] [relevant commit<\/a>]<\/h3>\n

\"\"<\/p>\n

While creating the skeleton for kernal.cpp, I decided to implement the main palette processing functions. There are not too many functions related to this, and it was a core component of the engine, so I felt it was good to implement along the way. It also served as an example of how the assembly code makes heavy use of bit manipulation and interesting math\/programming principles.<\/p>\n

– Scope and engine outline [relevant post<\/a>]<\/h3>\n

\"\"<\/p>\n

One part of translating the engine that took some time to get sorted out, was the general structure of the engine itself. It isn’t initially clear how each component of the engine relates to each other, but it is important for knowing how to structure the translation, what data types to choose, how to manage scope, etc. The linked post goes over the entire process of sorting through the files and determining the general scope and relation of each component in terms of ‘layers’ in the engine. This was important for the translation going forward, as it could inform decisions about how each new component that was translated related to the whole engine.<\/p>\n

– Story subsystem [relevant post<\/a>] [relevant commit<\/a>]<\/h3>\n

\"\"<\/p>\n

The ‘story’ subsystem in the game is crucial, as it defines many of the important aspects of each level of the game. It defines what and where the objects, enemies, and more are in each level, as well as the dialog strings, the sprite animations, and more. The way it is implemented in the source code is unusual, and the linked post goes into detail about it.<\/p>\n

– Cycles [relevant post<\/a>] [relevant commit<\/a>]<\/h3>\n

\"\"<\/p>\n

‘Cycles’ are the way that this engine handles sprite animations, and the linked post goes over the oddities with them.<\/p>\n

– Flameset [relevant commit<\/a>]<\/h3>\n

‘Flamesets’ are the torches that you find on the walls in each level. They are not objects or enemies, but are in fact their own little subsystem consisting of a sprite cycle, and code for interacting with fireballs, and even dimming the screen when they are ‘off’.<\/p>\n

– Sprite rendering [relevant post<\/a>] [relevant commit<\/a>]<\/h3>\n

\"\"<\/p>\n

\"\"<\/p>\n

Sprite rendering involved many different subsystems and took some time. This is because the method for preparing and drawing sprites is a bit unusual, and translating it accurately was a challenge. The post goes into detail about some aspects, but there are several others throughout which detail the process of understanding them.<\/p>\n

– Text parsing and printing [relevant post<\/a>] [relevant commit<\/a>]<\/h3>\n

\"\"<\/h3>\n

– Hit gauge [relevant commit<\/a>]<\/h3>\n

\"\"<\/p>\n

This acts as the wizard’s health bar in the game, and is drawn with sprites from the font sprite sheet.<\/p>\n

– Implemented many functions for Kernal, Logic, Level, Room, Sprites, and more, creating the skeleton of the engine in a way that supports a continued, accurate translation<\/h3>\n
\n

What is left to do<\/h2>\n

I had hoped to have some of the map drawing in time for this post, but unfortunately the map data is stored in multiple file types (.CNM and .UNV) which require unpacking and processing before they are usable, and the formats are specific to the Apple IIGS version of the game. I am working on it, but it will take more time to decipher.<\/p>\n