Did some design on our underlying graphics storage system.

Unlike the old days (directdraw), you cant just slap any old sized image into your game. In Direct3D, If you do you are likely to waste bunches of space, and even more likely find that there is no texture size large enough .

So I am working on an automated system of storage; what is commonly called a palette (or a texture atlas), is usually created by an artist or designer, but I really don't like this restriction, so instead, the engine will build and maintain it's own palettes.

(An example of a 512x512 palette)


The system will choose the 'best' palette size based on the hardware capabilities; palettes can be as small as 256x256 or technically as large as the graphics hardware will allow (though 1024x1204 is likely to be our largest)

The basic idea of usage is to 'fill the holes' efficantly. The largest texture that can fit into the palette is 256x256 .

Each palette is structured like so:

Palette has n regions (width/256 x height/256)

each 256 region has 4 128 regions
each 128 region has 4 64 regions
each 64 region has 4 32 regions
each 32 region has 4 16 regions

The key to usage is proper decision on how to store incoming images:

Example: I want to load a 256x256 image

find an empty 256 region
found an empty one?
use it
if not
create new palette
repeat

Example: I want to load a 32x32 image

find a 256 region with a 128 region with a 64 region with an empty 32 region

The code will be a little complicated to implement, but overall should be pretty logical.

The resulting storage returns a fully-qualified palette address

palette index,(u,v)

This system can be further extended by cutting up larger images (512x512) into 256x256 sizes