# Long time no see?

It’s been over a year since I last posted here, sorry about that, but I’ve been rather busy… What spare time I’ve had to devote to this hobby has been taken up with trying to convert a PC game which is currently in development to our humble Speccy.

The game is called Melkhior’s Mansion, and it’s a modern re-telling of the Speccy favourite Atic Atac, by Ultimate Play The Game, all done in glorious full-colour isometric 3D.  It really looks amazing!

# Slow slow quick quick slow…

Most of the questions I get asked about writing games for the Spectrum are about graphics – so the next two posts will cover two such questions on that topic.  The first question regards how to move objects around the screen at rates other than multiples of a pixel, such as moving 2 pixels every 3 frames.

If we were writing our game using a modern language on a modern system, this wouldn’t even be a problem – the position of the object would be stored using floating-point numbers, which we could adjust however we like safe in the knowledge that the system will render our object at exactly the right place – easy.  But we’re not a modern language or system, and on the face of it can’t do either of those things – we don’t have any floating-point registers, and have to sort out the actual rendering ourselves – but it can still be done.

# Printing Numbers – Part 3

The third system for printing numbers is very similar to the second – where we stored each digit of the number separately.  This gave us complete control over how big the number could be, and removed some of the drawbacks of storing the number as an 8 or 16-bit value.

However… doesn’t it seem a little wasteful to store a single digit – 0 to 9 – using a whole byte?  And doesn’t it also seem a little strange there there appears to be no support for doing this kind of thing in Z80 itself?  Surely it’s not such a ‘custom’ concept?

Well, welcome to Binary Coded Decimal!

# Printing numbers – Part 2

So we’ve covered the method required for printing the value from an 8 or 16-bit register, but have found two drawbacks with it – the size of the number we can print, and the time it takes to print it (as it has to keep looping for each value in each numeric ‘column’)  I also hinted that there are at least two other methods you can use for doing this tasks, and both rely on using a more ‘direct’ method for storing the number – just store the digits themselves instead of using binary as the registers do.

# Printing numbers – Part 1

Something which is very simple in BASIC is to print a number:

```10 LET A = 42
20 PRINT A```

Easy as that.  This isn’t quite so simple in machine code however, as you need to work out, and print, each ‘column’ of the number – the units, the tens, the hundreds, and so on.

There are a number of different ways to do this – I can think of 3 which work well – with each having it’s own pros and cons, so will start with the most simple – printing a number from a register.

# Rear Gunner XL – Part 6 – SLOW DOWN!!!!

So, have you played it yet?  Yep, it’s complete impossible to control, and there are bugs!  I’m going to cover all the ones I’ve found now, but not initially give you any code to fix them – try to fix them yourself first…

It’s a bit quick eh?!  This is a very graphic demonstration of the difference between BASIC and machine code.  In BASIC if you press a key to move the player it does so after roughly half a second or so?  In machine code, you can move multiple places in that same space of time – so much so that your first attempt at moving is likely to fling the sights completely off the edge of the screen!

# Rear Gunner XL – Part 5 – BOOM!

The final six lines of the game – 150 to 200 – involve reacting to the player pressing the fire button – and checking to see if they’ve hit the enemy or not.  If they haven’t then the play loop continues as before, allowing the player to try again.  If they have hit the enemy then an ‘explosion’ graphic is displayed, and the game starts over.

# Rear Gunner XL – Part 4 – Movement

So far we’ve setup the variables we need, and drawn our sights and the enemy into the screen.  We still can’t really play the game though, as we need to have some way of moving around,  This is handled in lines 90 to 140:

```; 90 IF INKEY\$=“5” THEN LET B=B-1
; 100 IF INKEY\$=“8” THEN LET B=B+1
; 110 IF INKEY\$=“7” THEN LET A=A-1
; 120 IF INKEY\$=“6” THEN LET A=A+1
; 130 IF INKEY\$=“0” THEN GOTO 150
; 140 GOTO 50```

# Rear Gunner XL – Part 3 – Drawing

Having converted the first five lines of the game in the last post, which setup the positions of the player and enemy, we can move onto the next four lines, which are concerned with drawing both the player’s sights and enemy:

```; 50 PRINT AT D,C;”(graphic G)”
; 60 PRINT AT A,B;” + “
; 70 PRINT AT A-1,B;”   “
; 80 PRINT AT A+1,B;”   “```

Line 50 is drawing the enemy sights, and 60-80 the player.  It’s interesting to note that the player is drawn in the middle of a 3×3 square, surrounded by spaces, so when the player moves it erases the previous position as it goes.

# Rear Gunner XL – Part 2 – Setting up

I think the best way to do this conversion is type in the BASIC listing as comments, and then add our Z80 conversion of each line as we go.  This will all be stored in our main.z80 file.  That way it will be obvious what code each line translates to, and hopefully be easier to follow.

Note that this isn’t going to be the most optimal or efficient solution to converting the game, as optimising everything often leaves the code being somewhat unreadable.  I’ll offer some thoughts on how it can be improved, but I’ll leave that up to the reader 🙂