Sega Megadrive – 8: Animated Sprites

This didn’t take nearly as long as I expected, I managed to knock it out in one afternoon all without looking at an instruction set. This stuff is finally beginning to sink in!

There are several options for animating a sprite, each with its own advantages, quirks and setbacks. The obvious one is to load all tiles for all frames into VRAM, and modify the tile ID in the sprite attribute table each frame. This is the fastest method (in terms of clock cycles) but when you consider a 32×32 sprite, that’s 16 tiles per frame, and with just 8 frames of animation that’s 4kb of VRAM for a very short animation (and I’m pretty sure the majority will end up having more than 8 frames each). The other method is to reserve space for just one frame in VRAM, and upload a new frame during vblanking as required. Straight from ROM, I’d imagine this to be a little slow, which leads us to the third method; caching it to RAM first.

Without any facts and figures to back up my claims of ROM access being slower than RAM (perhaps I’ll write a test later and see for sure), I’ll opt for uploading a new frame to VRAM during vblanking, straight from ROM. If it turns out to be slow later I’ll rethink the method, but for now I’d like to keep the code as simple as I can, without forking out the VRAM cost (since I know for sure that will be an issue later down the line).

I’ve created a small test sprite – 4 frames of 32×32 (16 tiles), each containing one letter of the word SEGA – exported one at a time in exactly the same way as in the previous articles (convert to Indexed Colour Mode in GIMP, saved as BMP, opened in BMP2Tile, set Sprite Output Mode, press * key to select whole bitmap, Save Tiles in ASM):

Let’s go!

Organising Sprite Tile Data

Again, I’m keen to use the preprocessor to make this as painless as possible. This time round, I need a bit more info than the sprite’s size – I’ll need to know eachframe’s size in bytes and tiles, too:

SegaLogo:

dc.l    $00000000
dc.l    $00000000
dc.l    $00000000
dc.l    $00000000
dc.l    $00000000
dc.l    $00000001
dc.l    $00000001
dc.l    $00000011

; Rest of frame 1...

SegaLogoTile2:

dc.l    $00000000
dc.l    $00000000
dc.l    $00000000
dc.l    $00000000
dc.l    $00000000
dc.l    $00000001
dc.l    $00000001
dc.l    $00000011

; etc...

SegaLogoEnd                                           ; Sprite end address
SegaLogoSizeB:      equ (SegaLogoEnd-SegaLogo)        ; Animated sprite size in bytes
SegaLogoSizeT:      equ (SegaLogoSizeB/32)            ; Animated sprite size in tiles
SegaLogoSizeF:      equ (SegaLogoSizeT/16)            ; Animated sprite size in frames
SegaLogoOneFrameT:  equ (SegaLogoSizeT/SegaLogoSizeF) ; Size of one frame in tiles
SegaLogoOneFrameB:  equ (SegaLogoSizeB/SegaLogoSizeF) ; Size of one frame in bytes
SegaLogoTileID:     equ (SegaLogoVRAM/32)             ; ID of first tile
SegaLogoDimentions: equ (%1111)                       ; Sprite dimentions (4x4)

I’ve also added the sprite dimentions in a binary nybble, ready for use in the sprite attribute table, since it’s very much a static value and belongs here.

As for its assetmap entry:

SegaLogoVRAM:   equ Sprite2VRAM+Sprite2SizeB
                ; Remember, what comes next needs to be at (SegaLogoVRAM+SegaLogoSizeF),
                ; we only keep one anim frame in VRAM at a time

Sprite Animation Data

I need to define the order in which the frames appear, and for how long they appear. I’ve chosen a very simple (if a little crude) method of an array of bytes, each representing the frame ID to show for each game frame:

SegaLogoAnimData:    ; Animation data (which sprite frame gets displayed for each game frame)

dc.b    0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3

SegaLogoAnimDataEnd  ; End of animation data
SegaLogoAnimNumFrames: equ (SegaLogoAnimDataEnd-SegaLogoAnimData) ; Number of frames in animation data

At the very least, this would compress down well if/when I choose to implement some compression for the art assets. Grabbing the number of frames using the preprocessor is easy too – it’s just the number of bytes it takes up. This allows for up to 256 frames in the image, which I’m pretty sure won’t be a restriction.

Advancing a Sprite Frame

First, I’ll need a counter to keep track of the current frame. This means some organisation of the memory map – I’ve based it on the VRAM asset map method, and added a few defines for various type sizes to make it easier, since it looks like I’m in this for the long run:

; **********************************************
; Various size-ofs to make this easier/foolproof
; **********************************************
SizeByte:    equ 1
SizeWord:    equ 2
SizeLong:    equ 4
SizeTile:    equ 64
SizePalette: equ 64

; ************************************
; System stuff
; ************************************
hblank_counter        equ 0x00FF0000                ; Start of RAM
vblank_counter        equ (hblank_counter+SizeLong)

; ************************************
; Game globals
; ************************************
segalogo_anim_frame   equ (vblank_counter+SizeByte)

To advance the animation by one frame, we need to perform the following steps:

  • Get the current and next frame IDs from the anim data array
  • Increment the frame counter (and wrap round to zero if at end of anim)
  • If the current and next are the same, do nothing, otherwise…
  • Multiply the frame ID with the size of one frame, then add to the address of sprite tile data to get the ROM address of the new frame
  • Move the new sprite frame to VRAM (LoadTiles will do the job)

Here’s the resulting code in one dump, but hopefully the comments should explain each step well enough:

AnimateSpriteFwd:
  ; Advance sprite to next frame
  ; d0 (w) Sprite address (VRAM)
  ; d1 (w) Size of one sprite frame (in bytes)
  ; d2 (w) Number of anim frames
  ; a0 --- Address of sprite data (ROM)
  ; a1 --- Address of animation data (ROM)
  ; a2 --- Address of animation frame counter (RAM, writeable)

  clr.l  d3              ; Clear d3
  move.b (a2), d3        ; Read current anim frame number (d3)
  addi.b #0x1, (a2)      ; Advance frame number
  cmp.b  d3, d2          ; Check new frame count with num anim frames
  bne    @NotAtEnd       ; Branch if we haven't reached the end of anim
  move.b #0x0, (a2)      ; At end of anim, wrap frame counter back to zero
  @NotAtEnd:

  move.b (a1,d3.w), d4   ; Get original frame index (d4) from anim data array
  move.b (a2), d2        ; Read next anim frame number (d2)
  move.b (a1,d3.w), d5   ; Get next frame index (d5) from anim data array

  cmp.b  d3, d4          ; Has anim frame index changed?
  beq    @NoChange       ; If not, there's nothing more to do

  ; spriteDataAddr = spriteDataAddr + (sizeOfFrame * newTileID)
  move.l a0, d2          ; Move sprite data ROM address to d2 (can't do maths on address registers)
  move.w d1, d4          ; Move size of one sprite frame to d4 (can't trash d1, it's needed later)
  mulu.w d5, d4          ; Multiply with new frame index to get new ROM offset (result in d4)
  add.w  d4, d2          ; Add to sprite data address
  move.l d2, a0          ; Back to address register

  jsr LoadTiles          ; New tile address is in a0, VRAM address already in d0, num tiles already in d1 - jump straight to load tiles

  @NoChange:
  rts

No new trickery, it uses all of the familiar opcodes. It does require a large amount of parameters, though. If any routines require any more than this, then perhaps it’s time to start passing them in via the stack.

Putting it to Use

First, we need to load in the first frame ready:

lea      SegaLogo, a0           ; Move animated sprite address to a0
move.l   #SegaLogoVRAM, d0      ; Move VRAM dest address to d0
move.l   #SegaLogoOneFrameT, d1 ; Move number of tiles (in one anim frame only) to d1
jsr      LoadTiles              ; Jump to subroutine

…and not forgetting the sprite attribute entry, with its own palette (just contains transparency and blue):

dc.w 0x0000             ; Y coord (+ 128)
dc.b SegaLogoDimentions ; Width (bits 0-1) and height (bits 2-3) in tiles
dc.b 0x00               ; Index of next sprite (linked list)
dc.b 0x40               ; H/V flipping (bits 3/4), palette index (bits 5-6), priority (bit 7)
dc.b SegaLogoTileID     ; Index of first tile
dc.w 0x0000             ; X coord (+ 128)

Then all that’s needed is to advance the sprite animation during vblanking:

move.l  #SegaLogoVRAM, d0          ; Move sprite VRAM address to d0
move.l  #SegaLogoOneFrameB, d1     ; Move sprite size (num tiles in one anim frame) to d1
move.l  #SegaLogoAnimNumFrames, d2 ; Move number of anim frames to (size of anim data in bytes)  d2
lea     SegaLogo, a0               ; Move address of sprite data (ROM) to a0
lea     SegaLogoAnimData, a1       ; Move address of anim data (ROM) to a1
lea     segalogo_anim_frame, a2    ; Move address of current anim frame (RAM) to a2
jsr     AnimateSpriteFwd           ; Advance sprite animation

To slow down the game loop to see that each frame is displayed correctly (just for debugging purposes), I can actually make use of the delay function I wrote and abandoned in the previous article:

move.l #0x18, d0
jsr WaitFrames

That’s all I got. There’s plenty of improvements that could be made over time, such as writing the equivalent AnimateSpriteRev, and passing an animation speed param to slow it down or speed it up (which I’ll implement sooner rather than later). Here’s a dodgy GIF showing the obvious:

Matt.

Source Code

Assemble with:

asm68k.exe /p spritetest.asm,spritetest.bin
Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s