Software Sprites (non-graphic)

[kelp7]

Hi,

This is a bit of a cheeky request but would like to have input from you guys as a) you are all awesome and b) this forum is very active so probably a great place to get an answer / discussion Let's pretend the VIC-20 had no graphic capabilities whatsoever, i.e. you could only put ASCII (and extended ASCII) characters onto the screen (and only in the 22 x 23 column/row positions). I just wondered how you might go about writing a software sprite routine which would draw sprites on the screen made out of ASCII characters (perhaps 4 x 4 characters or 8 x 8 even). The routine would have to prioritise the sprites and also would have to somehow stop the sprites from being over-written by other characters that might get placed onto the screen.

Okay okay, I admit it, I'm going to write this on a machine which isn't the VIC-20 (and has no graphic capability, you can't even modify the character RAM to re-define characters but there are plenty of extended-ascii shapes and lines to draw with). So that is why it's a cheeky request as it's not a VIC-20. But this forum is excellent and very active. So i'm not after program code really, just the theory or logical steps (pseudo-code maybe) for how you would handle an ascii-character based software sprite routine. Any help MASSIVELY appreciated.

[Mike]

You might take a look how my implementation of Moon Patrol handles the animation of the UFO and the bullets in front of the background with stars and scrolling mountains - see especially the lines 15 to 23 in the file 'MOON PATROL 2' of the disk image.

That should give you some ideas which can also be extended to larger objects, in short: prioritizing is done by layering the objects in order atop the background, and storing away what's currently 'below' the object. When an object is moved, its appearance changed, or the background is being written to, you'll have to remove all the objects in front of the moved/changed one (in reverse order, of course) - update this object, or the background - and then redraw the objects in front of it.

When there are large objects in use, it might be sensible just to redraw the entire screen from scratch for the next animation step, preferably into a double buffer. This also removes the need to remember what's behind each object.

One other alternative is the 'inverse painter's algorithm': first, the background is drawn, and then all objects in the order of highest priority first - this time however, an auxiliary bitmap marks all character positions where there is already an object. This way, objects which are drawn later get a lower priority and disappear behind objects of higher priority. The auxiliary bitmap allows to check, whether updates of the background can proceed or are blocked (they are still written to the original copy of the background). Again, the next animation step requires to redraw the entire screen.

[Kweepa]

Unless the screen is very large I would repaint it every frame. The background can be blitted very quickly... And the sprites drawn on top much like a normal sprite engine - since they are small (compared to bit maps) it will be quick too.

If the screen is large and there aren't many sprites or many moving sprites it might be better to use a "dirty rectangle" system.

[kelp7]

Thank you both, I shall take a look into all the methods you've mentioned. And Mike, thanks i'll take a look at Moon Patrol for certain. The machine i'm using has a 40x25 character display. I was thinking of making some useful kernel routines that could be inserted into BASIC programs on the machine and CALLed to essentially paint / move sprites on the screen.

[kelp7]

By the way, am I right in thinking that if you are animating a sprite and it is underneath a few other sprites you have to make sure to remove the sprites which lie on top of the one you're animating, draw new frame of animation and then put all those sprites back on top of it again? Or would you decide that the sprite isn't currently 'visible' and therefore not bother animating? (i guess that might be too processor intensive perhaps).