Notes about the porting process to PC

Hi,

my name is Paolo and, in this tech note, I give some details about the porting process of Poizone from Acorn Archimedes to PC.

 → 

Coding Background

I coded Poizone back in 1991, for the Acorn Archimedes. It was my first commercial game, and was written in ARM assembler.

Recently, I decided to fully rewrite it for PC, to give it a second birth, and also to allow to extend it during my spare time.

I decided to use the Pygame framework, because I wanted to learn the Python language and also because it's very fast to iterate and debug.

Also, Poizone is a simple game requiring limited computing resources, so there was no need to use more efficient languages like C++.

At my disposal, I had the original ROM of Poizone (.adf file). With an Archimedes emulator such as Arculator, I retrieved the final binary files used by the game, including the executable file called POIZ_cde, also containing permanently loaded graphics data.

I also had old 3.5" Archimedes floppy disks containing the original sources of the game, but I could not read them because I had no Archimedes at my disposal. Fortunately, Robin François from the SVGA association (Swiss Video Game Archivists) was able to dump these disks with the Pauline tool and send back disk images to me. Having access to the commented source code of the game was very helpful. Indeed, I wrote this game 32 years ago, so I forgot most details about it. To faithfully reproduce the game, I retrieved parameters, rules and "algorithms" for game logic. Fortunately, I wrote many useful comments at the time.

You can find the original sources on my GitHub repo:

Archimedes/Poizone at main · PaoloBaerlocher/Archimedes · GitHub

Graphic assets extraction and conversion

Before re-coding the game, the first task was to extract graphic and sound assets from the original game in their original format and then convert them to the required PC formats.

Some of the files were compressed with the !Cruncher app using the LZW module developed by John Kortink, so I had to use this app to decompress them. Just drag-and-drop them in the !Cruncher icon. Yes, RISC OS was a very user-friendly OS :)

Files compressed with !Cruncher can be recognized by their RISC OS file type "000" (also used by other applications).

!Cruncher can be found in the "Multi-Program 24 (19xx)(-).adf" ROM available on Internet.

Graphics data (i.e. sprites or backgrounds) were stored in a raw 1 byte-per-pixel format, using the fixed 256-colors palette of MODE 13.

For non-opaque sprites, a mask was also stored or built at runtime (1 byte per pixel, either 0 (transparent) or 255 (opaque)).

On PC, to make things simpler, I decided to have all graphic assets in 32 bits-per-pixel format. Luckily, I found a nice Python script called Acorn256.py that converts a palette entry (0-255) to an RGB color for the MODE13 palette. Applying it to all pixels of the sprites allows to generate a 32 bpp PNG file that can be loaded directly in Pygame.

Multiple spritesheets are generated containing assets for every world (background tiles, monsters) or asset type (penguin, blocks shared by all worlds, the scores font, ...). For example, this is the spritesheet for shared blocks:

The size of graphics assets must be known in advance, but this can be easily determined by running the game in the emulator. Also, for alignment reasons, the width of an asset is always a multiple of 4 pixels.

These conversions are performed by the ConvertData/ConverterAll.py script, and result in a set of PNG files ready for runtime.

Audio data conversion

Originally on Archimedes, for preparing musics and sounds data, we used an application called !Tracker, a great SoundTracker developed by Fabrice Mercier, the Arc Angels team creator (many thanks to him!).

Musics and in-game samples were all packed in a Tracker file called MUSIC. For PC, I needed to convert them to WAV files. Because there is no such option in the !Tracker app, I decided to play all musics and samples from !Tracker running in Arculator, and then record the audio output with a PC sound recorder app. I then had to cut the sounds precisely using the Audacity tool.

Level maps

The 50 maps (called SCHEMES) did not need conversion, they are binary files reused as they are. They were just decompressed using !Cruncher.

UI and menus

Menus have been redesigned for the PC version. Indeed, they were not easy to read in the original version, and they used very custom text rendering routines that I could not re-code easily with Pygame. So I used the basic text rendering methods available in Pygame. Only the 5-digits score in the right side of the screen is rendered faithfully.

Re-coding the game in Python

Of course, it was much quicker to rewrite the game in a high-level language such as Python. The original game took about 1 year to write from scratch, during spare time. Rewriting it in Python took about 3 weeks, during spare time too.

The original ARM code was written as a single file of about 8000 lines of code. In Python, I split the 3000 lines of code over multiple files for better readability.

The main problem I've encountered and that I did not anticipate is related to the frequency of game logic updates. The original game was hard-coded to run at 50 Hz (for PAL video refresh frequency), while on PC the default monitor frequency is 60 Hz. The game logic being updated per frame (and not per time step), it was running 20% faster than expected, making it too difficult to play. I had to adjust some parameters to make it slower. Actually, I even made it a bit slower than the original, it felt better so (probably because I'm older now...).

Ideas for the future

In the future, I would like to add a 2-players mode in LAN (cooperative mode). The original game had a 2-players mode on the same screen, but it did not work well because the camera constrained both players to stay close to each other. In the LAN mode, both players will be able to move freely.

Thanks

• Thanks to the Arculator authors for their work on this excellent emulator, that made this port possible.