Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: MGOS on January 07, 2012, 08:54:33 am
-
I wanted to test the tan-1 function in the latest version of axe and tried to rotate a spite with this little program:
:ClrDraw
:Draw sprite with size E*F at (0|0)
:For(A,0,E-1)
: For(B,0,F-1)
: If pxl-Test(A,B)
: sqrt(4*A*A+(4*B*B))->D .four times precision
: arctan(A,B)->W
: W+32->W .Let's rotate that 45 degrees or whatever you like
: sin(W)*D//512->Y
: cos(W)*D//512->X
: Pxl-On(X+32,Y+32) .A little offset
: End
: End
:End
:DispGraph
I tried it with only a box and it works, ut this gives me some really bad quality results. When I try to rotate pictures, it is even worse.
Where is the fault in my program? Are the trigonometry functions to low resulution? The square root?
What can I do to make it better?
-
why are you using arctan?
My rotation routine.
cos(O)->C
sin(O)->E
For (L,0,R)
Pxl-on(({L+L1}-32->G*C)-({L+L1+1}-32->M*E)//128+48,(M*C)+(G*E)//128+32)
L++
End
Where i have indexed all the points used in L1, because my picture was small. {2*n+L1} are x, while {2*n+L1+1} are y values.
-
Ok, thanks. I will try that out.
Edit: works :)
Btw I used the arctan to calculate the angle between each point and (0|0), then add an offset to that and draw it down. So basically I transform it to polar first, add the angle I want to turn, and retransform it to rect again.
And you are actually doing that:
X = (XI * cos a) - (YI * sin a) + XOffset
Y = (YI * cos a) + (XI * sin a) + YOffset
Right?
-
Not all pixels are being mapped to because you only Pxl-On if there was a Pxl-Test. This restricts sprites to have the same number of pixels in the best case even though there could be a lot more when the sprite is rotated and I'm not even including the overlapped pixels. Instead what you have to do is get a bounding box of the destination zone (which could be the whole screen) and then run for loops over the region to see if each destination pixel belonged to the original image. So you need to find the inverse in your eqaution first of all:
XI = ([X - XOffset] * cos a) + ([Y - YOffset] * sin a)
YI = ([Y - YOffset] * cos a) - ([X - XOffset] * sin a)
Something like that... So you for loop over the X and Y bounding box, pixel test if (XI,YI) is shaded, and if it is, fill in (X,Y)
-
nope, but very close!
Pxl-on(({L+L1}-32->G*C)-({L+L1+1}-32->M*E)//128+48,(M*C)+(G*E)//128+32)
the bolded is the point of rotation
the //128 scales it down because programming trig and math class trig are different, as programming trig (at least here) doesn't use a decimal point.
i have all those extra variables for speed improvement. when going through a loop many times, especially for larger pictures, it can provide a big speed boost.
Quigibo. are you sure you don't have your plus and minus sign mixed up?
-
I have a question concerning this particular routine. Would it work for 8x8 sprites?
EDIT: Also how would go about it so that when I press a button the rotation occurs to a certain degree depending on how long u held it for?
-
I have a question concerning this particular routine. Would it work for 8x8 sprites?
EDIT: Also how would go about it so that when I press a button the rotation occurs to a certain degree depending on how long u held it for?
Yeah, of course. This routine works for any sprites, any size. If you store each black pixel's coordinate to the memory before the main loop, it'll be much faster.
-
I have a question concerning this particular routine. Would it work for 8x8 sprites?
EDIT: Also how would go about it so that when I press a button the rotation occurs to a certain degree depending on how long u held it for?
Yeah, offcourse. This routine works for any sprites, any size. If you store each black pixel's coordinate to the memory before the main loop, it'll be much faster.
Nice one. Now add grayscale, zooming and skewing.
-
How fast does this routine runs btw? I'm curious if it could be used in games?
-
I don't know the exact numbers, but for up to 64 pixel sprites it works quite well in my games.