So let's cut right to the chase. Here's how (I understand) the Sonic games handle displaying sprites: There's a big table of sprites to be processed in RAM. This table is $400 bytes in total. Every $80 bytes are a separate "layer", with the first layer ($0-$80) being in front of everything and the last layer ($380-$400) being behind everything. Every object in the game has a "priority" SST, which tells the game which "layer" it should go to. The DisplaySprite subroutine is what handles sending sprites to the table. Sonic 1 and 2 have the "priority" SST as a byte, and to transform it into a "layer address", they do this in DisplaySprite: Code: lea (Sprite_Table_Input).w,a1 move.w priority(a0),d0 lsr.w #1,d0 andi.w #$380,d0 adda.w d0,a1 Sonic 3 and Sonic & Knuckles, on the other hand, have the "priority" SST as a word, and in DisplaySprite they simply do this: Code: lea (Sprite_Table_Input).w,a1 adda.w priority(a0),a1 So obviously, S3K's way of doing it is more optimized than the S1/S2 method. And there is a guide on how to port the S3K method to S2 (thanks redhotsonic). However, the guide isn't very... intuitive, and freeing up an SST shared with (almost) all objects is somewhat difficult, and you might want to use that SST for something else anyway. So, why not employ another way to speed up this subroutine? Here's my suggestion: Code: DisplaySprite: moveq #0,d0 move.b priority(a0),d0 andi.b #7,d0 ; safety measure. this shouldn't be needed, so remove this if you want a bit more speed add.w d0,d0 movea.w Priority2InputAddrTable(pc,d0.w),a1 ; (snip) ; --------------------------------------------------------------------------- Priority2InputAddrTable: dc.w Sprite_Table_Input dc.w Sprite_Table_Input+$80 dc.w Sprite_Table_Input+$100 dc.w Sprite_Table_Input+$180 dc.w Sprite_Table_Input+$200 dc.w Sprite_Table_Input+$280 dc.w Sprite_Table_Input+$300 dc.w Sprite_Table_Input+$380 Basically, instead of loading up the sprite table input address to a1 and then calculating (except in S3K) and adding an offset to it, my version simply cuts out the middleman and uses the priority as an index into a table containing layer addresses. Thus, being (possibly) faster, at the expense of a very tiny amount of ROM usage. ...yeah, if you haven't noticed, I'm not actually sure if this is any faster. Can someone let me know, please? also why does this forum not have syntax highlighting for 68kASM? can xenforo just not do that?