Melkhior’s Mansion – Project Update #8

Sunday night in the UK means it’s time for a project update for the conversion of Melkhior’s Mansion Spectrum Next!

It’s been another productive week for the conversion. I’ve finally added all of the background objects from the snapshot I took of the original PC version at the end of February!

I can now focus on the primary 3D isometric engine.

This week saw completion of all objects drawn by the secondary 2D engine. This includes the wall torches, the 1884 barrel, the grandfather clock pendulum, the bookcase sliding shelf, the trapdoor falling animation, the gates and the portrait pictures that change when the player is close by.

I developed a system to allow me to rapidly add these entities to the rooms importing the original PC version’s XML data for the animation speed and frame sequences.

I created a series of counters to cover the various animation rates. These counters allow the game engine to automaticity know when it’s time to update the next frame in each animation sequence.

As there are two refresh rates, 50Hz and 60Hz, I use two sets of counter data. A simple example is the torch animation, it’s speed is 10 frames per second in the original version so at 50Hz, that’s one frame change every 5 ticks and one frame change every 6 ticks for 60Hz. This allows the animations to match the original version. The system locks on to the Spectrum Next’s current refresh rate so there are no issues if the user toggles 50Hz/60Hz during gameplay.

As you may recall, I am developing two versions of the game, the Z80 based Spectrum Next version and a special Windows version written in x86 using an emulated virtual Next. The x86 version takes care of data conversion and allows me to edit visual elements of the game as it runs as well as view debug data.

I have come to the conclusion over the weeks that there is a good case to keep maintaining the Windows version seeing it through to completion. This was not the original plan. I will allocate some time to finish and add my Z80N core to the x86 project.

The Z80N core will allow me to run Next code on the Windows version saving time having to write two sets of game code. The game data is shared but the main routines have to be ported depending on which platform I decide to write for. Sometimes it’s x86 and other times it’s Z80 that takes the lead. I will continue to prototype the complex sections of the project in x86 but the simpler routines will be written directly in Z80 which will save time and effort in the long run.

Time was spent this week maintaining the projects to keep them tidy and in sync with each other. I have a procedure in place – It’s a simple rule that states that I must add the current set of routines to both projects as I develop them. They are both currently in sync with each other.

WARNING! CODE TALK!

I spent time this week on the Z80 start-up code, trimming it to gain space so I could allocate 256 bytes of upper memory for what I call ‘FAST BSS’. My start-up code is erased after the game runs but had to fit within the sprite buffer after modifying the upper memory allocation.

FASTBSS is a simple concept, I store frequently used variables at location 0xFB00 .. 0xFBFF. I coined the term FASTBSS to relate to address 0xFB00 lol. Their memory addresses are allocated using the assembler’s BSS system allowing their range to be 0x00 .. 0xFF … this only requires one byte of memory to store the address of these variables.

My assembler NXASM and the x86 assembler NASM both use RESB, RESW, RESD to define BSS data.

The variables are accessed by adding 0xFB00 to their address. This can be done by setting the Z80 H register to 0xFB and loading the L register with the variable address. It saves code space and CPU cycles. There are various other optimal methods to access these variables. My sprite animation system uses this feature as it saves one byte of memory for each sprite definition. You can access them as normal by using FASTBSS+VARIABLE_NAME.

I also had to solve a problem with data sharing. The x86 version requires 32 bits when storing an address in a data structure; DD POINTER_TO_SOMETHING. This is wasteful as the Z80 is using the same source code include file. NXASM builds the code as 32 bits which is not ideal for Z80.

I decided that I would add the directive DL, define LONG to my assembler. I would need a macro for the x86 project named DL which just places a 32 bit DD (define DWORD) in the code. This means that the tool chain has define LONG, where LONG is 32 bits for x86 and 16 bits for Z80. I can now use pointers in my data structures.

SUMMARY

I was hoping to start work on the 3D isometric engine late this week but the animation system and update to the tool chain was a worthwhile investment of development time. I’m happy and don’t mind that I am a couple of days behind this week’s predicated target.

Here is a quick note about the snapshot I am working with. The developers of the PC version took a short break so I am converting an older version of the game which I will refresh once development of the original has settled down again. It takes time and effort to prepare the data for the Next version – this includes editing some of the rooms in Photoshop. I find scenarios where an entity has moved location since the last build so it’s more productive to take a snapshot every other month or so to bulk import the game data in one long session rather than trying to amend small frequent changes.

My workflow is to complete the current snapshot although I keep an eye on the original to make sure I am aware of major changes. This method does force my hand from time to time to refresh the data I am working with. There is an update on twitter as I write this post announcing changes to 60 rooms so I will hold back with a newer snapshot I made a couple of days ago as it would soon become out of date.

The February snapshot game data has been added to the project so it’s now time to concentrate on the snapshot functionality. The next task is to develop the 3D isometric engine starting by adding the player sprite, aka Sir Stamperlot. This is where the real fun begins!

As usual, I will be back next Sunday night UK time (GMT) with another update.

KevB aka 9bitcolor.

https://twitter.com/9bitcolor
https://twitter.com/EricRetro
https://twitter.com/hot_piping