Creating Sprites for Half-Life
Introduction
Making sprites for Half-Life is an easy way to add visual appeal to any new map or add-on that you create. Sprites are used extensively throughout Half-Life to enhance the realism of a scene or effect, and intelligent usage of them can energize an otherwise lifeless scene.
Overview
Sprites are essentially 2D animations that play inside the game engine. They are always perpendicular to the player’s point of view, and always oriented the same way on the screen, so keep this in mind when creating and using your sprites. A column of smoke that is blowing to the right when you stand on one side of it will be blowing to the left when you stand to the other side of it. A wall of fire looks great when you’re standing next to it, but if you can get above it it will look like it shoots along the floor instead of pointing upwards. Most sprites you do will have some quirk about them that will often dictate that they never be used under certain circumstances. A good level designer will quickly realize what those circumstances are, and not use the sprite in a way that makes it look bad.
There are a variety of ways to render sprites within the engine:
Additive: looks best for explosions, steam, lasers, or other gaseous or light effect. It acts as a brightness map in the scene, brightening whatever appears behind it. What this amounts to is a white pixel in your sprite is essentially totally opaque and white, and black pixel becomes transparent, and every value in between is appropriately translucent, modulo the background behind the sprite. The lighting of the surrounding area will not directly affect the lighting of this sprite, so in extremely dark areas the sprite may appear to be self-illuminating (which is often desirable, especially for explosions and lens flares). The brighter the background behind the sprite, the brighter the sprite will be.
Indexalpha: similar to Additive in that it has varying grades of opacity from totally opaque to totally transparent, but the blending within the world is done differently and the opacity is controlled not by the value of a given pixel, but by the palette register of the color of that pixel. Any pixel within the sprite that is colored by the first color in your palette will be transparent, and any pixel within the sprite that is colored by the last color in the palette will be opaque.
Alphatest: this is a totally opaque sprite with one key color that is invisible. This sort of sprite can look jaggy and less realistic than Additive or Indexalpha sprites, but it renders significantly faster than either of those two, and so can be very useful for situations where speed is more important than appearance. For instance, if you are doing sprites for a multiplayer mod, you might choose to use Alphatest sprites for explosion effects even though they look worse than Additive, because you don’t want the framerate to get too bad for any given player who is seeing a lot of sprites on their screen. The appearance of Alphatest sprites is similar to that of Masked Textures used on brushmodels, excepting that Masked Textures respond to the light level of their situations while Alphatest sprites do not.
Normal: no transparency or translucency. This sprite will appear as a rectangle in the world, animating with whatever design you create it with.
The pixel artist who is also a level designer will notice that the render type is specified in two places: inside the QC file that creates the sprite, and in the env_sprite entity properties. It is best to make both render properties coincide (that is, a sprite created as “additive” be referenced in the env_sprite as “additive”), because this is the only way to insure that the sprite look the same in software and OpenGL. The rendermode specified in the QC file lets OpenGL know the alpha requirements of the sprite, and is necessary for it to look correct in this hardware accelerated mode. Mixing-and-matching rendermodes (using an “additive” sprite as a “solid” env_sprite, “solid” meaning the same as “alphatest”) may cause your sprite to look different from software to GL, or it may just look plain bad. Happenstance may create an interesting effect, but likely as not the best thing to do is just use the sprites as they were created.
Creating the Sprite
Use whatever paint and animation tools you like best: Photoshop is my favorite paint tool, and Autodesk Animator Pro is my favorite animation tool. Anything that can generate BMP files is what you ultimately need: theoretically, you do not require an animation program, but I cannot help but think that trying to animate by just looking at the frames side by side in a paint program has got to be pretty tough.
In painting the sprite, you will need to know which render method the sprite will use in the engine. If, for example, you are painting a jet of steam, and it will be additive, you want the background to be black and the jet of steam should anti-alias against the black background. This will make it look very realistic in the game. On the other hand, the steam is going to be rendered as an alphatest sprite, you want to insure that it does not alias to the background at all, because you will end up with a dark halo around the sprite when it appears in the engine. The sprite will look great in the animation program, but will look terrible in the game. For alphatest sprites, it’s best to pick a background color radically different from any color in your sprite, and change that color a lot to insure you are not incorporating it unintentionally into your sprite. For sprites a paint tool that works well in 8-bit mode is invaluable.
All the BMP files for a single sprite must share a common palette: you cannot have different frames of a sprite with different palettes. Sprgen.exe, the program that compiles the sprite, will quit if it comes across a set of frames that do not all share exactly the same palette. Likewise they must all be of the same size, or sprgen.exe will quit the sprite generation process.
Sprite sizes must be in increments of 8 pixels, and sprites may be a maximum of 256x256 pixels. They may be as many frames as you want, but sprites do count towards texture memory, so keep that in mind when planning them.
Creating the QC File
Use the sprites.qc file included with the SDK as your base. Each entry has a three line header, giving it a name, a type, and a rendermode. Then the sprite entry is an alternating set of “load” lines, loading each BMP in turn, and “frame” lines, giving the coordinates to rip from each BMP. An except from the included QC file:
//
// medium-sized explosion, solid render
//
$spritename explode02
$type vp_parallel
$texture alphatest
$load bmp\2expl01.bmp
$frame 0 0 40 40
$load bmp\2expl02.bmp
$frame 0 0 40 40
The lines preceded by “//” are comments and won’t be parsed by sprgen.exe. They are not needed, but help a great deal when your QC file gets large.
$spritename will define the name of the SPR file generated. In the example above, the sprite will be named “explode02.spr”.
$type describes how sprites are oriented in the world. It is only a partially implemented feature, and Half-Life does not fully respond in all video modes to any adjustment of orientation. Leave this line in, set to “vp_parallel” for consistent results in the engine.
$texture is where the rendermode is defined for OpenGL, setting how much alpha information needs to be stored in the SPR file.
$load references the BMP to rip the current frame of the sprite from.
$frame defines the coordinates, as the X and Y of the upper-left-most pixel to the X and Y of the bottom-right-most pixel, which in most cases should just be 0 for the first two numbers and the size of your image for the last two. The example rips the whole image from a 40x40 pixel BMP.
--shielding people from their own stupidity is an evolutionary step backwards anyway.
.
