Smoke.

[Argh]

OK, Spring devs... and here, I'm mainly asking anybody who's worked with the particle system... how, exactly do the smoke puff graphics work?

Why? Because I want to see if there are better ways to optimize them for my mod, of course

Sooo... I have done some basic experiments, and learned several things:

1. These are Indexed BMP files.
2. The indexes used seem to actually matter. Substituting new ones does not work correctly.
3. The colored ones, very unfortunately, do not take switching to grayscale correctly.
4. They are not sized to a pane, and stretched to fit. Instead, they are projected onto the pane and appear to take up as much "room" as their bitmap vs. a field of some kind. IOW, making them bigger/smaller doesn't work, as it does with most particle effects I am familiar with.

Um... any explanation (or, better yet, whatever PAL files were used, since it appears that the indexes aren't arbitrary) about how these work would be helpful. Even better... if these could be recoded so that:

1. They no longer are indexed BMP (I'd prefer TGA, even 8-bit TGA, because it has an alpha built in, but ideally, it'd use the same DeVil stuff everything else is going towards).

2. They stretch to the panes, instead of being larger/smaller based on raw bitmap size. If we want larger, we should (yes, eventually, maybe, if developers feel like giving us modders control over this area of content) be able to alter that through parameters passed to something in a (admittedly vaguely-defined and highly idealized) particle system... so, for example, if I'm making a big, slow-rising smoke particle system, I'd specify the "panesize" in whatever scripting system we (theoretically, hopefully) develop to make, configure and control particle systems.

3. Should be configurable to call any given texture file that contains an RGB and Alpha channel. Using two seperate bitmaps seems like a kludge to me, although I am open to arguments otherwise. Every other game engine I've worked with has used this arrangement for particle FX, though.

At any rate, feel free to ignore this one, devs, if you're already working on a newer, better particle system, but if we're going to keep the current one for awhile, I'd like to know how the current smoke is defined, so that I can at least take a stab at optimizing it for my mod.

[Meben]

Indexes?

The field names in resources.tdf are hardcoded - there are exactly 12 smoke image/smoke alpha pairs. You can name them whatever, but you're stuck with splitting off the alpha channel. (This would be easy enough to fix.)

Spring uses CBitmap to load the smoke textures, so you shouldn't need to use indexed BMPs.

ProjectileHandler::LoadSmoke assumes the images are 32x32, or rather reads the first 1024 pixels.

What do you mean by panes?

(I turned the first smoke image green, painted a smiley face on it, resaved it as mySmoke.png and changed gamedaata/resources.tdf. It works. And it's darned spooky, too. I'll never look at a geothermal vent the same way...)

[Argh]

Very useful, thank you.

As for "panes", I'm referring to projecting the bitmap onto a rectangle, like most game engines seem to do.

[Argh]

Ok... another question. If the smoke bitmaps could be several sizes (say, 16, 32, 64 and 128 at the largest) and were thus shown in different sizes, instead of being dynamically resized/filtered, would that perform better or worse than the current system? Seems like a lot've people's complaints about smoke are when there are literally 100+ particles on-screen at once, being dynamically resized every frame.. if the "tween" steps were fewer, might that not help things a bit? I'm probably terribly wrong there, but the last two games I modded used DDS LODs for particles, which seemed to work really well.