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.

Pick a key, any key…

Finally!  The mythical keyboard post!!  Sorry it’s taken so long, but SokoBAArn was taking it’s time (along with a large & overgrown garden back in the real world). Anyway, we’re here now, woohoo!!

Back in the depths of time I did a short piece on how to detect if a key is pressed, which used the following code:

```WAITFORKEY:
ld a, 0
in a, (254)
cpl
and %00011111
jp z, WAITFORKEY```

That’s actually the basis for all keyboard reading, and as complicated as it gets, just that we were doing a particular and simple case – testing for any key being pressed.

Normal service to be resumed…

Now that SokoBAArn has been released, I’ll have a bit more time to devote to this blog, starting with that mythical keyboard handling post!

In case you haven’t seen SokoBAArn yet, take a look here…

https://bobs-stuff.itch.io/sokobaarn

M/C SCREEN\$?

Back in June Peter Jones (Hi Peter, hope you’re still reading?) asked after a machine-code version of the BASIC SCREEN\$ command, to help him convert a BASIC program.  At the time I briefly replied that it wasn’t the best way to do things in m/c, and now I’ll explain why, and what a better alternative is.

When graphics (visually) collide!

We now have the knowledge to draw sprites anywhere we want on the screen, and could try and draw as many of them as we like, but there’s a problem…

If we try to draw two of our ‘smiley faces’ next to each other, then one will overwrite the other, as below:

Smoothly Horizontal – Part 4 – Economy of scale

So which is best – storing your graphics already shifted into position, or shifting them in code?  The answer is simple – which you choose is entirely up to you and the kind of game you are writing, there is no ‘best method’ for all cases.

Smoothly Horizontal – Part 3 – Shifting as we go

So pre-shifted graphics are great to use in certain circumstances – objects which are constantly moving horizontally whilst animating, for example (think Manic Miner) – and are fast,  but they also have their drawbacks – not the best use of memory for one.  We could fix the memory issue by not having all those individual graphics, and just shift one copy into the required position when we need to. Continue reading