Mike Goldberg looks at changing sprite size and using bank switching to scroll the screen

Cooo! Look at the size of those! A few years back that was a familiar cry of astonishment upon witnessing the staggering size of the sprites in some games as programmers stretched the performance of their 8-bit machines to the limit.

Not only were these sprites big but they moved swiftly over complicated backgrounds left intact after the sprite had passed. With the 32-bit computers now in our possession it is no longer necessary to write complicated machine code listings to do this because these routines are built into the sprite handling system.

Don’t be put off using these excellent facilities by purists who insist that to be serious about writing games you must, of course, write your own sprite handler. Some of the best dedicated sprite routines written have ended up incorporated in the most boring and terrible games.

If you have the imagination and your game is good and playable fun, then it matters little whether you use Basic, machine code or finger paints to produce it — don't forget how powerful 32-bit computing is!

Getting back to size, it's really quite easy to scale your sprites once you've found Acorn's equivalent of the Rosetta Stone. Using all my investigative powers and reference books it only took me six months to amalgamate the requisite commands and calls into a coherent whole!

Thank you Acorn for providing the best computer adventure game I've played in years: Sprite Trek III — The Search for Clear Instructions spread over six volumes bought by many, understood by few and correlated by nobody.

So, get yourself a sprite drawn in !Paint and use the program, Scale (on the subs disk), making sure you amend the spritefile and sprite names to your own creations. The bit we are interested in here is that in order to scale your sprite you must first DIMension some memory space for the scaling factors to be poked into:

590 DIM scale% 16

Basically we can alter the sprite size in width, the X scale if you like, and in height, the Y scale. If you take each of the two scales and look at them as fractions the picture becomes so much clearer.

Look at lines 610-640. You can see that I've used variables A and C to determine the X scale and variables B and D for the Y scale. They are set out like fractions because what you are actually altering is size in the form of a ratio. These variables are then poked to the allocated scaling area scale% at lines 660-690, and we add the address of this memory block as an additional parameter to our sprite plotting at line 590.

Obviously 1 over 1 is the normal (default) sprite size — try changing A = 1 to A = 8 and the sprite's width will increase eight fold. Try altering the Y scale to B = 8 and the sprite will be eight times as big all round. You can use these keys to alter the size while the program is running:

Z,X   = X scale
P,L   = Y scale

By altering the bottom half of the fraction you can make the sprite smaller so just think of it this way for example — if you want a sprite two thirds size, alter both sets of parameters to 2 over 3 like this:

X scale    Y scale
A = 2      B = 2
-----      -----
C = 3      D = 3

Or twice as tall but half the width:

X scale    Y scale
A = 1      B = 2
-----      -----
C = 2      D = 1

Well that's about the size of that, now let's have a look at another bug-bear for past 8-bit users — screen scrolling.

On the BBC Micro hardware scrolling enabled the entire screen to be whipped left or right and up and down at lightning speed. But if that had been all there was to it everyone would have been able to make a decent sideways scrolling shoot-'em-up before breakfast.

What a let down it was to find out that when you scrolled left the screen returns on the right one line up. Yes, that was when over 90 per cent of us gave up. And despite programmers keeping a track of the screen start address and plotting new background to the right of the screen I can only think of half a dozen commercial games at best that were anywhere near successful in sideways scrolling without that accompanying irritating flicker.

So once again the 32-bit cavalry comes to the rescue with a built in VDU command to scroll not only the entire screen but just PART of a screen which is what we all wanted years ago! No big mystery here, it is explained in the User Guide and the example, Scrolli, demonstrates how easy it is.

Look at line 250:

         Window (1=whole screen)
         |
VDU 23,7,0,1,1,|
           | |
           | 0 = one block: 1 = one byte
           |
           Direction of scroll
           0 = right
           1 = left
           2 = down
           3 = up

You can see from this example that a portion of the screen can be scrolled by simply making a window and that no wrap around occurs, thankfully. Alter the 0 after the 7 at line 250 to a 1 and watch the whole screen scroll. That's how easy it should be.

Apart from that, another really good way of scrolling is open to us owing to the 32-bit speed — that is plotting a large background sprite in a window and replotting it a bit further left each time we want to simulate a background scrolling in that direction. The diagram shows how this can be done and how extra background is added when needed.

Making the background sprite larger than the window it appears in, then simply altering the X coordinate, allows the next part of the background to be displayed, by using bank switching. When all the sprite has been shown, a further chunk of background from DATA is added to the screen when that bank is not displayed.

Then the screen itself is grabbed as a sprite and the plotting coordinates are returned to their original settings, the sprite plotted and the display switched back on — it's easier to do than write about it.

The program called 4x4 on the disk demonstrates this principal. Before running it make sure the Desktop is in Mode 15 to allow room for memory space bank switching — or it will flicker something awful — and use the following keys to move a 4x4 truck over a scrolling landscape:

Z   Steer left
X   Steer right
"   Accelerate
?   Decelerate

If you keep each of the front wheels on the same colour pixel background, the 4x4 travels more quickly — if the pixels are different, the program assumes rough terrain and slows the vehicle down.

This information - P1% and P2% — along with the background sprite's X co ordinate X% and truck speed sp% is displayed at the top of the screen.

The program halts when it runs out of background DATA but you can add more to make a longer road if you wish. Six squares are added each time from DATA numbered 1 to 19 — you can see which squares are which in the CARSfile1 file.

More about grabbing next time as I must scroll off and grab some respite.

Click here to download the example files for this article