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.

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

Smoothly Horizontal – Part 2 – Here’s one I shifted earlier

This post is about using pre-shifted graphics to produce the effect of smooth horizontal movement, as explained previously.  This is the most straightforward of the two methods to produce smooth movement, but has it’s limitations – which I’ll come to at the end.

Smoothly Horizontal – Part 1

Drawing graphics at horizontal pixel, rather than character, positions isn’t quite as straightforward as doing it vertically.  Vertically, as each pixel row has it’s own address on the screen, we just had to find the correct address to start from, and work down from there.  Horizontally however, groups of 8 pixels are held within a single byte, using a single bit each, which makes things more complicated to know which bits to set. Continue reading