Jump to content
  • Advertisement
  • entries
  • comments
  • views

Graphics Palette system

Sign in to follow this  


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

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
Sign in to follow this  


Recommended Comments

Not sure what API you're using, but have you considered artifacts from texture addressing? Sometimes it's necessary to factor in a gutter in order to stop neighbouring tiles in the palette from being sampled at the borders (e.g. bilinear filtering)...

Also, if you're feeling really adventurous, I was discussing an idea with someone the other day - temporal resource rearrangements.

That is, if you had 5 palettes fully loaded with textures, you'd (over a period of 100 frames or so) monitor what order those textures were required by the hardware. In Direct3D that'd be a SetTexture() call. You'd end up with a list like:

SetTexture( 0, Palette_1 );
SetTexture( 0, Palette_2 );
SetTexture( 0, Palette_3 );
SetTexture( 0, Palette_2 );
SetTexture( 0, Palette_4 );
SetTexture( 0, Palette_5 );
SetTexture( 0, Palette_1 );
SetTexture( 0, Palette_2 );

and you could then attempt to optimize the layout of the tiles (probably by moving tiles between palettes) in the palettes so that less state changes occured.

I'll be quiet now [smile]


Share this comment

Link to comment
I havent considred that unfortunetly.

Is there no way to insure it doesnt read past?

Share this comment

Link to comment
Is there no way to insure it doesnt read past?

Correct texel addressing should solve most things, but I think there are still cases where you can get the occasional artifact.

Basically, in a bitmap image you store pixel's intensity as an area (usually square!). Whereas when it comes to rasterization, the intensity as defined as a point in the middle of that pixel. If you get the addressing wrong (address the top-left for example) then it knows that part of the colour at that point is an interpolation with the neighbour pixel.

All gets quite confusing unless you write it out on paper with diagrams [smile]

If you've not seen it, have a read of Directly Mapping Texels To Pixels - it covers the basic rules on how to offset things correctly.


Share this comment

Link to comment
yup, thankfully i know about proper texture coord adressing (half-texel yada yada), I guess i am just worried about the effects of scaling textures.

Share this comment

Link to comment
I like the idea of optimizing the palettes which Jack proposed but I'd do it a bit differently.

If your game is split into levels or regions you could rank the "importance" of textures once, then store this information in an extra file (or even in the level file) and use it when you load a level or enter a new region. This would make loading time a bit longer, but it would avoid lags which occur when you need a texture which is currently being moved [to another palette].

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!