Ben Larson wrote:
> Anyway, like I said, I don't really know what the
> standard player graphic-loading methods are. Right
> now I'm just wondering if this is a viable (albeit
> wasteful) method. I think it is, but I need some
> insight...
Your idea will work and should be very fast, but it wastes a lot of ROM
to store the data with those additional zero bytes needed.
The fastest (non illegal opcode) version I know, looks like this:
TYA ;2 Y contains the kernel line counter (i.E. 191..0)
SEC ;2 if carry is already known, this can be removed
SBC SpriteStart ;3 contains the line where the graphic starts+1
ADC #SPRITEHEIGHT ;2 assuming the height is constant (i.E. 6)
BCC .skipDraw ;2/3
LDA (GfxPtr),Y ;5
STA GRPx ;3
.skipDraw: ; = 19/12 (or 17/10)
If you are willing to use an illegal opcode, the two SEC cycles can be
totally removed:
LDA #SPRITEHEIGHT-1 ;2 assuming the height is constant (i.E. 6)
DCP SpriteEnd ;5 illegal opcode, see below
BCC .skipDraw ;2/3
LDA (GfxPtr),Y ;5
STA GRPx ;3
.skipDraw: ; = 17/10
(DCP SpriteEnd == DEC SpriteEnd, CMP SpriteEnd)
So when your sprite is 6 pixels tall and shall start at line 45, then
you initialize SpriteEnd with 50 (45+6-1). With each line, SpriteEnd
will be decreased.
The result of the following compare will be:
50..6: 5 (SPRITEHEIGHT-1) is smaller than SpriteEnd -> carry = 0 -> .skipDraw
5..0: 5 is bigger than/equal to SpriteEnd -> carry = 1 -> draw!
255..: 5 is smaller than SpriteEnd -> carry = 0 -> .skipDraw
In both cases, GFxPtr has to point at the data where the graphics are
stored, minus the Y value of the line where the player shall be
displayed.
I'm quite sure, that's (in most cases) the optimal way, but someone may
prove that I'm wrong.
Have fun!
Thomas
_______________________________________________________
Thomas Jentzsch | *** Every bit is sacred ! ***
tjentzsch at web dot de |
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
