[Gambas-user] the math behind full screen rotation

[Doriano Blengino]

Il 26/03/2011 04:08, Kevin Fishburne ha scritto:
> On 03/24/2011 12:05 AM, John Spikowski wrote:
>    
>> On Wed, 2011-03-23 at 23:03 -0400, Kevin Fishburne wrote:
>>
>>      
>>> That will probably work, but there should be a mathematical way to
>>> compensate for not cropping the image twice, or even once. As long as
>>> the entire image is preserved by the rotation function (it is) and it
>>> behaves in a predictable manner (it does), the camera's coordinates
>>> should be able to be translated and rotated so that they are in the same
>>> position in the rotated image as they were in the non-rotated image. For
>>> the sake of efficiency that is what I'm trying to accomplish.
>>>        
>> This thread might help. (or not)
>>
>> http://forums.libsdl.org/viewtopic.php?t=2983&sid=1d2c6a94470c0fd56f3f542cd702ec37
>>      
> No go, but thanks for trying to help. Right now my code looks something
> like this:
>
>     ' Convert camera coordinates to their distance from the center of the
> tile grid.
>     newcx = newcx - (bworkspace.Width / 2)
>     newcy = newcy - (bworkspace.Height / 2)
>
>     ' Rotate camera.
>     newcx = Cos(Rad(- Client.orientation)) * newcx - Sin(Rad(-
> Client.orientation)) * newcy
>     newcy = Sin(Rad(- Client.orientation)) * newcx + Cos(Rad(-
> Client.orientation)) * newcy
>
>     ' Adjust the camera coordinates to fit the rotated tile grid.
>     newcx = newcx + (brotated.Width / 2)
>     newcy = newcy + (brotated.Height / 2)
>
>     ' Draw the rotated workspace centered on the camera and cropped by
> the render window size.
>     Draw.Image(brotated, 0, 0, swidth, sheight, newcx - swidth / 2, newcy
> - sheight / 2, swidth, sheight)
>
> First I figure out the distance of the camera from the center of the
> non-rotated image. Then I rotate the camera using those distance values
> as the camera's coordinates. That should in effect make the center of
> the non-rotated image the origin of rotation. I then take the rotated
> camera values and add them to the center point of the rotated image to
> determine the camera's position in the rotated image.
>
> Maybe my logic is wrong, maybe it's my math. Maybe demons are hovering
> over my shoulder casting black magic. I'm about to hit up Facebook for
> an old math whiz I knew in high school, as gamedev.net has failed me as
> well.<blood curdling Arnold scream from Predator>
>
>    
Dear Kevin,

if I well understand, you have to rotate your world around the player. 
To rotate a point around another arbitrary point (different from the 
origin), you must first translate the point, then rotate it, then 
translate it again in the original position. If you want I can give you 
a working routine to do so. Your code seems to do something similar, 
but... should not the player always stay in the middle of the screen? If 
so, you need not to translate anything, but just rotate the original 
image. Or, perhaps, you want to reduce scrolling, so the player is not 
always in the middle? If there is not a true motivation, due to some 
game concept, to have different x/y positions of the player inside the 
screen, then it is much simpler to always keep the player in the middle. 
I try to explain in other words. Suppose that you can't get enough 
framerate when you rotate the world, so you try to minimize this, and 
let the player move around the screen. When the player reaches the 
boundary of the screen, you update the whole screen. Doing so, you speed 
up considerably. Nevertheless, when the player reaches a boundary, you 
must invoke anyway the "slow" routines to update the world. The net 
result is a stiffy game, which alternates fast movements with slow ones. 
I am also confused by our previous thread, where you rotated the player 
instead of the world. Not knowing enough, I can only say that you can, 
perhaps, gain some speed by doing calculations in the dead times 
(delays, if you have/use them). I have read that you reach speeds as 
high as 200 FPS or similar... if you reduce FPS to 25, you gain a lot of 
spare time to calculate ahead the new scenes (or perhaps not). If you 
explain better your ideas, may be I can try to give some advice.

Regards,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."