Sprite routines

 So, I'm writing stuff to do stuff still rather than an actual game. I now have a Sprite system for the Aquarius, which is a bit strange, but it allows sprites built from multiple characters and colours to behave like sprites, in that you can move them about and they restore the background.

This editor is f--- awful. I'd be ashamed if I'd written something like this. It's slow and bug ridden.

So you can see two sprites, the two triangular things, slightly different graphics and they whiz about very happily and quickly. M7 is very fast, if a bit greedy with memory.

The code is below. The eccentric format is because it's like Color Forth , except my text editor doesn't do colour. So :xxx is a definition (red), anything in [ ] is an execute (yellow) and the rest would be compile (green). White is comment but I've filtered that out.

So it defines two graphics, two sprites, executes the clear screen function and set speed to normal function (it's mad fast anyway). It defines an area for a sprite group (up to 15 here) and 2 areas for sprites, which contain location data, new location data and storage space for the background.

 RFill fills the screen with the text. Pause is a loop to slow it down so I can see it.

Test initialises a group and adds two empty sprites, sets the image and the inital position, fills the screen, and then 10000 times sets the sprite positions to things derived from the index, draws the sprite group, pauses so you can see it, then erases the sprite group.

M7 actually runs on the Aquarius as a cartridge, and you could use it for a development environment, but it doesn't actually have an editor. You can sit at the console and bash commands out like on a Jupiter Ace. 4 space 5 space + con.sprint (console - signed - print). The console is execute only for technical reasons, you would edit definitions in a screen and reload them.

It's not FORTH. You can't tell from this, but it doesn't have a stack. Well, you could argue it has a two-entry stack - A & B which are actually the HL and DE registers. So a>b in RFILL actually copies HL to DE. c is BC which isn't part of the stack but can be used as a temporary register.

I got the idea from the HP machines which have very small stacks. It gets round the problem of processors with only one stack. 

Which in 8 bit land is pretty much all of them, except the 6809 to some extend. Obviously you can fudge a stack, but it's slow. Not having a stack means you generate a lot of Z80 code. So + is just ADD HL,DE, and it's a macro that generates that in line, no NEXT or ENTRY or EXIT or anything, which is why it is so fast.

Part of me thinks you could do it pretty well by having the list of address as you have in non-STC FORTHs and have your cake and eat it, because it's really not that efficient.

require stdlib,console,interface,sprites

:graphic data [ $22 c, 192 c, $30 c, 193 c, $30 c, 20 c, $50 c, 20 c, $50 c,]
:graphic2 data [ $22 c, 192 c, $30 c, 193 c, $30 c, 20 c, $60 c, 20 c, $60 c,]
[con.clear]
[slow]

:group [32] array
:spr1 [22] array
:spr2 [22] array

:rfill 960 times $3028 + a>b c! tend ;
:pause 1000 times tend ;

:test
    group sg.init
    spr1 group  sg.add
    spr2 group  sg.add
    graphic spr1 sp.image!
    graphic2 spr2 sp.image!
    4 spr1 sp.x! 6 spr1 sp.y!
    24 spr2 sp.x! 7 spr2 sp.y!
    rfill
    10000 times
        a>c 21 mod spr1 sp.y!
        c>a 39 mod spr2 sp.x!
        c>a 7 mod 4 + spr1 sp.x!
        group sg.draw
        pause
        group sg.erase
    tend
;

[test]