Sprite transparency mode - w23/xash3d-fwgs GitHub Wiki

Each sprite has its transparency mode set.

  • Additive - 256 colors with additive transparency.
  • Alphatest - 255 colors; last color is transparency.
  • Indexalpha - Grayscale; last color is the sprite color.
  • Normal - 256 colors; no blending or trasparency.

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.

https://web.archive.org/web/20020601221031/http://www.planethalflife.com:80/wavelength/2dart/tutorials/sprites.html https://web.archive.org/web/20000124024908/http://www.planethalflife.com/wavelength/2dart/tutorials/sprites2.html https://web.archive.org/web/20010711153031/http://www.planethalflife.com/wavelength/2Dart/tutorials/SpriteTutorial.html

Examples from HL resource:

  • Additive: animglow01.spr, b-tele1.spr
  • Indexed Alpha: vp_parallel.spr, tinyspit.spr
  • Alpha test: rope.spr, agrunt1.spr, tile.spr
  • Normal not found