What's this all about? Check out:

With this scheme, you could quite easily add specular highlights for zero additional code at runtime. These are the "shiny spots" that adorn almost all real world objects, although they are most pronounced on metallic surfaces. They occur where the light is reflected directly from the surface towards your eye, rather than being absorbed and then reemitted equally in all directions as would happen with a normal dull surface. The highlight color is unaffected by the shade of the surface that is reflecting it, so they are almost always white. They don't happen in the same place as the brightest normal lighting (ie. where the light is falling directly onto the surface), but where the surface is reflecting the light directly towards your eye, ie. where the angle between the direction you are looking at it from and the surface normal is the same as the angle between the light direction and the surface normal. Specular highlights have a much sharper falloff than diffuse lights, so they only affect a few pixels in a very confined location, but varying the exact falloff curve and the brightness of the highlight can give a convincing effect of many different textures and material types (if you have a copy of 3DS, have a fiddle with with the specular lighting parameters in the material editor to get an idea how this works).

Because specular highlights occur at different angles to the normal brightest light, they cannot be stored in the same bits as the main light color. But because they are so sharp and clearly defined, they don't require nearly such a smooth gradient. I think you could store an adequately detailed combined light level in a single byte, using 6 bits for the diffuse light level and 2 bits for the specular intensity. The code to display a bumpmapped object would remain unchanged, just using different lookup tables. Instead of outputting an 8 bit greyscale level, the table used to combine the two direction vectors would do two individual computations (it doesn't need to know about the view direction, because in a 2d game that is always directly above the sprite), and output a combined 6.2 light value. The lighting table would then use the low 6 bits of this input to tint the sprite pixel color, and add some amount of white to the result depending on the top two bits of the light value. Result: realtime specular highlights, "for free"...

By varying the two tables described above, I suspect that all sorts of other interesting effects would be possible, for example a variant of the classic 3d chrome effect. That works by applying a plasma texture to a polygon with u/v coordinates calculated from the transformed polygon normal, but I'm sure something very similar could be done in 2d by combining a heightfield bitmap and direction vector with suitable lookup tables.

TALK ABOUT THIS STORY NOW ON THE DIGITAL GAME DEVELOPER

The latest version of Allegro can always be found on the Allegro homepage, http://www.talula.demon.co.uk/allegro/.

Shawn Hargreaves wrote the core parts of Allegro while earning a music degree at York University. Although he doesn't have any formal computer training other than having done a computing A-level course, which was "incredibly boring", he's been programming for years before this, first on the Oric Atmos (in BASIC and 6502 asm), and later on the Atari ST (Forth, C, and 68000 asm). Since graduation, he's been working for Probe Entertainment (a subsiduary of Acclaim), helping to develop the racing games Extreme-G and XG2 on the N64. As of a few months ago, he has moved to Climax Studios' new Brighton, England office, where he's the lead programmer on a new PS2 title.

BACK TO PAGE 1 2 3 4 5