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.

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.

I have no special talents. I am only passionately curious.--Albert Einstein

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org