Sprites, Sprites

rje

Member
Nov 6, 2019
40
13
8
Warning - stream of consciousness mode.

So I was typing up yet another Traveller demo game in BASIC, when I realized that what I REALLY wanted to do was leverage the CX16's sprite capabilities. Otherwise I've just got Yet Another Text-based Program, and I want something that is more than that.

And I've also read the demo programs on Github, but even with those, AND even with Michael's technical docs... oh I also found a website that walks through sprites for the CX16, which was also helpful. However, I came away from all that still feeling that the documentation is incomplete. So maybe that's something I could work on first.

(Is it me, or does it seem like that some of the registers used for sprites in the CX16 are kind of inconvenient? Maybe it's just because the sprite engine is so much more powerful than that of the C64?)

(I seem to recall a sprite editor for the CX16, but maybe that's my brain mis-firing.)
 

rje

Member
Nov 6, 2019
40
13
8
Okay, the VERA Programmer's Guide, under "Sprite attributes", coupled with the demo code from Github. Here I'll try to write in my own words, so to speak, at least as much as possible since this is registers for goodness' sake.

There are 128 sprites, as we all know and are very excited about. Each sprite is configured by a block of 8 contiguous bytes. Configuration structure is 8 bytes long. 64 bits. OK.

Addresses. Sprite attribute data apparently starts at $F5000. Thus we set the attribs for Sprite 0 like so:

Code:
100 S0 = $5000                  :REM OFFSET
110 VPOKE $F, S0+0, %00000000   :REM LSB
120 VPOKE $F, S0+1, %10001000   :REM MODE=8BPP(7); ADDR = $10000(0-3 + LSB << 5)
So we're doing one byte per pixel. I guess that gets us 256 colors for each pixel. We've come a long way since the C64.

The sprite "block" address is kinda like that from the C64. On the C64, each sprite took up 64 bytes, so when you did a POKE 2040, 200, you were addressing memory location 200 x 64 = 12,800 in the default VIC memory bank.

So in other words, the value was bit-shifted left 6 places. But we never thought about it that way, did we? No, we just thought in blocks, and we knew the VIC could access 256 of those blocks.

Of course VERA is more complex. Its "block" size is 32 bits, and it can access a bazillion of them. Well maybe not a bazillion, but it's more than you could address on the C64: $F00, or 16 x 256, or 4096 blocks. Be sure to adjust that based on your sprite size, though.

Code:
130 VPOKE $F, S0+2, 220         :REM X = 220
140 VPOKE $F, S0+3, 0           :REM (X MSbit)
150 VPOKE $F, S0+4, 55          :REM Y = 55
160 VPOKE $F, S0+5, 0           :REM (Y MSbit)
No surprises there. We have to have access to the whole screen, so we have an MSB.

Code:
170 VPOKE $F, S0+6, %00001100   :REM Z = LAYER 2, NO H/V FLIP (0,1)
180 VPOKE $F, S0+7, %01010000   :REM H=16(6-7), W=16(4-5)
Horiz/Vert flip is handy -- it can minimize the number of sprites you have to paint.
And we can have truly monstrous sprites... 64 x 64 pixels max. Nice.

Since this code says its sprite 0 data begins at $10000, let's poke some data there. 16px * 16px = 256 pixels, so we fill 256 bytes with data, right? Let's do it totally random just to stave off boredom.

200 FOR I = 0 TO 255
210 VPOKE $1, I, INT(RND(1)*256)
220 NEXT


Apparently, we enable sprites via location $F4000. Something like this apparently works:

300 VPOKE $F, $4000, 1
 
Last edited: