A couple months ago I changed the Path system to change unreachable terrain cells into cliffs. This greatly improved path-finding performance on fully-enclosed maps when the strategic AI tried to explore outside the playable area. Unfortunately, some Instant Action maps start units outside the playable area as a time delay, and path-finding crashed on those maps.

To fix the problem, I added a check in path-finding to prevent the crash and then changed how unreachable cells work. Instead of changing unreachable cells into cliffs, I modified path-finding to treat unreachable cells as impassable regardless of cell type. Units use the unmodified cell types so they don't trigger "stuck" behavior when crossing unreachable terrain. Units outside the playable area now follow designer-placed paths exactly since path-finding fails but they do seem to arrive at their destinations.

I was curious how 8-bit translucent textures would work and found that I had forced 16-bit assets during the D3D9 conversion. I disabled that that and after several false steps found that the 8-bit effects use the normal palette and additive blending. This gives them a strange appearance and much lower color quality compared to software and 16-bit rendering. There wasn't much alternative at the time given the hardware that would be running 8-bit mode so I can't fault it too much.

As an experiment, I added an alternative indexed texture remapping table based on my reconstruction of the RGBA alpha-blend palette. It broke the existing 8-bit hardware assets but worked perfectly with the existing 8-bit software assets aside from anything using the missing explosion color ramp (indices 0xE0-0xFF). The resulting effects look much better than the software-rendered equivalents but otherwise share their color restrictions; they can't achieve the vibrant colors of the 16-bit versions (especially magenta). Unfortunately, I can't use this change without replacing bzhw.zfs.

Graphics cards no longer support 8-bit indexed texture formats so 8-bit hardware assets use the same surface formats as 16-bit textures. As a result, there's little benefit to supporting them besides historical interest. It might be worth replacing them with DXTC/S3TC assets, which reduce texture memory usage with a modest decrease in image quality. I'd have to decode that format when calculating terrain material colors, though.

Between the sprite colorization table in sprites.c and looking at the 8-bit indices and 16-bit A4R4G4B4 values in several colorized sprite textures in a hex editor, I've managed to piece together most of the alpha texture "virtual palette". I still need to get the explosion colors and figure out the low 4 bits of the secondary (S*) ramp values. The latter looks like a quadratic curve but I haven't worked out the exact pattern yet.

I spent several hours over the weekend adding error diffusion to MakeMAP but found it unusable in practice. It produced glaring and objectionable dithering in many 8-bit indexed textures and subtle but noticeable color noise in many 16-bit textures. In the remaining textures, it produced little visible difference. In the end, most Battlezone textures simply look better without it.

Floyd-Steinberg dithering is the most famous form (and the first thing I tried) but I ended up using a simpler pattern that worked just as well (or badly, as the case may be):

-
#
2
1
1
 

Sometimes you have to try something to rediscover why it wasn't done before...

Depending on how textures get used, they get processed in several different ways. The original Battlezone toolchain only supported 8-bit indexed (type 0) and A4R4G4B4 (type 1) formats. The new MakeMAP tool adds support for R5G6B5 (type 2), A8R8G8B8 (type 3), and X8R8G8B8 (type 4) formats.

Object textures are opaque and used by units, buildings, props, powerups, and other objects that can appear on any world.

• For 8-bit indexed format, the tool maps colors to a subset of the palette shared by all worlds (objects.act).
• For 16-bit format, the tool reduces colors to R5G6B5.
• For 32-bit format, the tool passes colors through as X8R8G8B8.

Environment textures are opaque and used by terrain, sky, and other objects that are specific to one world. For historical reasons, images must be flipped vertically.

• For 8-bit indexed format, the tool maps colors to a world-specific palette (e.g. moon.act).
• For 16-bit format, the tool reduces colors to R5G6B5.
• For 32-bit format, the tool passes colors through as X8R8G8B8.

Effect textures are used by ordnance, particles, explosions, and reticles. The images contains the effect composited against a black background, a form of premultiplied alpha. The tool recovers alpha by taking the maximum of the red, green, and blue for each pixel, then normalized red, green, and blue by multiplying by 255 and dividing by alpha.

• For 8-bit indexed format, the tool maps colors to an RGBA "virtual palette". The renderer blends these into the framebuffer using a precomputed 256×256 lookup table.
• For 16-bit format, the tool reduces recovered-alpha colors to A4R4G4B4.
• For 32-bit format, the tool passes recovered-alpha colors through as A8R8G8B8.

Interface textures are used by interface elements. The images use magenta as a chromakey color. The tool recovers alpha by treating the chromakey color as transparent and all other colors as opaque.

• For 8-bit indexed format, the tool maps colors to a subset of the palette reserved for interface elements.
• For 16-bit format, the tool reduces colors to A4R4G4B4. This wastes three bits of alpha but makes non-opaque formats consistent with each other.
• For 32-bit format, the tool passes colors through as A8R8G8B8. Interface elements get little benefit from 32-bit color, though.

Colorized textures are used by smoke, tracers, and flames. The images themselves are grayscale but colorized during processing.

• For 8-bit indexed format, the tool maps grayscale values to special color-remapping palettes (e.g. brown.act). The remapping palettes contain grayscale values at indices that map to color ramp entries in the world palettes; the remaining entries contain a chromakey color indicating that the index should not be used.
• For 16-bit format, the tool colorizes grayscale values with a color table and reduces the result to A4R4G4B4. (MakeMAP does not implement this yet)
• For 32-bit format, the tool colorizes grayscale values with a color table and passes the result through as A8R8G8B8. (MakeMAP does not implement this yet)

During the development of Battlezone, I had a Perl script that walked the asset directory tree and built a makefile from rule snippets stored in specially-named files. The resulting makefile cooked assets as needed into a form usable by the game engine.

Since I no longer have the asset-processing tools, Perl script, or rule snippet files available, I just wrote some Windows batch files to automate the texture cooking process. It's nowhere near as clever as the makefile but gets the job done well enough for now.

I did some digging around and found a bunch more source textures for Battlezone. While I unfortunately don't have everything—building and prop textures are still missing—I now have the original effect, terrain, sky, and interface textures in addition to the unit textures. I spent most of the weekend adding support for new 16-bit and 32-bit texture formats.

The main task was creating a MakeMAP tool to cook textures into Battlezone's .MAP format. It does does most of what the original toolchain did with the exception of colorization. In particular, it supports the premultiplied-alpha and chromakeyed images used by most effect and interface textures. Once I add support for color remapping and reconstruct the color tables, it will be able to cook the remaining effect textures.

I don't have all the palette files I would need to recreate all the 8-bit textures, especially the "virtual palette" used by 8-bit effects textures. I should have enough to recreate the original 16-bit textures and create new 32-bit textures, though.

The game and MakeMAP tool support five .MAP formats:

• Type 0: the original 8-bit indexed format used for SW rendering and opaque textures in HW
• Type 1: the original 16-bit A4R4G4B4 format used for translucent textures in HW
• Type 2: a new 16-bit R5G6B5 format used for higher-quality opaque textures
• Type 3: a new 32-bit A8R8G8B8 format used for highest-quality translucent textures
• Type 4: a new 32-bt X8R8G8B8 format used for highest-quality opaque textures

The results are oddly inconsistent. Unit and some sky textures look much better in 16-bit, with more accurate colors, better detail, and cleaner gradients. Terrain textures look only a little better since they are relatively monochromatic and much of the palette is devoted to terrain colors. Effect textures were already 16-bit but definitely look smoother in 32-bit.

WebGL Playground, which attempts to do for WebGL what wondefl does for Flash.

Here's a good example: Reaction-Diffusion

Pressing the up or down arrow key during a YouTube twirling-circle "buffering" indicator turns it into a "snake" game on top of the video. (I discovered this by accident earlier this evening.)