Project FDF is going on strong. I've done a lot of pruning and refactoring to make the engine scalable. And today I had the idea of making the lighting dynamic. This is how it looks: Jump for some elaboration.

Follow up:

Firstly, the lighting wasn't static as such, however it used to be tied to the viewer, and much like in Highlander, there could be only one. Viewer, and thus lightsource.

The new approach isn't only nice, but it saves some computing too: Project FDF's graphics comprise of two components, tiles and avatars. For both of these, lightness had to be calculated individually. Now they just go to the GloomMap, which you'll previously PutLight()s (of given position and radius) into, and there'll be ready baked and piping hot luminosity data waiting for them.

And finally, the reason this new facility is called GloomMap is, because it stores darkness, rather than lightness values: when it's being populated we're looking at how far a tile is from a light source and we get a value which we use to blend darkness color to light color (lights can't yet be colored, and it isn't one of my ambitions for Project FDF either, but I might just look into it later).

Trivia for the bored: GloomMap actually used to be a part of XRhodes, way back. However, it was less advanced back then - plus it's highly specialized functionality. Therefore I decided to leave it out.