Melkhior’s Mansion – Project Update #17
Welcome to project update #17 for the conversion of Melkhior’s Mansion Spectrum Next!
Here’s part 2 of February’s news.
Most of the development hours during the last two weeks have been spent in Photoshop and on the room editor x86 code. The panel, background animations and trapdoor shaft transition have been the main focus. Here’s why…
Drawing and masking pixels with the Z80N CPU to the 320×256 bitmap known as ‘layer2’ can be painfully slow. The original Monogame version throws a lot of eye candy around the screen. The sheer amount of pixel art and layers is overwhelming. There’s an animation for just about every entity in the game. The 3D isometric engine would run like a dog if it had to process all of the assets and I would soon burn through all 128 hardware sprites. My goal is to add as many of the animations as possible into the Next version.
So I need background eye candy, isometric sorting/masking, a large panel/HUD and vertical scrolling at 60Hz. along with multi-channel audio and on-demand SD card multiple asset streaming and 1MB KS1 compatibily… ouch!
My solution was to use the tilemap to offload rendering tasks from the Z80N and sprites. I continued the route of storing each room on SD card as a pre-rendered 320×224 image – minus all animations. I decided to pre-mask the panel onto the image during export from the Windows tool. It’s a waste of memory and CPU processing power to draw the panel live. There’s plenty of room in the 64-megabyte game WAD to store multiple copies of the assets.
The priority pixel feature built into the Next core allows the hardware to automatically mask the panel over the game sprites, even though it’s on the same layer as the room. Storing the panel on layer2 would cause problems for the trapdoor vertical scroll transition – I’ll save those details for the March update as it’s still a work-in-progress as I write this post!
Need for speed…
Photoshop time! Each room has been allocated a custom 320×256 tilemap of animation cells, laid out from left to right similar to a sprite sheet. I need to double buffer both layer2 and the tilemap so that means the tilemap data must fit within 8K (that’s 216 8×8 pixel tiles in total). It’s just enough luckily. A couple of rooms do use all 216 tiles!
The tiles are stored in the ULA display memory as usual but the 40×32 map of animations is stored in a small buffer so the animation script can copy the cells (typically 4×3 tiles – 12 bytes lol) to the main display map to bring the room assets to life. The cells range from 1×1 tiles to around 10×10. It’s a small amount of data for the Z80N to process. The tilemap data is around 500K but no need to panic as only 8K or less is loaded on-demand as you enter each room.
In a nutshell, the tilemap is being used as a texture page with X, Y, U, V style meta-data. The hardware is rendering the room, panel and animations using the powerful layering system, freeing the Z80N for the 3D isometric side of the display engine. I haven’t used a single hardware sprite so far, reserving them all for the main player, weapons, spooks, objects and room animations that require drawing order.
Summary…
It was a joy this weekend to see the pixel art animate for the first time on Spectrum Next hardware. 99% of the background scenery animations from the original have made it into the Next build. I can also reveal that the Next version has exclusive content not seen in the original!
To conclude. The Windows room editor/viewing tool is the workhorse of the conversion, creating vast amounts of meta-data for the Z80N to munch on. The Next side of the project is compact, taking advantage of the SD card capacity and bandwidth. I’m very happy with the progress I have made so far.
Thanks for the positive feedback and support over the weeks. See you Next time!
KevB aka 9bitcolor.
https://twitter.com/9bitcolor
https://twitter.com/EricRetro
https://twitter.com/hot_piping
https://twitter.com/alberto_mcalby
