Hey Kamilche, I don't have code that handles rotations correctly in front of me now, but I had the same problem as you before I realized what pygame's rotozoom was doing...
basically those pygame transform routines rotate and zoom from the center of the image. Also, the rotated image is larger (imagine you take the rect of the image, and rotate it 45% around the center, see how the corners of the rotated rect are outside the original? So the pygame routine is finding a new larger axis-aligned rect that can contain those repositioned corners, note that this also means if you keep rotating rotations the image continues to grow in size). However, since the origin (0,0) of the image is always the top-left pixel, it means that the image is being shifted down & right in order to make the image. So basically the routine is both rotating/zooming the image from the center, AND translating the image on the diagonal. You are probable accounting for the rotation about center, but not for the translation due to the size change. In my opinion, the simplest way to figure out how much the image has been translated, is to use the width & height's of the original and the transformed image. I *think* the algorithm that worked for me was this (this isn't working python code unless you have a vector class that overloads math ops, I just didn't want to write out stuff for both x & y positions) ---------------------------- center = (original_image.width/2, original_image.height/2) position_relative_center = position - center rotated_position_relative_center = position_relative_center.rotate(angle) new_center = (transformed_image.width/2, transformed_image.height/2) rotated_position = rotated_position_relative_center + new_center On 6/19/06, Kamilche <[EMAIL PROTECTED]> wrote:
Andre Roberge wrote: > Ok, here's a quick stab at it... I couldn't get that to work. Maybe it's something else.
