Melkhior’s Mansion – Project Update #2
Welcome to the second project update for Melkhior’s Mansion Next. It’s been a productive week. The Z80 side of the project was created on Friday 1st March as work on the PC emulator and tools had progressed to a stage where room data was ready to export to the Next.
The first step was to build the foundations for the Next version. This involved updating my cross development tools; NXASM and NX232. It was clear that I would need an efficient method to handle a large data set.
I would need an executable file format to handle the output from my Z80 assembler and a system that downloaded as little data as possible to the Next from my development PC as my RS232 link takes around 4 seconds to send 48K. I use legacy 9 pin D-sub RS232 serial so I am limited to 115,200 Baud due to the age of the hardware. The transfer of megabytes is not practical for game development.
I decided to use the 128K extended snapshot .SNA format as I already had 3 megabytes of data. NextZXOS implements a neat feature allowing 128K .SNA files to be extended by many megabytes. The OS boots and loads the initial 128K of data located at the beginning of the file and ignores the remainder. This allows software to launch as normal from the Next file browser and manually mange the contents of .SNA file using operating system API functions to seek and read data within the file when required. The OS can boot a 128K .SNA file in under 2 seconds!
I formulated a plan to keep most of the static data on the SD card. The result means the current download time to test the game on the Next takes a couple of seconds. The cross development system only transfers data from the lower 48K of the .SNA file. Essentially, I have split the snapshot file into two sections with frequently changing game boot/code/data in the lower 48K and finalised data filling the remainder of the file. The code/data update transfers direct to the Next memory. The initial game code opens the .SNA file stored on the SD card and reads the remaining data it requires into memory at a rate of around 680K per second.
I only need to copy the entire file to refresh the SD card when I add game data from the conversion tools. I have to insert the SD card into a Windows machine during this process. I limit these major file changes to a small number per day. Each .SNA build from my assembler is a stand alone EXE and can be launched from the Next file browser or from my PC by sending the initial 48K boot code down my RS232 link.
The initial foundations of the project include planning the memory allocation of the 768K available on a standard Next and SD card access to the data stored in the .SNA file. I spent a day developing SD card compression using the JP (C) instruction to speed up data access time. I also spent time on the room data format which I have now finalised.
I developed a new graphics cutting method to allow the conversion tools to read the pixel art assets from the texture pages used by original PC version. The tool is built into the PC emulator to speed up this process. Assets can be checked as soon as they are cut by using print screen to import the clipboard to Photoshop zooming the image to check the results as the game runs on my desktop.
I also refined my color depth conversion process to make sure the palette quantizes correctly to 9 bit RGB as the source PNG files are 24 bit RGB. The shades can easily change to undesirable colors during this process. A grey may become pink as the resolution of the Next palette cannot represent the original shade. I programmed the simple rules I use to manually convert the shades by eye into the quantizer tool.
A large amount of time is spent in Photoshop preparing the pixel art as the Next prefers the visual assets to be stored efficiently in multiples of 8 or 16 pixel textures. The original PC version builds the rooms from arbitrary shaped assets similar to the way one would assemble a piece of flat pack furniture. I manipulate each texture to work with the Next’s specifications. I prebuild the room assets into finished elements as it is not piratical for the Z80 CPU to render a full 3D isometric image made from many individual entities.
I have currently prepared pixel art for various assets found in the rooms. I also made a 3D isometric map in Photoshop of the Ground Floor so I can view the entire level at a glance.
Data is read from the SD card during game play. This was going to be a problem as the music is also read frequently from the SD card. Timing is very tight during this process. The file system must not take too long to read the room data as the player explores the game world. It currently takes two video frames @ 60Hz to load and display to the next room which is well within the specification required by the game mechanics. I developed a method to allow data to be read without affecting the audio streaming. I added 4 minutes of music provided by Alberto J Gonzalez which plays seamlessly without pops or clicks verifying this system.
The game .SNA file increased from 3 megabytes to 7 megabytes after including the initial test music!
I will continue to process pixel art to populate the rooms over the next week. This will include development of a simple sprite system to animate the doors and background objects.
KevB aka 9bitcolor.
https://twitter.com/9bitcolor
https://twitter.com/EricRetro
https://twitter.com/hot_piping
