Melkhior’s Mansion – Project Update #18
Welcome to project update #18 for the conversion of Melkhior’s Mansion Spectrum Next!
I have some good news and some bad news… let’s dive straight in – I don’t think this game will fit in one-megabyte Kickstarter #1 Nexts without a fight… Here’s the good news and there’s plenty of it!
Where was I…
I wrote about the trapdoor transition and panel in the last update. The trapdoor is complete at last! The panel health ‘chicken’ meter is also finished and functional for all four characters. The HUD is waiting on the game objects to be added to the project as it will use the code and assets to display the inventory.
Headache…
I was adamant the trapdoor should integrate neatly into the room flip state machine. I got there in the end after a three-week battle. One of the first problems was the memory needed for the 88×800 pixel bitmap known as ‘the trapdoor shaft’. The solution was to compress the asset as a large region of the image was black. The depack code would render it directly to the live frame buffer.
I cheated with a fast screen clear by blacking out most of the palette to hide the current room but still allow the coloured pixels of the trapdoor shaft to be visible. The final binary was just short of 16K and could decompress to the full-frame buffer within a quarter of a video frame at 60Hz.
More problems…
The rooms on the Next version are slightly cropped at the top as there’s very little point storing and loading pixels you’ll never see… oops! the trapdoor transition scrolls the room onto the display vertically – those missing pixels will have to be restored for the rooms that scroll. Eleven rooms use the trapdoor shaft entry point. That’s a lot of extra pixels requiring a total of 56K to be cached in SRAM.
There’s some nasty real-time frame buffer juggling and ‘demo coder’ tricks to deal with the HUD/panel when the screen scrolls. This update would turn into an essay if I detail how I manage to keep the game running at its fast-paced 60Hz refresh rate during the trapdoor transition!
The last section of the trapdoor section involved adjusting the scroll timing for each of the sixteen display configurations. The sound effect always plays at the correct pitch, but the video refresh changes rate.
Performance vs. memory…
I’ve noticed over the weeks that I’ve been compressing many of the assets on a case by case basis as I process them. Load on demand is helping a great deal but I also have to pack a lot of the data too. I write a custom piece of x86 in the Windows tool for every single asset group. It’s keeping the SRAM footprint down but eats into development time and can be costly on CPU processing as there’s very little hardware support on the Next side to depack the data.
As mentioned in a previous update, the Layer 2 320×256 bitmap eats a lot of processing power. 28Mhz is a fast clock speed for an 8-bit Z80, but there are penalties imposed by the Next hardware when reading SRAM at that rate. One extra clock cycle is added to each byte read from memory, slowing down the system – the Z80N instructions are also read from SRAM as well as any data they process so those ‘wait state’ penalties add up.
LDI is a common data transfer opcode. It normally takes 16 clock cycles to complete. At 28Mhz, it takes three extra cycles. DMA would solve the performance issues I write about in many cases as it’s only 5 clock cycles per byte transfer, but I would lose a lot of SRAM storing assets in RAW uncompressed format. I will carry on compressing as many of the assets as possible.
Are we there yet?
I needed a break from the game engine side of the project after the trapdoor headache, so I decided to tackle the front end. It makes sense at this stage because the game is made up of four quests, one for each character. The health meter was the first section of the project I encountered that only needs to load the data for the active character. At 8K an animation, that’s a total saving of 24K of SRAM.
The internal core of the game must use SRAM efficiently, swapping modules in and out when needed. If it’s not used, it gets purged. I felt it was important this week to deal with modules and the SRAM layout after the work-in-progress memory footprint hit 550K! That figure will shrink when I complete the memory module allocation system.
Summary…
The intro is finished and most of the main front end is also done! I added sprites to the project this week and that’s when the memory began to disappear lol. It was nice to finally see Sir Stamperlot on the Next hardware. It won’t be long now before he can begin to run around the mansion.
I’ll do my best to fit Melkhior’s Mansion in 1MB, fingers crossed.
KevB aka 9bitcolor.
https://twitter.com/9bitcolor
https://twitter.com/EricRetro
https://twitter.com/hot_piping
https://twitter.com/alberto_mcalby
