views:

480

answers:

3

Hello all. I am working on a top-down view 2d game at the moment and I am learning a ton about sprites and sprite handling. My question is how to handle a set of sprites that can be rotated in as many as 32 directions.

At the moment a given object has its sprite sheet with all of the animations oriented with the object pointing at 0 degrees at all times. Now, since the object can rotate in as many as 32 directions, what is the best way to work with that original sprite sheet. My current best guess is to have the program basically dynamically create 32 more sprite sheets when the object is first loaded into the game, and then all subsequent instances of that type of object will share those sprite sheets.

Anyways, any advice in this regard would be helpful. Let me know if I need to rephrase the question, I know its kindof an odd one. Thanks

Edit: I guess for more clarification. If I have, for instance an object that has 2 animations of 5 frames a peice, that is a pretty easy sprite sheet to create and organize, its a simple 2x5 grid (or 5x2 depending on how you lay it out). But the problem is that now those 2 animations have to be rotated in 32 directions. This means that in the end there will be 320 individual sprites. I am going to say that (and correct me if im wrong) since I'm concerned about performance and frame-rate, rotating the sprites on the fly every single frame is not an option. So, how should these 320 sprites that make up these 2 animations be organized? Would it be better to

  • Think of it as 32 2x5 sprite sheets
  • split the sprite sheet up into individual frames, and then have an array the 32 different directions per frame (so 10 arrays of 32 directional sprites)
  • Other....?
  • Doesn't matter?

Thanks

+2  A: 

You can just rotate the sprites directly by setting the rotate portion of the sprite's transform.

For some sample code, check out the Chimp sprite in this pygame tutorial. It rotates the sprites when the Chimp is "dizzy".

Reed Copsey
Alright, I mean that works. But honestly, I was already doing that, I guess my question is how to organize the sprites and their rotations in the most effective way... maybe I need to rephrase it
Jurassic_C
+2  A: 

The 32 directions for the sprite translate into 32 rotations by 11.25 degrees.

You can reduce the number of precalculated images to 8 you only calculate the first 90 degrees (11.25, 22.5, 33.75, 45.0, 56.25, 67.5, 78.75, 90.0) and use the flip operations dynamically. Flips are much faster because they essentially only change the order an image is copied from the buffer.

For example, when you display an image that is rotated by 101.25 degrees, load the precalculated image of 67.5 degrees and flip it vertically.

I just realized that this only works if your graphic is symmetrical ;-)

When talking about a modern computer, you might not need to optimize anything. The memory used by precalculating the sprites is certainly negligible, and the cpu usage when rotating the image probably too. When you are programming for a embedded device however, it does matter.

Otto Allmendinger
I don't know why it didn't occur to me to only prerotate the first 90 degrees. Good thinking ;)
Jurassic_C
+1  A: 

Typically you will sacrifice either processor time or memory, and you need to balance between the two. Unless you've got some great limit to your processor or you're computing a lot of expensive stuff, there's no real reason to put all that into the memory. Rotating a few sprites with a transform is cheap enough that it is definitely not worth it to store 32x as much information in memory - especially because that information is a bunch of images, and images use up a lot of memory, relatively speaking.

Eli