Rotation

Blitz3D Forums/Blitz3D Programming/Rotation

JeeyD

(Posted 2012) [#1]

So, got away with quads for a moment of curiosit trying to get a 2d rotation done by hand.
After trying million variants of different rotation algos this is that seemed to stand out and it should work splendidly but somewhere a bug slipped inside
accidently somewhere and now really stuck, any Mathematicians or anyone who knows great deal of these things perhaps recogonize what it could be?
Grateful for any ideas really.

Any ideas?

; 2D bitmap rotation

; Create a screen
Graphics 1024,800
Cls : For temp=0 To 999 : Color Rnd(255),Rnd(255),Rnd(255) : Plot Rnd(400),Rnd(400) : Next

Repeat
	lockbuffer
	rotate(200,200,64,64,400,400,a#)
	a#=a#+1
	unlockbuffer
	vwait
Until MouseDown(2)

Function rotate(srcx,srcy,width,height,destx,desty,theta#)

h0 = height : w0 = width ; SIZE OF SOURCE box to rotate (starting srcx,srcy)
h1 = w0 * Sin(theta#) + h0 * Cos(theta#) : w1 = w0 * Cos(theta#) + h0 * Sin(theta#) ; SIZE OF DESTINATION box (starting destx desty)

; init few used variables
fsin# = Sin(theta#) : fcos# = Cos(theta#)
c1# = (w0 - w1 * fcos# - h1 * fsin#) / 2.0 : c2# = (h0 + w1 * fsin# - h1 * fcos#) / 2.0 : ex#=0 : ey#=0

; i and j loops loops thru destination box, dot by dot
; fx and fy is used for outer loop, ex and ey is used for inner loop, used to control m and n
; m and n is used for actual integer pixelcoordinates

For i = 0 To h1-1
	fx# = i * fcos# + c1# : fy# = -i * fsin# + c2#
	m=Int(fx#) : n = Int(fy#)
	If (fx# - m) > 0.5 Then m = m + 1
	If (fy# - n) > 0.5 Then n = n + 1
        ex# = fx# - m : ey# = fy# - n
        For j = 0 To w1-1
		x=ReadPixelFast(srcx+m,srcy+n) ; (This could also using any kind of interpolation using ex#,ey# like so x=anykindofinterpolation(srcx+m,srcy+n,ex#,ey#)
		WritePixelFast destx+i,desty+j,x
                ex# = ex# + fcos# : ey# = ey# - fsin#
                If ex# > 0.5 Then m = m + 1 : ex# = ex# - 1
                If ey# < -0.5 Then n = n - 1 : ex# = ex# + 1
        Next
Next

Return
End Function

Last edited 2012

Last edited 2013

Last edited 2013

Last edited 2013

Last edited 2013

JeeyD

(Posted 2013) [#2]

Generalized and cleaned code up, tried several ways changing it to work but still no results.

It's interesting and it is fun but still frustrating when getting stuck.

Anyone know of these things? It's supposed to actually rotate a 2d box of pixels, and do it amazingly, not just any old sin/cos rotation this.

Bobysait

(Posted 2013) [#3]

Strange behavior ... and hard to understand what you 're looking at

whatever :
You locked the buffer and don't use any flip.

replace your "main" program with this

Graphics 1024,800
Cls : For temp=0 To 999 : Color Rnd(255),Rnd(255),Rnd(255) : Plot Rnd(400),Rnd(400) : Next  ; Make a screen to test on

Repeat
LockBuffer
rotate(200,200,64,64,400,400,a#) ; rotate box 200,200, width=64, height=64, into destination 400,400 (size of destination box becomes the space rotation needs)
UnlockBuffer
a#=a#+1
Flip True
Until MouseDown(2)
End

ps : use [ codebox ] [/ codebox] (without space) to create a codebox

Last edited 2013

Midimaster

(Posted 2013) [#4]

do you know, that there is already a rotation command in BitzBasic: RotateImage()? I think Mark did the best, what is possible with this language. All your tries will be slower.

Bobysait

(Posted 2013) [#5]

@Midimaster :

I think Mark did the best, what is possible with this language. All your tries will be slower.

That's wrong. blitz provide lots of functions (fast for most) but all are "generic" functions. Everything designed to a specific task generally gets faster when you code it by yourself.
BTW, the blitz rotateimage is one of the slowest blitz command (and does not allow buffer to be rotated, it works only for images).

JeeyD

(Posted 2013) [#6]

I want to make sure you know both that BB has inbuild and there's ways using 3d hardware to get what looking for here. This is purely conceptual and fun learning rotate with extreme precision of pixels. (They often mess up when rotate, and even more when using AA/interpolation if done wrong)

None of the above is what this code is about, it's just simple raw pixel manipulation to do 2d rotation in a rather innovative fashion. It where almost working at one point so I know its just some bug that creeped inside.

Just sharing and wondergin if anyone know these things.
If you're slightest interested in pixel manipulation whith good style, you should give this code some eye and some time.

JeeyD

(Posted 2013) [#7]

Bobysalt no that would mess things up. I tried just to be sure what I recognized. Lockbuffer just locks any buffer to allow fast access, here i unlock frontbuffer.

What I *did* wronlgy perhaps was to not unlock it before exiting the
program, but BB has automatic resources freeing up things like that.

Your example flips and without clearing redrawing, plotting comes on alternating front/back with time.. flickering till it's all gone.

setbuffer backbuffer() is the one that needs FLIPping. Don't use that here.
Locking is just locking.

Just wanted to point it out so no missundestandings.

I'm back to the drawingboard with this routine.. tough stuff.

Any help at all would be most wonderful and appriciated.

Bobysait

(Posted 2013) [#8]

Sure, I just wanted to point the missing "Unlockbuffer"
I didn't care for what it should look
At the moment, I only had a black screen running your code.

JeeyD

(Posted 2013) [#9]

That aside, any ideas about the actual algorithm itself? It uses a technic that is one of the candidates about to go into hardware directly. With floats and integers mixed up. The speed is about 1-to-1 to what it takes to access actual pixels not much overhead as you would think with involved floats..

JeeyD

(Posted 2013) [#10]

Changed the code to something should be able to run on any Windows any driver any blitz. It should fit everyone and not getting a total black.

What it does is rotate (a supposed rotation) a box of graphics 200,200 - 263,263. projecting it into a new box at 400,400 (and uses whatever size it needs rotation, it calculates it first few lines)

Sadly as it is now it gives something that looks more like what a blackhole would look like from within. A nice effect in which you despite all this still see the smoothness of the algorithm. But as some character slipped in, ain't no rotation no more.

Last edited 2013

JeeyD

(Posted 2013) [#11]

Solved the problem, just change the first +'s into - - and change order of ex# , and forces m and n use positive integers before calculating deltas, then you have the rotation going :).