OK, a quick and (possibly very) dirty overview of how the sprite video memory is set out.
Sprite video ram, like all video ram, is accessed in u16 sized chunks (you can access it as a u32 or u64 as well but for this post I will stick to u16 which is what the define is)
Depending on how your memory is layed out will affect how you actually access the sprite data.
- For the 2D mapping modes you have a 256 pixel x 256 pixel grid split into chunks that are 8x8. A 16x16 sprite in this mode will look as it should if drawn on paper. Think of the 2D mode as a sprite sheet put directly into the sprite video memory.
- For 1D mapping you have a long line of 8x8 pixel boxes. A 16x16 sprite will be stored as consequtive 8x8 chunks - 0,1,2,3. This mode would be likened to a file.
Example spirte design used in the following examples:
0 = Transparent colour
1 = Red colour
Code: Select all
0 0 1 1 1 1 0 0
0 1 0 0 0 0 1 0
1 0 1 0 0 1 0 1
1 0 0 0 0 0 0 1
1 0 0 0 0 0 0 1
1 0 1 1 1 1 0 1
0 1 0 0 0 0 1 0
0 0 1 1 1 1 0 0
For 16 colour sprites:
The way the data is stored is in the 4 nibbles of the u16, in reverse order. So if you stored 0x01234 in a memory location you are actually putting on the screen the colours 3 2 1 0.
So taking the example sprite from above you would store the following data into the sprite video memory at the location that your sprite should be placed at.
Code: Select all
0x1100, 0x0011,
0x0010, 0x0100,
0x0101, 0x1010,
0x0001, 0x1000,
0x0001, 0x1000,
0x1101, 0x1011,
0x0010, 0x0100,
0x1100, 0x0011
For 256 colour sprites:
As with the 16 colour sprites the data is stored in reverse, each byte of the u16 is 1 colour but this time a single block takes up 64 bytes of memory. So if you stored 0x01234 in a memory location you are actually putting on the screen the colours 0x23 0x01.
So taking the example sprite from above you would store the following data into the sprite video memory at the location that your sprite should be placed at.
Code: Select all
0x0000, 0x0101, 0x0101, 0x0000,
0x0100, 0x0000, 0x0000, 0x0001,
0x0001, 0x0001, 0x0100, 0x0100,
0x0001, 0x0000, 0x0000, 0x0100,
0x0001, 0x0000, 0x0000, 0x0100,
0x0001, 0x0101, 0x0101, 0x0100,
0x0100, 0x0000, 0x0000, 0x0001,
0x0000, 0x0101, 0x0101, 0x0000,
For truecolour sprites, each pixel is stored in the video memory in a direct 1:1 relation. I'm not up to speed with this sprite mode as I've not looked at it fully to understand it, but it does eat up the memory allocation for sprite banks very fast and IMHO should not be used, unless you really need a true colour sprite...
I did say it was a quick and dirty way to how sprites worked
Oh don't forget that the 16 and 256 colour sprites are broken up into blocks of 8x8, so you will have to convert from screen co-ords to sprite co-ords first. Basically if you know how to convert screen to tile co-ords for a 2D square tile map editor, then you can work out what sprite tile you are working on.
I'm not sure exactly what your attempting to do, but the biggest sprite you can work on at any time is a 64 x 64 sprite, so if you are wanting to draw on the sprites you are going to have to split the screen into blocks of 64x64 and then down into the 8x8 tiles of the sprite before setting the actual colours, using bitmasks for the relivant pixel.
