I am designing a 2D game using directdraw. It is in an overhead view and therefore needs to show characters turning in all directions. In my previous games the animation was fairly simple, ie. 2-3 frames for walking. This meant that to let the character turn in 360 degrees I could manipulate the images myself and turn them in 9 degree increments which gave 360/9 * 3 = 120 frames.
However, in this game I wanted to have better animation – now I have 10 frames for animation and individually rotating each frame by nine degrees would mean too many to do by hand. Therefore I was wondering whether I could just load the 000 degree into the game and rotate the rest on initialisation by the software. I first tried to use the rotationangle variable of the ddbltfx struct but it returned norotationhardware. Have I missed something here or is directx meant to emulate missing hardware features?
So can somebody tell me what the best way to proceed would be and how to go about it?
Nope you are absolutely right. 2D Rotation requires hardware availablity(because MS couldn''t figure out how to write a fast enough 2D software emulated rotation function). If you really want hardware rotation, ''cheat'' a bit by using D3D.(sorry but i have no idea how to do it, I seen it in work though)
I also ran into this problem while I was programming a StarControl clone... Luckily I still remember how I solved the problem. Here are the steps you need to take -
1. Create an empty surface. (It will need to be bigger than the original surface containing the sprite) 2. Lock both the surface with the unrotated sprite, and the new surface. 3. Now, using these formulae, you can create new sprites for all your required rotations. Xt = X*cos(i) - Y*sin(i) Yt = X*sin(i) + Y*cos(i) Where Xt & Yt are the new coordinates. X & Y are the coordinates of the original pixel i is the angle of rotation.
This formula does work, however it rotates around 0,0 so you will have to offset it to fit on the new surface properly. Its just some simple trig!
Using the sin/cos transform suggested will work, however, I''d like to mention that you might want to do pixel averaging as well.
Since sin/cos will give decimal results, the pixel values will be rounded (well, truncated) and you''ll have several pixels end up mapping to the same location. The fastest solution is just to let the last pixel that maps to a location win. Or you can average the rgb values. Or you can do some blending to get nice results too. (They''ll probably all look fine. It''s just a question of how much of a perfectionist you are.