drawing a 24x24 sprite

[psycopathicteen]

I just thought of this. You can make a 24x24 sprite by overlapping 2 16x16 sprites across from each other, and filling the remaining 2 corners with 8x8 sprites.

[Drew Sebastino]

I just thought of this. You can make a 24x24 sprite by overlapping 2 16x16 sprites across from each other, and filling the remaining 2 corners with 8x8 sprites.

You just thought of that? There will be a little additional overdraw, but oh well.

[Sik]

Abuse it by using different palettes =P

[UnDisbeliever]

I just thought of this. You can make a 24x24 sprite by overlapping 2 16x16 sprites across from each other, and filling the remaining 2 corners with 8x8 sprites.

You just thought of that? There will be a little additional overdraw, but oh well.

But it saves two whole Objects and the cost is pretty minimal if your sprite tiles are dynamicaly loaded into VRAM by VBlank.

I'm going to have to remember this one if I ever run out of Objects in a game.

[Sik]

I imagine that having to process those sprites is a bigger issue (due to the MSB of the horizontal coordinate and the sprite size bit, ugh dammit Nintendo, why not just use words where not all bits are stored? - OAM is on-chip rather than on VRAM, right?)

[Drew Sebastino]

Dealing with "hioam" really isn't that difficult, or too CPU intensive. If you're doing what psychopathicteen came up with, when you are processing the metasprites, you load the 8 bits of the high byte of the 16.whatever bits and store them in "Sprite Buffer 3" (That's what I call it anyway) and store the other 8 bits in "Sprite Buffer 1". You also just have a whole byte dedicated to size that gets loaded and stored into "Sprite Buffer 3". At the end of everything, You load the first bit (that's all you need) of each byte and compress it to where the size and the x bit alternate so it's in the format of "hioam". Every byte in "Sprite Buffer 3" is equivalent to 1 bit in "hioam". Because you need to DMA sprite information to oam, I have it to where there is "Sprite Buffer 1" which is the replica of main part of oam, "Sprite Buffer 2" which is the replica of "hioam", and "Sprite Buffer 3" which is the larger version of "hioam" that has every byte only have one bit. Sprite Buffer 1 and 2 get DMAed, but 3 does not because it gets converted into 2. The bigger problem is that sprites can only occupy a fourth of vram, which calls for checking to find an empty spot for a new sprite, not a metasprite because it uses less vram. There are many times where I wonder how hard it would have been to have just given sprites 5 bytes.

[UnDisbeliever]

I imagine that having to process those sprites is a bigger issue (due to the MSB of the horizontal coordinate and the sprite size bit, ugh dammit Nintendo, why not just use words where not all bits are stored? - OAM is on-chip rather than on VRAM, right?)

True, but either way less Objects means less processing time.

There are many times where I wonder how hard it would have been to have just given sprites 5 bytes.

As far as I understand it, it would not be hard, just expensive.

To get the character bits of an Object the system needs to calculate id << 2 | %10 which costs very little silicon (no logic gates, just connection lines to the next block) and is near instantaneous.

If the Object data is not a power of 2, the system would need to use a pointer offset instead of a id (requiring more bits than just using an Id) and a n byte buffer that would need to filled before processing the Object. This takes silicon (for the buffer and logic) and master cycles to process.

It would easily reduce the number objects that can be processed and filtered per scanline by ~30% (guessing).


The other option is to make the OAM Table 2 1 byte per Object, but you would still have to split xPos in code.

Either way that you require an extra 96 bytes of wasted SRAM (IIRC) and SRAM was very expensive back then.

EDIT: Woke up this morning and realised a circular 5 byte buffer instead of using an offset index would be faster and would probably use the same amount of silicon.

[Sik]

You don't need to store the bits you don't need, in fact I know the Mega Drive takes this approach (CRAM and VSRAM only store the bits that are actually used, which matters if you try to read them back), I see no reason why Nintendo couldn't have taken the same approach. It would be the same amount of SRAM, just arranged differently.

Oh well, too late to complain on that stuff anyway =P

[psycopathicteen]

The irony is that I can't use this trick for Alisha, because I'm using 16x16s and 32x32s.

[Sik]

But now you get 48×48... more useful for large sprites I suppose. How much of an advantage would you get with 24×24 for Alisha, anyway? The silhouette is probably complex enough that you're better off using the sprites as usual anyway (just remember that aligning to a 8×8 grid isn't required).

[Drew Sebastino]

But now you get 48×48... more useful for large sprites I suppose.

Why even use it at that point? I doubt you'll be that pressed for for sprites using 16x16 and 32x32. Overdraw matters more at that point.

[Sik]

Big obstacles? (bosses? large enemies?)

[Drew Sebastino]

I'm saying that you'd be better off using 1 32x32 with 5 16x16s than 2 32x32s and 2 16x16s because there won't be any unnecessary overdraw. I plan on having a good number of sprites that large, but I'll do the 6 sprite approach.