Melkhior’s Mansion – Project Update #6
Today is the 40th day of the conversion of Melkhior’s Mansion Spectrum Next – here is the latest end of week project update!
I’m really happy with progress this week even though I still have toothache – Grrrh!
I managed to have to good run from Wednesday to Sunday on the project. Most of the work has been centred around the sprite cutting system I detailed in my previous update. That system is now complete and will only be updated as and when needed.
I spent a couple of days experimenting with the output of the cutter before finalising a format for the sprite attributes. Sprite attributes are used by the Next hardware to display the 16×16 pixel assets.
I decided to save the data in a compact format as there was no need to store the full five attribute bytes for each 16×16 sprite. The Z80 can create some of the attributes in code so there is no point storing data when it can be generated on the fly.
I settled with four bytes for each 16×16; the X and Y anchor offsets, the hardware X and Y mirror flags and the RAM banking information to access the pixel data – rotate is not needed due to the design of the graphics plus there was no room for the bit! Colour selection is set in software so there is no need to store the palette select nibble or the colour format as all sprites use the original ZX Spectrum 15 colour palette.
I used 14 bits for the banking information which allows me to store each of 16 colour sprites in any 128 byte aligned memory location covering the full 1792K. The maths is simple; 8 bits for the 8K bank selection (0..223) and 6 bits for the 128 byte slot within each 8K bank.
DON’T PANIC! This game is designed for the base Next with 1MB (768K usable). I am thinking ahead… Ice World, a future title requires 2MB.
Here is an example include file from the cutter.
; Bookcase sprites.
bookcase_000_spr
db 4
db 000,000,048,00000000b+51
db 000,016,048,00000000b+52
db 016,000,048,00000000b+53
db 016,016,048,00000000b+54
bookcase_001_spr
db 4
db 000,000,048,00000000b+55
db 000,016,048,00000000b+56
db 016,000,048,00000000b+57
db 016,016,048,00000000b+58
bookcase_spr
dw bookcase_000_spr
dw bookcase_001_spr
All of the 16×16 sprites are saved out in one single binary file with separate source code include files for the attributes and pointer lists shown in the example above.
I was initially going to write code to cut each texture but that was not going to be practical in the long run so I invested a couple of hours developing a script system for the cutter.
It’s pretty simple but effective. I specify the filenames and the X and Y origin on the texture page plus the number of rows and columns to cut. White space is optimized out of the cutting process so I can define the cutting dimensions to any size as long as each bounding box is correctly spaced matching the width and height in the script.
Here is the format for the script:
[BMP] SPRITES\BOOKCASE.BMP
[INC] BOOKCASE.INC
[SPR] bookcase
[COM] Bookcase sprites.
[POS] 000,000
[CUT] 02,02,07,02
The example script cuts the bookcase sprites; 2×2 16 pixel sprites (32×32 pixels), seven across and two down, fourteen in total.
The isometric design of Melkhior’s Mansion means that most of the background graphics face two directions; left or right. I decided that it would be a good idea to use the optimising sprite cutter to advantage as it will not store sprite assets that are mirrored in the X or Y planes. This advantage is that ONLY the attributes will be created for graphics that face multiple directions so no code is needed to display flipped sprites. The cost is memory but the gain is less code to develop and less CPU processing.
I spent time during the weekend developing the Z80 to process the sprite data – successfully creating code to display any sprite – this includes the logic to DMA the pixel data to the sprite video memory (FPGA block RAM).
The next task is to populate the rooms with the sprites until all the current background objects are in the game. This will keep my busy over the coming week!
So after 40 days on the project, can we see a demo ?
It’s too early for a demo version on the Next at this stage in the project. The main workload over the weeks has been dealing with the vast amounts of data from the original PC version and creating development tools to assist with the conversion.
I’m still working on the secondary 2D engine to display the rooms. The primary isomeric display engine is required for the player sprite, objects and enemies. As the game is a conversion. there is no need to prototype the gameplay first or test out ideas to see if they work as the main team are responsible for those tasks.
My role is to concentrate on the technical challenges converting a PC title to the Next so the order of development differs from traditional game dev. I’m solving memory issues first and allocating as many tasks as possible to the faster 2D display engine. The 60Hz isometric engine will take some time to develop. The gameplay can be developed once the 3D system is in place. The ideal situation is to wait until the original PC game mechanics are finalized before attempting to add them to the Next version.
I hope to have a WIP demo on the Next around the time of the Manchester Play Expo in early May – fingers crossed!
I’ll be back late next Sunday night UK time (GMT) with another update and hopefully have my tooth fixed!
KevB aka 9bitcolor.
https://twitter.com/9bitcolor
https://twitter.com/EricRetro
https://twitter.com/hot_piping
