Rotating an image in 90 degree increments

90 degrees is easy and cheap, since all the image pixels will line up perfectly with the background pixels. So I'd probably rotate the images, rather than storing and working with pre-rotated images. Which graphics API are you using?

The method you use will depend on any limitations you may have for example, SDL doesnt support rotating surfaces (you would need an aditional library to do so) so using 4 tile images with the sprite rotating in all 4 directions would be your only option. Either way would be fine on todays computers.

Quote:

Original post by cNoob The method you use will depend on any limitations you may have for example, SDL doesnt support rotating surfaces (you would need an aditional library to do so) so using 4 tile images with the sprite rotating in all 4 directions would be your only option. Either way would be fine on todays computers.

Well you can certainly write the rotation routine yourself, all you have to do is access the surface data and blit it to the destination surface in the right order. If he only does it for surfaces with square dimensions with 90-degree rotations, the code will be very simple.

Actually, I am using SDL. I was just going to lock the surfaces and do the rotation myself. Since these rotations are simple to implement, I figured I wouldn't have too much trouble. Should I try to find a library that does it in the video card? I don't really want another DLL floating around.

Edit: Woops, my question was answered before it was asked! So I guess the only question is whether to do all the rotations in setup (and use 4 times as much memory), or do them for every sprite every cycle and save the RAM.

I doubt it will make a significant difference. Choose whichever is simplest.

Note that generally speaking, computation is fast and memory access is slow. While there is no reason to "save" RAM unless you're getting close to the amount of physical RAM you expect the target machine to have, generating prerotated images will probably lead to more cache misses, which can be about as expensive as generating them every frame - depending on the size of your cache and the amount of memory your game needs to shuffle in and out of it.

But this level of optimization is completely irrelevant for all non-scientific applications (and possibly the most demanding games on the market).

Alright, then, I'll rotate them for every cycle. Thanks for all the help!

I don't know how much SDL will let you do, but rotating an image 90 degrees is trivial. Hell, you don't even need to rotate it at all, you simply alter the way you draw it. As you read in the rows of pixels horizontally, display them verticaly. This is, effectively, 90 degree rotation without any overhead at all. I do not know if SDL would let you do that, though (somehow doubt it).

Do whatever is easiest to do. Performance isn't going to be an issue in any case; this is just another case of the classical trade-off between more CPU usage or more Memory usage.

Hnefi's right that computation is generally quicker than memory access these days, but the fact is, due to the memory access patterns involved, you're probably going to thrash the hell out of the cache doing rotation at run-time anyhow... Its impossible to predict which will be faster without profiling.

I wouldn't be too hesitant to use the extra memory if it were me... I mean, how many of these 32x32 images do you have? multiplying by 4 on the PC platform is probably not even a blip on the radar... Thats the same increase you'd see when increasing the number of MIP levels on a texture by one, its not even really anything to blink at these days.

Quote:

Original post by Ravyne ... Hnefi's right that computation is generally quicker than memory access these days, but the fact is, due to the memory access patterns involved, you're probably going to thrash the hell out of the cache doing rotation at run-time anyhow... Its impossible to predict which will be faster without profiling. I wouldn't be too hesitant to use the extra memory if it were me... I mean, how many of these 32x32 images do you have? multiplying by 4 on the PC platform is probably not even a blip on the radar...

My game is pretty simple at the moment, but I eventually plan on having many kinds of sprites, each with several frames of animation, all of which need their graphics in memory.

But you made me realize that most of what is involved in my rotations is not computation, but memory copying. I think I'm going to try it both ways and profile it. Finally gonna have to learn how to use the thing.