[Nuke]

I might argue that code for procedural 2D shield icons would require additional processing, more so than the conventional method already implemented. Thus, when you have a program getting progressively more taxed that runs on a single core...

But this might be unjustified. My thoughts are this: The ship's top down view will have full opacity factor, apart from any typical FS HUD opacity. It is thus a "solid" bitmap with a background of... zero opacity! If it is possible to write a code that can draw four quadrants with vairable strength gradients that doesn't take up too much processing power, then you might have a winner.

The code would need to do the following:
- Find the center of the bitmap. Very simple mathematics here, just divide the resolution by two on both the x- and y-axis of the bitmap, and place the center coordinates there.
- From this point, quadrant vectors are drawn at 45 degree angles from forward, at 90 degree separation. Or you could make an angular spacing function based on bitmap resolution.
- The absent background opacity is detected by the code, and a shield "gradient" is drawn from the ship's central coordinate. The start of the quadrant image is drawn a pre-determined distance from the full-opacity ship icon, and extends to an appropriately determined length.

Thus, any ship icon, asymmetric or not, could be drawn with a shield. That is, if you could code it, and it would not use more resources than necessary.

its more of a memory vs c/gpu cycles tradeoff. whats more important, cycles, or texture memory? even then the game is dealing with hundreds of models, hundreds of thousands of polygons, hundreds of megs of bitmaps, i dont think rendering a little 256^2  icon is going to matter much for performance. i dont think these icons, procedural or not, tax the game all that much.

if you can draw an opaque pixel, you can draw a transparent one too. thats trivial. if you want to do a simple radial gradient with quadrant masking, thats also fine (an improvement to those box icons), but i think it would look better if you could conform the shield to the shape to the ship, and i can think of a dozen rendering methods to do that.

[The E]

Well, but the point is, why keep rerendering this stuff every frame when you can do it once during mission load and cache the results?

[Nuke]

you could do it that way. you can then use a higher quality generation routine, and then draw with variable opacity, of course that kinda still uses up bitmap slots.

[The E]

Sure, but so do bitmap icons. Not much of a difference there, I think.

[headdie]

I must admit to being a layman when it comes to bitman and how it works so something like this might already be in play or impossible but seeing as we are generating the icons at mission start can we store the generated icons in a kind of image array, basically a big single layer image with all the permutation of each ship icon in a row, then under that the same for the next ship and so on.  If it would work a file storing 4 would cut the number of bitman slots used by shield icons down by a quarter and so on.

If you clamp the generation code to use a set pixel dimension, say 32x32 then the code would be able to assign to the ship class the file name the icon is stored in and the row say Shields2 row 3.  because the icons are a uniform size the game would know that if it goes down to pixel row 96 that is the start of the shield icons for that ship class.

[Aardwolf]

Well, but the point is, why keep rerendering this stuff every frame when you can do it once during mission load and cache the results?

What about glowpoints/animations? Are those reflected in the generated shield "icon" ?

[sigtau]

Seeing as the icon is a five frame ANI... no.

[Aardwolf]

Seeing as the icon is a five frame ANI... no.

Well, but the point is, why keep rerendering this stuff every frame when you can do it once during mission load and cache the results?

Is it even an ANI?



And I remember seeing blinking lights on something... it might have been something with 3d ship select, though.

[The E]

Right now, they are (Animations, anyway, I don't think glowpoints are rendered there. Or that they are visible enough to register at those sizes).

But there's a problem with that: It's really not efficient. As an extreme example, take "The Blade Itself" from WiH. Go to external camera, and target the other Karuna in the mission. Suddenly, you have four Karunas rendered in realtime on your screen, with all the geometry- and texture uploads that entails. For a model as horrifyingly bad as the Karuna, this is a performance concern.

Now, granted, that is an extreme case, and it's not really all that relevant during normal gameplay. But as I see it, this is more about improving the look of the default shield icons the engine creates, which is pretty ugly. And, speaking for myself, I would rather trade a bit more memory usage for speed any day, thus my recommendation to render them once and store the results.

Seeing as the icon is a five frame ANI... no.

Well, but the point is, why keep rerendering this stuff every frame when you can do it once during mission load and cache the results?

Is it even an ANI?



And I remember seeing blinking lights on something... it might have been something with 3d ship select, though.

sigtau, plz to read thread. This is about the icons the engine generates when there is no icon specified in the tbl. These consist of 4 shield brackets, and a live rendering of the model. I'd rather take a little bit of time and render the 5 frames a normal shield ani has during mission load than having to rerender all of this stuff every frame.

[Nuke]

i have nothing against the generate and cache mentality, because it solves the problem nicely and has the added bonus of being scalable to match the screen resolution, so you still get some benefits over traditional icons. you just dont save any texture slots.