Melkhior’s Mansion – Project Update #9
Happy Easter! Here’s the latest project update for the conversion of Melkhior’s Mansion Spectrum Next!
The project is progressing at a good pace and has now clocked up 61 days of development at the time of writing this post. Here’s a breakdown of this week’s achievements…
I began the week tidying up loose ends spending most of Monday finishing off various routines that were spoiling the overall polish. The sprites didn’t scroll with the background as I hadn’t decided on the best method to clip them when they are off screen. I solved the problem after studying the original PC version. The Next display engine only needed to clip the sprites vertically which was a simple addition to the existing code.
I adjusted the falling speed of the trapdoor shaft animation to make sure it was a similar duration for both 50Hz and 60Hz to keep the sound effects in time for the land. I wrapped up Monday’s development session with all outstanding cosmetic issues fixed.
Tuesday was the big day where I could finally start on the 3D isometric engine. It didn’t take long to decide on the isometric method as initial timing tests pointed to one specific algorithm I had been toying with over the weeks. I will talk more about the details of this algorithm in a future update once I am sure it is suitable.
Now that a 3D isometric engine design was established, it was time to look at the sort routine. I had a library I wrote several years ago that I lifted into the x86 project. I wired it up to the game and sure enough, it sorted the test data. I studied the code to refresh my memory and saw that it required a large amount of workspace. This meant that I couldn’t use it for the Next version as it would take more than an entire video frame just to initialise the workspace RAM. The algorithm is designed to quickly sort thousands of entries. This is fine for PC software but the Next only has to sort tens of objects although care must be taken to choose an optimal sort method.
The overhead of clearing workspace on an Intel CPU is negligible whereas the Spectrum Next tops out around 48K-64K per video frame depending on the display configuration, obviously, the worst case scenario is your bandwidth limit across all modes. I made a note of the method and will come back to this solution next week. I’m confident I can modify it to keep the overheads low as it will be ideal to sort the objects for the 3D isometric engine.
The next job was to add the main player sprite at long last – Sir Stamperlot! Initial estimates returned high memory usage for the animation frames but to my surprise, he packed down to around 25K using my optimised sprite cutting tool! There are four characters in Melkhior’s Mansion, the Knight was drawn first with the remaining three to follow.
Some of you may wonder why I waited as late as week #9 to add the main sprite… the answer is simple, I prefer to work on the game world first before I add the main character. There was plenty of content to keep me busy plus I’ve also spent time on tools development.
The game world reached a stage by the end of last week where it could go no further so this week was the right time for me to move the project forward. As the game is a conversion, there is no pressure to profile the gameplay mechanics first as the original team have already done that task. My role is to concentrate on the technical challenges involved squeezing a PC title into an 8 bit system.
I had done some preliminary work with the player sprite during my assessment period of the conversion late December 2018. Soon enough, the Knight was moving around the room so it was time to look at the third task of the day… collision!
Collision is required by the player control logic plus walking through objects breaks the 3D isometric illusion.
I spent some time studying the XML from the original PC version and was able to import a good percentage of the data. The co-ordinate system is based around NE, NW, SE, SW compass directions where the 0,0 origin is located towards the bottom right of the room with X and Y increasing towards the top left.
I added a system to the x86 emulator to overlay the collision data in the form of a simple HUD (head up display). I wired up the F function keys so I can show/hide various configurations of the HUD as and when needed. The HUD has proved very useful for debugging purposes as some of the collision data is generated real-time. The data and routines have to be spot on otherwise the objects will overlap.
Friday saw the surprise announcement of a ZX Spectrum 128K version of Melkhior’s Mansion. The conversion is being done by Bob Smith, I have placed a link at the bottom of this post to Bob’s twitter page for those that wish the follow the Speccy 128K project. I wish him the best of luck and look forward to seeing the progress, it’s a beast of a game for any 8 bit system to handle.
It’s now Sunday evening and I have just about finished adding all the collision data for the entire game. It’s been the focus of my workflow for most of the week. I’m currently at a stage where I am finalising the collision data generation routines and meta data ready to port to Z80.
I’m keeping the collision method a trade secret for now but I will disclose the details in a future update.
The next task is to address the 3D isometric sorting algorithm which is the workhorse of the primary display engine.
Hope you’ve enjoyed reading this diary of 8 bit game dev. I will be back next Sunday night UK time (GMT) with project update #10.
KevB aka 9bitcolor.
Leave a Reply