dougeff wrote:1. have 2 separate arrays for each flip state (faster to draw, but takes up more bytes of ROM) that already has the H flip bit set.
2. subtract each x coordinate from a central x point (slower, but needs 1/2 the ROM space)...and also set the H flip bit for each sprite.
So, FWIW, I prefer the latter option, mainly because if you have enough sprites the extra space becomes pretty significant.
Naively, a metasprite is 4 bytes per tile. Maybe a typical one has 4 tiles? 16 bytes per sprite for an extra flipped version adds up pretty fast.
On the other hand, a metasprite drawing routine is probably only ~60 bytes total. So, what I did is copy-paste my sprite routine and make a separate flipped version that's different in the following ways:
- input X = X + 8 (+4 cycles per metasprite)
- subtract metasprite tile X from input X instead of add (same number of cycles)
- XOR the attribute byte for flip (+2 cycles per tile)
So, the "slower" aspect is really quite minor (~12 cycles per sprite), and the code/data trade begins paying off at only 4 sprites or so.
There's other ways of doing it, and if your game is not horizontally oriented you might want vertical flips as well, etc. but generally I find it pretty worthwhile to have two routines. If you want to spent a few more cycles per tile, you could even share most of the code between the two routines, saving even more space. You could even piggyback a palette swap option into the attribute XOR... there's lots of ways to customize this to suit your needs.