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." ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
