GP32 Sprites


pea

developer
Joined
Oct 3, 2004
Messages
1,089
Age
45
Location
New Zealand
Website
www.projectitis.com
Why are sprite tiles stored in horizontal strips?

When the image is converted from a bmp to a c array, are the pixels stored in vertical cols? This is the only way that I can see that it is more beneficial to store tiles in the same tileset horizontally rather than vertically.

BMP with 2 tiles:
123ABC
456DEF
789GHI

c array as vertical cols:
147258369ADGBEHCFI

This way an offset can be specified (in this case 9) to get the second tile.

If the pixels were stored horizontally:
123ABC456DEF789GHI

You would need to do an offset calculation for every single row of the tile!

Am I correct?
 
pea posted on Oct 10 2004 at 09:15 AM said:
Why are sprite tiles stored in horizontal strips?

Because there is no need fora 2-dim. array. the data is aligned linear in memory anyway, you can easily calculate the needed offset for a give pixel...
 
Last edited by a moderator:
pea posted on Oct 10 2004 at 11:37 PM said:
Did you even read my post?

sure and I answered the first question...
all pixel information is stored linear in the mem, as long as you keep your tiles in a strip it makes no real difference (vertical vs horizontal). You can also manage your tiles in somekind of array, but calculating the right sprite is not that easy... (it's easier when all tiles have the same size...)
 
Last edited by a moderator:
The best way to store a single tile is usually as a one dimensional array, with data laid out as a set of horizontal spans. The reason for this is that this is the same way the screen buffer is organized on most systems.

However, on the gp32 the screen is rotated anti-clockwise 90 degrees, meaning that memory adress 0 corresponds to the lower left corner of the screen, and memory adress 239 is the upper left corner.

The reason you want to lay out your sprite data like your screenbuffer is simple, you want to avoid cache misses. If your sprite data is rotated against your screen data, the offset between two consecutive reads from sprite memory will be >1, therefore yielding more cache misses, and lower execution speed.

So, for GPAmp for instance, my bmp reader reads the image data and stores it in memory rotated 90 degrees clockwise. This way I can draw the different parts of the interface more quickly.

Hope this helps.
 
Inopia posted on Oct 11 2004 at 10:39 AM said:
However, on the gp32 the screen is rotated anti-clockwise 90 degrees, meaning that memory adress 0 corresponds to the lower left corner of the screen, and memory adress 239 is the upper left corner.

The reason you want to lay out your sprite data like your screenbuffer is simple, you want to avoid cache misses. If your sprite data is rotated against your screen data, the offset between two consecutive reads from sprite memory will be >1, therefore yielding more cache misses, and lower execution speed.

could this be a reason MirkoSDK's graphic functions seem to be slower than the original SDK ones, because he re-maps the screen coords and does not use rotated sprites... so there must be a lot of cache misses then....
 
Last edited by a moderator:
I don't use mirko's SDK, not do I know how his sprite functions work, but if he does not take into account the screen orientation his functions could be generating a lot of cache misses.

Also, those routines probably aren't written in assembler :)
 
Back
Top