2d Bitmap rotation under DirectDraw
Author
HALLO! I would liek to rotate bitmaps in 2d with DirectDraw 7.
Is there anyone who has any clue as to how I''m going to do it?
plese halp!
I''m sorry to say that I don''t think there are any DirectDraw commands to let you do that with the same bitmap... (If anyone disagrees, please say so.)
You could make several bitmaps that are rotated versions of the original (as animation frames) and then display them consecutively. I don''t think that the Windows Paint application performs rotations, but the GIMP might--I''d have to look into that.
Hope that helps!
You could make several bitmaps that are rotated versions of the original (as animation frames) and then display them consecutively. I don''t think that the Windows Paint application performs rotations, but the GIMP might--I''d have to look into that.
Hope that helps!
Author
...Or i could always pre-do them as animation frames yes thats
a good option performance wise.
I wasn''t asking for a DirectDraw function to do the job though,
I was after a bitmap rotator in general (or a texturemapper)
a good option performance wise.
I wasn''t asking for a DirectDraw function to do the job though,
I was after a bitmap rotator in general (or a texturemapper)
Author
oh wait, I have a sprite with 3 animations at 16 frames each
as well as a still idle image
so thats 17,640 frames.
at 4.19 KB per frame, thats approx 72 megabytes just for
this one sprite and I really don''t think its worth it to be
honest.
as well as a still idle image
so thats 17,640 frames.
at 4.19 KB per frame, thats approx 72 megabytes just for
this one sprite and I really don''t think its worth it to be
honest.
how did you get 17,640 frames
from 3 animations with 16 frames in each animations
thats only 48 frames
at 4.19 KB a frame thats only 201.12 KB total
thats seems pretty low to me
from 3 animations with 16 frames in each animations
thats only 48 frames
at 4.19 KB a frame thats only 201.12 KB total
thats seems pretty low to me
I believe the 17,640 came from 49 frames multiplied by 360 degrees.
If you wanted to you could sacrifice on the rotation by doing the rotation in steps. Even if you did just 2 degree steps you would cut the frame count by half. 10 degree steps would knock the frame count to 1,764. Just a thought...
Just had another thought too. I'm pretty sure DDraw7 supports rotating an image on a multiple of 90 degrees. So you could just pre-rotate the first quarter-circle of the sprite. Then when blitting use an algorithm to figure out if you need to mirror the sprite on an axis. That way you get a whole 360 degree rotation. I hope that made sense.
Edited by - doombunny on February 20, 2002 2:36:24 AM
If you wanted to you could sacrifice on the rotation by doing the rotation in steps. Even if you did just 2 degree steps you would cut the frame count by half. 10 degree steps would knock the frame count to 1,764. Just a thought...
Just had another thought too. I'm pretty sure DDraw7 supports rotating an image on a multiple of 90 degrees. So you could just pre-rotate the first quarter-circle of the sprite. Then when blitting use an algorithm to figure out if you need to mirror the sprite on an axis. That way you get a whole 360 degree rotation. I hope that made sense.
Edited by - doombunny on February 20, 2002 2:36:24 AM
Author
Yeah, I could do it in steps, but I would prefer to have it
*perfect*. I used to have a routine that I converted from
a texture mapper from a 3d engine but I lost it.
*perfect*. I used to have a routine that I converted from
a texture mapper from a 3d engine but I lost it.
for (x,y) = pixel on the target bitmap T figure out (x0,y0) whence in the source bitmap S the pixel T(x,y) comes from ( e.g. x0 = cos(-angle)*x, y0 = sin(-angle)*y, if you arer centered at (0,0) ) plot the pixel at T(x,y) with the color from S(x0,y0), possibly with supersampling (e.g. averaging the neighbouring colors)
Well it''s your classical stupid ''copy the pixels from the original image, rotate them, write them in the target image'' algorithm, except that you are iterating over the target pixels instead of the source pixels so as to avoid any holes in the target image.
That''s clear enough I think.
Just remember to precompute sin and cos.
That''s clear enough I think.
Just remember to precompute sin and cos.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
