MagicEngine

Charles MacDonald · Member Joined: 07 Dec 2005 Posts: 35

After some discussion with FraGMarE about how to handle animated sprites efficiently, I came up with an adaptation of the compiled sprite technique for the PCE which involves a crude form of hardware-driven decompression.

Normally when writing VRAM data, the fastest you send data is with TAI which has a 6 cycle overhead per byte transferred. A compiled sprite is a sequence of ST1 and ST2 opcodes which encode the bitplane data as the operand, which only use 4 cycles per byte. This typically means the source data is twice the size as it normally should be, but it can be compressed to some degree:

Because the LSB of every word written to VRAM is latched, you get free decompression; for any sequential words in the data stream with the same LSB, you only need to output ST1 once and then multiple ST2 opcodes, saving 2 bytes per word per LSB skipped. For a bunch of ripped Sonic sprites that had some empty space out of each 48x48 animation frame, the sequential runs of 0 at the edges compressed to almost 1/2 the size exactly. Not bad!

The savings really add up, to transfer 1152 bytes takes 6912 cycles with TIA (counting transfers only) and at worst 4608 cycles with a compiled sprite, but probably less due to compression. That's in terms of CPU cycles, not sure what delays the VDC might insert (haven't been able to get any conclusive test results in that area)

Because of the small 64K address space the HuC6280 can access, the applications of this technique are limited. However, I think it would be quite useful for Arcade Card programs where there is plenty of RAM and various ways to sequentially access memory through the data ports. A more complex analysis program could find identical runs of data in a source image and thread them together with some JSRs to reduce code size.

If anyone is interested, I could write a little demonstration program and include a utility to create compiled sprites too. The same idea also works with background tiles (or even name table data), but sprites seem to be the most appropriate.

ccovell · Regular Joined: 19 Dec 2005 Posts: 100 Location: Japan

That's a really smart technique! I don't really need compressed sprites for the game I'm making, but for action games with lots of sprites being shuffled around, it would be great!

On a related note, so many PCE games use some sort of compression for their tiles. Does anybody know the compression method? And, is the method the same or different for each game company?
_________________
http://www.chrismcovell.com

Tomaitheous · Elder Joined: 27 Sep 2005 Posts: 306 Location: Tucson

fragmare · Member Joined: 01 Feb 2003 Posts: 59

Anyone know if any of this sprite/tile compression and streaming data from HuCard > VRAM on the fly can be efficiently accomplished in HuC?
_________________

Rec'ing Minds...

Charles MacDonald · Member Joined: 07 Dec 2005 Posts: 35

Tomaitheous · Elder Joined: 27 Sep 2005 Posts: 306 Location: Tucson

You could also have someone write you a custom routine in ASM.

HuC has a "#pragma FASTCALL" function that allows you write ASM routines with the same arguement passing as the Magickit lib functions, i.e. ax,bx,cd,dx,di,si,reg a, reg x, reg y - bypassing the stack passing style of HuC in favor of speed. The function calls just like any other C funtion to the user.

You can even use '.n' directive for mutilple number of arguements for the ASM label, i.e.

#pragma fastcall decompress_tile( word acc )
#pragma fastcall decompress_tile( word acc , word ax)

#asm

   decompress_tile:      ; If no arguements are called.
    <code>

    rts

   decompress_tile.1:
    <code>

    rts

   decompress_tile.2:
     <code>

   rts
#endasm

The only catch is the fastcall function code must be placed in the CONST bank or added to the HuC library.

-Rich
_________________
www.pcedev.net

fragmare · Member Joined: 01 Feb 2003 Posts: 59

Charles and Tomaitheous,

That's awesome news. Sounds like we can not only do this in HuC, but also make little "core" engines of ASM code embedded within the other HuC code for things that require more speed like collision, tile swapping, etc. I'll need to suggest this to Bt.
_________________

Rec'ing Minds...

Paranoia Dragon · Elder Joined: 09 Apr 2005 Posts: 366 Location: New Iacon

Wow, this all goes over my head, but it sounds like something Nodveidt should know about for some future titles. Won't come in handy now exactly, though maybe for Neutopia 3, since that's an action game. But, ultimately I'm talking out of my arse Razz

_________________
Sentience is the right of all freedom beings?

Keranu · Posted: Sun Jun 25, 2006 6:39 am Post subject:

Ditto!
_________________
LaZer Dorks