flipcode - Cool, It Works!

Cool, It Works! - Issue 04 - Handling Textures & Effects
by (06 October 1999)

Introduction

Sorry for the long delay in getting this edition done, but work is on a tight schedule right and after working 16 hours, I just don't feel like writing when I get home ... you know.

Anyway, I figured it was time I did something so here we go ... a quick blurb on how I'm handling textures and their various effects...

"texdef" files

My engine does something similar to the shader files in Quake3 ... although, of course, not nearly as cool. Basically, you can create a text file that describes a texture and the engine will apply the things you specify in the file, to the PCX data after it reads it in.

The basic steps my engine follows when reading in a texture are as follows...

Read the PCX file.
Parse the data, and create a buffer of RGBA data from the palette/indexed data in the PCX file. My engine only reads 8-bit PCX files at the moment...
Check to see if there is a "texdef" file for this texture.
If so, apply the specified changes to the texture.
Send it to the texture manager for caching.

The files are named the same as the textures in the package files ... just for ease of reading and finding them in the directory. For example, if my texture in the package is called "warren.misc.fog" (meaning the "warren" package file, the "misc" group and the texture called "fog"), the texdef file would be called "warren_misc_fog.texdef". I replace the periods with underscores just so I don't get problems with file management and stuff. It's probably paranoia, but hey, might as well be careful.

What does a texdef file look like? Here's a sample...


[General]
Translucent=1
TranslucentAlpha=64

Very much like an INI file in Windows, there are just a list of attributes and values. So in this case, it tells me that the texture I'm reading should be translucent, and the alpha should be 64 (out of 255). So about 75% translucent. There are a lot of other settings you can use... Here's a dump of all the current ones...


Mask=1/0				// is this texture masked?
MaskRGB=red green blue			// the RGB color to mask out
Translucent=1/0				// is this texure translucent?
TranslucentAlpha=alpha			// (0-255) = the amount of translucency
					// "RGB" = calc alpha from RGB of texture
Animating=1/0				// Does this texture animate?
AnimatingThink=#			// Milliseconds between animation frames
AnimatingFrames=#			// Number of textures in animation chain
AnimatingFrame0=package.group.name	// Need one of these for each animation frame

Some more examples of use...


// Masked based on the color black.
//
Mask=1
MaskRGB=0 0 0

// 50% translucent
//
Translucent=1
TranslucentAlpha=128

// Animating
//
Animating=1
AnimatingThink=250
AnimatingFrames=4
AnimatingFrame0=animations.computers.computer1_a
AnimatingFrame1=animations.computers.computer1_b
AnimatingFrame2=animations.computers.computer1_c
AnimatingFrame3=animations.computers.computer1_d

Using these settings we can change how a texture appears in the game without messing with the source data, which is nice. The downside is that a texture can only appear one way in the game. You can't take a water texture and use it translucent in one place, and opaque in another. But I think it's a small price to pay for the flexibility these files offer.

In closing, here's an explanation on the texture animation stuff...

What happens is the level designer places a texture that is marked as animating into their level ... in the above example, a computer panel with an animating display. When the texture manager loads in that graphic, it also loads all the graphics it needs for the animation cycle. The texture manager has a "Think" function that is called right along with the rest of the game actors ... like the player, enemies, etc. During this think cycle, it checks to see if each animating texture wants to move to it's next frame. If so, it uploads a new texture to OpenGL under the same texture name as the old one. So the game itself just keeps rendering as it always did with no knowledge that the texture manager is swapping new textures in under it's nose.

Next Time

Small installment I know ... next time will be better, but I figured I should post something rather than let this column languish.

The game we're making with the engine has changed direction fairly radically, so the column will shift it's focus as well. You probably won't see any difference in what I write, but internally things will be moving in the new direction ...

See ya then!

Article Series:

Cool, It Works! - Issue 01 - Introduction
Cool, It Works! - Issue 02 - Linked Lists, Overloading Operators, Sprites, & More
Cool, It Works! - Issue 03 - Files, Texture Effects, Coronas, & More
Cool, It Works! - Issue 04 - Handling Textures & Effects
Cool, It Works! - Issue 05 - 32-Bit GL Textures & Log Files