Melkhior’s Mansion – Project Update #4
Project update four has arrived which means I am one month into the conversion of Melkhior’s Mansion Spectrum Next!
The previous two updates have been centred around the SD card system which plays an important role in Next games just as the cassette tape was the backbone of loading original ZX Spectrum data. The visual side of the project is moving forward again now that the low level foundations are complete.
Too much to read… skip to the end for a quick summary.
Day #20, Monday 11th March 2019 saw completion of the sprite module of my Spectrum Next PC emulator allowing me to continue work on the rooms moving the project forward.
Here is a brief refresher on my emulator… I decided at the beginning of the conversion to create a Windows based Spectrum Next emulator specifically for this project.
WARNING – MACHINE CODE TALK!!! Intel x86 and Zilog Z80 share some common features as they evolved from the 8080. The AX CPU register on the x86 is 16 bits and splits into two 8 bit registers; AL, AH which maps to HL, L, H on the Z80. The Intel CPU instruction MOV AX,16384 translates to LD HL,16384 on the Zilog Z80 and so on for several instructions. It made sense to convert, test and process the complex and constantly evolving original game data with the same CPU to make sure the conversion process was error free. I also find that x86 has a quicker development cycle compared to Z80.
I emulated the Spectrum Next hardware needed to run Melkhior’s Mansion, wiring it up to an Intel CPU. I find the concept of a 2.8Ghz x86 based Next with 768K of RAM rather amusing!!! I did upgrade the sprite display engine to render 4096 16×16 sprites but that was just silly and pointless so I keep to the Next’s hardware specification.
My emulator allows me to prototype the main logic of the game in simple 16 bit Intel x86 assembler with the intention that most of this code will be ported to Z80 once it is refined. It is not an easy task to implement the full isometric engine used in the original C# Monogame version on the Next. I am able to use the power of the x86 to profile various algorithms before committing them to development time consuming optimised Z80. The data conversion routines are coded in full 32 bit monster x86 as this code doesn’t execute on the Next.
I am also able to share one set of source code data include files as NXASM, my own Z80N assembler is based on NASM syntax, the x86 assembler used to create the Microsoft Windows code.
Overall, the benefit is a single integrated application to process and work with the complex game data in a virtual Spectrum Next Windows based environment – viewing and rapidly tweaking results in an instant. Changes can be made on the fly during emulation. Game editing and data debugging tools are also built into the emulator as and when they are needed.
Day #21, Tuesday 12th March 2019. It was now time to write the code that would parse the XML based game data from the original C# Monogame version. It was not going to be practical to work with the XML on the Next so it would have to be converted into a smaller, simpler token based data set.
Here is the original XML map data for room 001:
<Room ID=”001″ Size=”72 72″ RenderOffset=”0 0″ Style=”Castle”
Theme=”Red” Description=”Ground Floor”>
<Template Type=”FLOOR3X3″ Position=”0 0 -4″ />
<Door Position=”NW1″ Destination=”008″ GateType=”Cyan” />
<Door Position=”NE1″ Destination=”999″ />
<Door Position=”SE1″ Destination=”002″ />
<Door Position=”SW1″ Destination=”009″ />
</Room>
As you can see, there are no pixel co-ordinates as such although there are other XML files that contain master templates for the room styles and objects, aka ‘entities.’
Door position “NE1” refers to an exit in the middle of the north east wall. I was able to work with this format to create display position look-up tables in a neat friendly Spectrum Next Z80 compatible format. Work was completed reading the XML late on Wednesday night prior to this update.
My Spectrum Next emulator start-up sequence was updated to import and convert the XML meta data. This automated process will save many man hours converting data after receiving each work in progress update from the developers of the PC version. The emulator exports the simple binary data in both RAW and source code include file formats. The sprites are also exported in RAW format during the start-up sequence. They are cut from PNGs I prepare in Photoshop.
Here are 18 BYTES of data in my own format to describe room 001:
room_001
db LEVEL_GROUND
db FLOOR3X3
db DOOR_NW1_0,GATE_CYAN
dw 008
db DOOR_NE1_0,0
dw 999
db DOOR_SE1_0,0
dw 002
db DOOR_SW1_0,0
dw 009
To summarise, a large portion of the visual side of the game I am converting is described in XML – this also includes animation sequences. I am using as much of the original data as possible to handle various visual elements of the game. I replace the routines written in C# from scratch with x86/Z80 ported by eye in most cases. An example is the door open and close/slam timer logic. The position of the door in the room is taken from the XML data but I would need to request the time delay algorithm from the developers as a guess is not suitable in this case.
Day #23, Thursday 14th March 2019. The game engine now has access to the display co-ordinates of many entities within each room as well as the new room destination link data. Each room has as many as six exits and seven different exit types – fans of the original Atic Atac will remember the secret passages unique to each character. I can tell you that the clocks, barrels and bookcases are featured in Melkhior’s Mansion!
Day #26, Sunday 17th March 2019. All gates and key coloured doors are in the game world as well as the bookcases and trapdoors. The Next’s sprite palette select feature allows me to store one set of gate graphics and re-colour them to WHITE, CYAN, GREEN etc…
I was able to use the sprite X mirror feature with the benefit of only storing one set of bookcase sprites as they can be mirrored during the display process by the hardware.
Work has started on the barrels but requires an update to the sprite cutting system. I will need to automate cutting to detect and re-use as many 16×16 sprites as possible as I will run out of memory on the Next if I continue on the current path of storing the sprites ignoring duplicates and mirrors. The barrel animation requires 42K alone but will reduce in size once optimised.
Yes, I did say 42K, one single background animation takes the same amount of memory as the entire 1984 ZX Spectrum game Knight Lore!!!
Conclusion.
The conversion is progressing at a good pace and text book in most cases. Work will continue on the room exits and background objects over the next week as they are part of a secondary display engine used to off load tasks from the main CPU intensive isometric engine. The goal is to remove as many display objects from the primary display engine as possible to keep the frame rate at 60Hz.
KevB aka 9bitcolor.
https://twitter.com/9bitcolor
https://twitter.com/EricRetro
https://twitter.com/hot_piping
