Jump to content
  • Advertisement
Sign in to follow this  
theOcelot

Rotating an image in 90 degree increments

This topic is 3786 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm not sure If this is the right place to ask this, but exactly how computationally expensive is flipping an image or rotating it 90 degrees? I know that it would be pretty simple, but is it simple enough to do many times per cycle? We're talking small images, 32x32. I'm working on a simple tile-based game, so the only versions of any creature image I need are north, east, south, and west. I figure If I can rotate the image to where I need it, instead of drawing it in all four directions, the image files will be easier to handle and draw, and I'll generally be happier. Or I could pre-load a surface with all the rotated versions. Which will work best?

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!