[CSDb] - User Forums - Point rotation

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Point rotation

2009-07-07 20:56

Axel
Account closed

Registered: Apr 2006
Posts: 42

Point rotation

How can I rotate point by fixed axis? how calculate new x and new y coordinates in assembler?

... 10 posts hidden. Click here to view all posts....

2009-07-08 18:33

Oswald

Registered: Apr 2002
Posts: 5076

Jackie, brilliant. but why not precompute the coords into polar. giving:

x = c[X]
y = s[Y]

and while we're at it, why not precompute the *2 *3 *4 tables aswell.

2009-07-08 19:39

doynax
Account closed

Registered: Oct 2004
Posts: 212

Quote: Jackie, brilliant. but why not precompute the coords into polar. giving:

x = c[X]
y = s[Y]

and while we're at it, why not precompute the *2 *3 *4 tables aswell.

Sure, that works too. It just eats a bunch of memory.

The most straightforward method is to avoid recomputing anything each frame, as you suggested, and instead just keep a full set of scaled sine and cosine arrays with double the normal period in memory.
That way the load's address specifies both the point's distance (e.g. the table number) and relative angle (the table offset.) With an index register to animate the rotation.

The obvious drawback here is that you won't be able to animate the scaling. Well, that and fact that it eats quite a bit of memory.

Perhaps the most interesting possibility of this setup is that it allows you to precalculate significant portions of the pixel addressing calculations, though come to think of it with you might not actually save any cycles when working with a clever char layout. Plus that approach would waste *even more* memory and prevent the usual space-saving trick of overlapping the horizontal (cosine) and vertical (sine) tables.

2009-07-09 05:31

Oswald

Registered: Apr 2002
Posts: 5076

well, Axel wasnt asking for scaling, and wasting memory is no problem as long as it speeds up the routine :) I would waste happily 16k for tables in such a demopart. Regarding speed/scaling/mem usage Jack's method is the best indeed.

precomputing addies made me think, the routine would look like this for a 32x25 screen, first part setting dot&presetting dot clear code, 2nd part is clearing the dot.

lda YtabLo,x
sta $fe
sta clrspeed+wherever
lda YtabHi,x
sta $ff
sta Clrspeed+wherever
ldy Xoffset,x
sty Clrsped+wherever
lda ($fe),y
ora Mask,x
sta ($fe),y
...
...

clrspeed

ldy #Xoffset
sta bitmap,y
...
...

edit: oh my its bugged, and keeping Y zero might be faster, I'll leave it to you :)

2009-07-09 06:38

doynax
Account closed

Registered: Oct 2004
Posts: 212

I was thinking something more along these lines:

plot	lda sincos_hi(a,s),x
	sta $ff
	sta clear+1
	ldy sincos_lo(a,s),x
	sty clear+2
	lda sincos_bit(a,s),x
;	ora ($fe),y
	sta ($fe),y

	.
	.
	.

clear	sta $ffff

With, say, 128 angles and 48 scales this would eat 36k of memory for the tables alone.

A nice point is that for static objects you could figure out ahead of time which plots might potentially intersect and thus avoid the ORA in the majority of the cases. That is if you wanted to bother with masking to begin with.
For the last 127 plots or so you could store the full address in a unique zeropage location and reuse it directly in the clearing code, saving something like three cycles per plot.

In the end you might squeeze 500 or so plots out of it, but the size of the plot code alone would almost kill you. And in the end it would look pretty lame compared to a comparable 3D plotter in which you'd get full 3D rotation and scaling for half that number of vertices.
But perhaps it might pay off if you wanted to plot into some byzantine sprite-based screen layout, with complex clip regions and color-effects based on the screen coordinates.

2009-07-09 17:11

Axel
Account closed

Registered: Apr 2006
Posts: 42

Thanks for your help :). Nice ideas, now I will try to do it

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread: