SDL surface rotation code

I got it to work on windows (easy - there is no platform specific code in it).

I made a test application to try your code versus SDL_rotozoom, yours is faster than SDL_rotozoom when rotozoom has anti-aliasing on. On my machine, a 512x512 image rotates at ~23 FPS with anti-aliasing rotozoom, and between 23-30 fps for your version. However, SDL_rotozoom with no anti-aliasing renders faster, at 34-37 fps. In addition, your version looks more aliased than rotozoom whether it has anti-aliasing on or not.

Your test image and program uses transparent white pixels, so you don't see this, but you don't make room for the full final image. My test image has its corners taken off it.

Your draw_rotated function couldn't seem to handle the case where the source and destination have different bit depths.

Next on a coding style note, you have made a class with no members to contain your functions. Why? There usually is no reason to do this, use a namespace instead. I would consider it strange if a library printed error messages to the standard error stream. Again, don't do this. If the error is critical enough, throw an exception. Otherwise, trust the client code to check the return value.

So: its a good start, but needs a bit more work.

You should note also that it isn't "free to use if you find it useful" - because it is under the extremely strict GPL. Licences such as zlib are less restrictive for end users. To use your code I would have to make my programs GPL. One of the reasons for SDL's success (IMO) is that it is LGPL rather than the GPL. While the final decision on licenses is up to you - I think the number of people who will use your code is inversely proportional to the strictness of the license.

Thanks for the feedback! :) I'll make some modifications to the next version.

BTW, I can see no errors with the corners...thats weird. I tried with another image. The code _does_ make room for the result. Maybe I'll do some more tests..


Edit: I changed the license to LGPL and fixed some bugs. Reality is hard for a coder :)













[Edited by - riserbar on March 9, 2008 10:56:03 AM]

Much nicer! The quality seems comparable to SDL_rotozoom now, and the ability to write to a pre-allocated surface is a great improvement.

I still think you should drop the class, and just put the functions in a namespace. The member variables you have shouldn't be member variables because they don't represent state, they are temporaries. Don't worry about reducing the number of variables, let the compiler do that for you. Don't use "register", the compiler is free to ignore it, besides the compiler knows far more than you about that kind of stuff. Also, don't write an empty destructor for a class (unless you are starting an inheritance hierarchy and need a virtual destructor but it has nothing to do). The compiler will generate a constructor if necessary that will call the destructors (if any) of each member variable.

Pixels should take the type "Uint32" when working with SDL, to keep consistent among the SDL functions that take pixel arguments.

Other than those minor issues, it works great. [smile]

Ok, many thanks for your suggestions again :) I'm already working on the next version and planning to add some zooming options, too.