From Retrosoftware

Revision as of 12:08, 29 September 2009

Mode 2 sprite movement

Demo Video

Note : The video seems to make the fastest sprite look a little jerky, in reality it isn't so.

Introduction

This project demonstrates three technuiqes; plotting, moving and erasing sprites. This page may be expanded upon in more detail in the future but for the moment appologies for the brief explanation.

Moving sprites

Moving sprites around a screen is not just a simple matter of changing the X,Y coordinates, if only it was ! When a sprite is plotted to screen you are physically writing to the screen memory and if you change the X ordinate and replot then the old copy will still be there. So the principle is before plotting in a different position you have to erase first before you can do this.

This routine plots fully masked Mode 2 sprites. Which means anything behind a sprite will show through rather than having an ugly black block around our sprite. If your sprites never cross over each other or you don't move them over anything more than a plain background then you can get away without using masked sprites, and these are vey much faster to plot so worth considering if you don't need a masked sprite.

The Raster and vertical sync

For now I'm afraid I'm going to have to presume you know what the raster and vertical sync is as time does not allow me to explain it here. But basically you must time all your sprite plots to the screen sync pulse, otherwise you will get flicker (Some flicker is often unavaiodable for complex games). You need to do all your erasing and plotting before the raster beam starts to redraw the screen. To do this we wait for a system even called the screen sync, when this occurs the beam has finished drawing the display and is about to start another. This is whenwe do our sprite plotting and hope that we get it all done before the beam gets to out sprites otherwise the dreaded flicker can occur.

In fact the screen sync actually occurs a couple of rows after the visible part of the display has been drawn. So if we use the sync for our sprite plotting timing we do in fact waste some time. What this demo does is to use a system timer to indicated when the visible screen has just been completed. It's at this point that we fire off our drawing code to try and gain maximum time.

Limitations

The demo is flicker free, but that is not to say that the raster isn't well onto the screen by the time we've finished plotting the sprites, because it is. By choosing the order in which the sprites are plotted in the demo means the plotting stays ahead of the raster for all sprites and is flicker free. If you draw too many sprites near the top of the screen you will get sprite "shearing". One easy solution is to limit how high you plot your sprites (put in a nice big status bar so that the user doesn't feel cheated of screen space) and also to reduce the sprite sizes to speed up plotting. the sprites used are a reasonable size for a Beeb game and could eb reduced in size if requried. Another option would be to use a lower memory screen (i.e. Mode 5) and for the loss in colour you're sprites end up physically the same size but using much less memory and thus plotting very much faster.

Why not try

This routine is reasonable for some games but for others the dreaded sprite shearing may be an issue. But... there are still other things you can put into the code to improve this. For example write a routine to order your sprites so that they avoid the raster beam as much as possible. Think also about when you do your erasing, is the point that it happens in this demo really the best point ?

Download source

The enitre Swift Project (Highly recommended, just load into Swift and run !, contains all files you need even if not running in Swift )