Extended Graphical Templates for Sprite Management
by Ernest "TANSTAAFL" Pazera

What are graphical templates?

Although you may be unfamiliar with the term, chances are you've seen a graphical template; especially if youíve read some of the more popular game programming books. This is what one looks like:

Whatís wrong with this?

At one time, I used these to manage tilesets. However, in almost all cases, there wasnít enough information in the image, and Iíd have to either hardcode the width of the tiles, or save cell information in another file. Needless to say, it was an unwieldy solution. What I wanted to do was to be able to provide all of the information about the sprites in the template itself, such as the size of the cell, which more often than not did not take up the entire cell, and centering or reference points so that I could supply my sprite blitting function with just a (x,y) pair, and have the sprite blit properly in relation to that point. Also, I wanted to supply transparency information, and cell size so that I could just load the tileset, and go.

What I did to fix it Ö

So, I came up with a way to keep track of all of this information graphically. The first thing I did was to make the pixels where the white lines cross black. Actually, it can be any color. This color is also used as the transparent color key (magenta (RGB(255,0,255)) is a favorite of mine). What these black(or whatever) dots allow us to do is determine the width and height of the cells. In fact, if we really wanted, we could have more than one width or height within the same tilesetÖ Iíd like to see you do that without a lot of pain in a standard template.

The next thing I added was a reference point (I call it an "anchor") on the cell walls (the x goes on the top, the y on the left). This can be used for a center, or to reference where the foot of a character is, or the base line of a font. With this, you can just pass an (x,y) pair to your blitting function, and the (x,y) point will correspond to the anchoring point in the image.

Still, this wasnít enough for me. Most of the time, my sprites didnít take up the entire cell. Depending on your blitting function, and whether or not you make heavy use of transparent color keys, many times you either have to blit twice to the same pixel, or you have to test all of the pixels in the source against the color key. This isnít terribly inefficient by any means, but why should we force ourselves to do this if we donít have to? So, what I did was I put a different color to specify the extent of the sprite on the template walls (x range on the top, y range on the left). This way, my loader could determine the size, and store it in a RECT, and then use some code to only blit that RECT.

Of course, this lead to a problem. Sometimes the reference point is within the width or height, sometimes not. To fix this, I added one more control color to differentiate between anchors within the image rect, and outside the image rect.

Hereís an example of an extended template, with a few sprites from spritelib:

And hereís the same image, blown up to 400%

As you can see, the green sections make up the rectangles into which the sprites fit. The blue dots are the y reference, which is one pixel below the feet of the characters, and the cyan dots are the centering reference dots for x. The reason that the y anchors are one pixel below the feet of the characters is so that I can align the sprites on the topmost pixel of whatever they are standing on.

In the upper right corner, along the right side, there are a series of 5 dots. These are for the control colors, so that you can use whatever colors you like.

How to load in images that use the extended template ...

Initially upon loading, you have to load in the control colors from the rightmost pixel column. I use the order Transparent, Border, Outside Anchor, Inside, Inside Anchor. This is just a personal preference, order-wise.

Next, you scan the top row, and leftmost column of pixels, and parse out the cell widths and heights.

After that, you scan the top and left wall of each cell for the anchors and sprite rectangles. Then youíre ready to go. The coordinates for the RECTs and anchors should be in relation to the tileset image as a whole. Youíve got all the information you need to be able to blit your tiles.

Now, if youíre using GDI, your work isnít quite done. Youíll have to scan for transparent pixels, and replace them with black (if they arenít already), and also make a bitmask, but since all the transparent pixels are there in the image, you can go ahead and do that while scanning for transparent pixels. The beautiful thing is that you donít have to scan the entire image, you can just scan within the sprite rectangles.

If youíre using DirectX, then your job is simple, just set the source color key to the transparent control color (be sure to take into account the pixel format) and go.

Blitting a sprite from an extended template Ö

Youíll probably want to keep all of this information in a class or a struct, like so:

//GDI tileset struct GDITileset { HDC hdcImage;//contains the actual image HDC hdcBitMask;//contains the bitmask LPRECT rcRectList;//list of sprite rectangles LPPOINT ptAnchorList;//list of anchors DWORD dwSpriteCount;//number of sprites }; //ddraw tileset struct DDTileset { LPDIRECTDRAWSURFACE7 lpddsTileset;//surface containing tileset LPRECT rcRectList;//list of sprite rectangles LPPOINT ptAnchorList;//list of anchors DWORD dwSpriteCount;//number of sprites };

Regardless of using GDI or DDraw, the way to find out where to blit to is the same.

Your blit function will most likely resemble one of the following:

bool BlitSpriteGDI(HDC hdcDest, GDITileset* pTileset, DWORD dwSpriteIndex, int xDest, int yDest); bool BlitSpriteDD(LPDIRECTDRAWSURFACE7 lpddsDest, DDTileset* pTileset, DWORD dwSpriteIndex, int xDest, int yDest);

Within either of these functions, you first check to see if dwSpriteIndex is a valid sprite by comparing it to pTileset->dwSpriteCount. If it isnít valid, return false.

if(dwSpriteIndex>=pTileset->dwSpriteCount) return(false);

Next, we pull out the source RECT.

RECT rcSrc; CopyRect(&rcSrc,&pTileset->rcRectList[dwSpriteIndex]);

Now, we calculate the destination RECT:

RECT rcDest; CopyRect(&rcDest,&rcSrc); //start by copying the source rect OffsetRect(&rcDest,-pTileset->ptAnchorList[dwSpriteIndex].x, - pTileset->ptAnchorList[dwSpriteIndex].y); //subtract the anchor OffsetRect(&rcDest,rcSrc.left,rcSrc.top); //add the upper left corner of the source rect

Lastly, the actual blit. With GDI, first the bitmask with SRCAND, then the image with either SRCPAINT or SRCINVERT. With DDraw, just use Blt.

And thatís about all there is to blitting from an extended template.

Other uses for extended templatesÖ

I use extended templates for almost ALL of my 2d graphics. Sprites, animation sequences, cursors, tiles, fonts, you name it.

The great thing about using these templates for animation sequences is that you can move the anchor points for a sprite without moving the image. This makes lining up cells really easy.

Bitmapped fonts are a breeze, since you have the width of the sprite within the struct. I usually use a little VB utility I wrote to take a font and make an extended template with it. I only include characters 32 through 127, and then I have the program scan the image to set up the width and height and the anchors. (for the space, I just copy the width and x anchor from the exclamation point).

Using extended templates for cursors is really cool. You can use the anchor point as the point that you are on. This is especially useful in fullscreen DirectDraw applications where you are using DirectInput, and need to do your own cursors, and want to have them animated; extended templates make that management easy.

One more really cool thing Ö

One last thing, and Iíll stop trying to sell you on extended templates.

Since you have the sprite rectangles, you can programmatically make the entire set smaller. Itís a really simple process.

First, you scan through each row, and determine the largest height (has to include the anchor if there are any anchors outside of the image itself). Next, you scan each column, and do the same thing for width.

Now, you can create a new template, and use the information from the scan as the cell widths and heights, and then reposition the sprites based on this information. Voila! you have a smaller image, thus decreasing load time and scan time.

So, what CANíT extended templates do for you?

Well, thereís one thing Iíd like these templates to do that they currently cannot, and that is store strings naming the sprites. Sigh. Bitmaps can only be extended so far. If anybody has any ideas, though, let me know.

Ernest Pazera

Discuss this article in the forums

Date this article was posted to GameDev.net: 7/12/2000
(Note that this date does not necessarily correspond to the date the article was written)

See Also:

© 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!