Performance of Pre-Assembled Sprites vs. Run-Time Assembly

[Oskuro]

In my current project I need to have sprites subdivided into modular pieces to allow for variations. For example, certain monster categories can have different heads, yet the same body, or, more important, players can switch weapons and armor around, and these changes need show up on the player sprite.

Internally I'm handling the drawing of pixels manually, I extract the byte buffer form the application context and operate on it directly (as a single index byte array I dump data into using System.arraycopy loops).

My question is, of the following options, what is, performance wise, more adequate:

  a) Keep the pieces separate and assemble them each frame.
  b) Pre-generate all possible combinations at level load.

I haven't done benchmarking yet, but my guess is that a hybrid method would be best. Pre-generate monster sprites for a limited number of random variations (Say in each individual game execution there are only 5 variations per monster type, even if the available pieces could yield hundreds of combinations), and do the player character at run-time so all possible combinations are always available.

I've observed that sprite sheets for some games (Like old Zelda games) actually have all possible sprites pre-generated for the player. Then again, their possible combinations are simpler.


In any case, these seems like an issue of memory capacity (pre-generation) vs processor capacity (run-time). Are there any quirks or features of the JVM I need to know about that might tip the decision towards one or the other?


Note: No, I will not use higher order Java structures or library wrappers for graphics. Not for this project at least. On one hand I want to practice graphics management at as low a level as possible, and on the other, portability to C++ is one of my requirements, so the less dependencies, the better.


Edit: Typos

[sproingie]

c) When a new combination is needed, assemble it, render it to a new image (or set of images, if you're dealing with animation), and cache it in another spritesheet.

[delt0r]

I assemble on the fly. That is a "unit" is a set of sprites that are rendered (set of quads). Since i am no where near fill rate limited and it gives flexablity with relative movements, i didn't see the point of the complexity of assembling new sprites. 

Games published by our own members! Check 'em out!

[princec]

Assemble on the fly.

Cas

[Oskuro]

The problem I see is when a sprite needs to be quickly and arbitrarily updated on the fly (Again, I need to benchmark this, I'm just conceptualizing at this stage. For the sake of discussion, let's assume I'm trying to run this on a Blackberry device, and have very limited resources.)

Example, if a player character switches weapons, or gets the weapon (or its head) blown off.

Or, when in multiplayer a client gets an update with the info on nearby creatures and their structure (Say another players burst into the room being chased by an eclectic group of monsters, each sporting a different party hat).


In general I feel uncomfortable making several passes over the same pixels as I draw each piece on top of the previous one.

[princec]

FYI there are between 2000 and 8000 sprites in a single frame of Revenge of the Titans during a massive battle. Each object on the screen is made up from about 3-5 different sprites, drawn on top of each other and animated pseudoindependently.

Cas

[Oskuro]

Niiice. I'll just do what comes more comfortable then. Thanks