[F8] Custom Sprites: layering and lightmapping

[Q__Hybrid]

Hi everyone,

Before I begin on a large project, I would like to ask advice regarding the plans I have for my engine.

Premise
First of all, I want to achieve effects like dynamic lighting and highly flexible user-customizable colors.

Composite Sprites
The basic idea is to use sprites that are divided up into cohesive elements (a head layered on top of a torso, etc) and are first drawn in grayscale, then exported as a set of discrete graphical layers whose opaque fill is white.
The layer that corresponds to the darkest value of a sprite element is then transformed to the desired color, per default for the sprite or the user's selection.
The other layers that correspond to the lighter values of the sprite element remain white and are given an opacity equal to 100 divided by the total number of layers in the sprite element.

When all of these layers combine, they yield a "modeled" sprite element whose base color is user definable.

Lightmapping
You're right if you immediately said "it would be easier to transform a grayscale image without all these layers." The reason I nominated the approach above is because of my need for lightmapping.
Each sprite's lightmap is made up of the layers that provide the appearance of modeling, as well as any additional layers that simulate any sort of lighting-specific interaction between the sprite and its environment.
The lightmap needs to change to reflect either a change in lightsource direction or color and some other effects as well. By keeping the layers seperate, a greater range of subtleties can be achieved through fewer loaded resources.

When the lightmap is updated in realtime within the environment, the sprite will (hopefully) seem to be immersed in its surroundings.

I find it noteworthy to point out that I will not be using any gradient fills.

Refresh Rate
The bottom line is the framerate. Nobody enjoys choppy games. If engine performance suffers, the whole experience suffers.
Thus, all of this rests on what is best practice in terms of rendering speed.

Any warnings on the pitfalls of these plans or tips on optimizing the process are appreciated.

[DancingOctopus]

Wow, I haven't posted here in a while. Last time I was working with flash, I was trying to do something similar to what you're doing here with tile based dynamic lighting and light mapped sprites. I didn't get very far into it, so unfortunately nothing to show for my troubles. I'll be interested to see what you come up with

"Any warnings on the pitfalls of these plans or tips on optimizing the process are appreciated"

My suggestion would be to ensure the engine can efficiently bypass the light mapping routine so you give the option to turn it off on slower computers. I'd also suggest writing the code so that it can be executed at various intervals. What I mean is, instead of calculating lightmaps for evey object on every single frame, you could calculate them every 2nd, 3rd or even 4th frame, depending on the style and pace of game. This means you can have somewhat of a sliding scale of performance/quality.

[lesli_felix]

Cool thread,

I've been working on some similar ideas since f6 came out and gave us dynamic masks. I'll try and dig some of my old experiments up if I can. It's all doable, though I was using simulated curved surfaces and mixtures of curved surfaces to achieve similar effects.

This is a work in progress, but it uses some of the same techniques:
(Click the orange rectangle to turn off the lighting and see the base colour.)
http://www.brokenbutton.com/bugball11.html

Also, you have to check these bump mapping demos out (theyre not mine), I don't know how practical they would be in a game, but they're incredibly impressive:
http://www.bytearray.org/?p=74
http://www.unitzeroone.com/blog/flas..._included.html

As for advice, just keep it minimal, or at least use loads of one-off calculations for static surfaces, and keep the constantly re-calculated areas to a minimum to achieve the best effects.

[Q__Hybrid]

DancingOctopus,

Good suggestions. With regard to calculations, I have already considered options and have decided to use a simple system of "light" sprites that listen for a player's proximity. When the player is in range, the light map nearest the angle between the light and the player is applied using the appropriate percent. The lightmaps use eight-directional lighting, so all angles greater than zero and less than ninety snap to forty-five.

I was very impressed by the UnitZero example, but it's alot more than I had in mind. It's beautiful, beautiful overkill.

I hope to have something to show by next week. Better start scribbling.