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
