ROTATING IMAGES PMODE3
Re: ROTATING IMAGES PMODE3
That's very nice! Is it using some sort of 2x2 matrix to calculate the X and Y step?
Re: ROTATING IMAGES PMODE3
sin/cos lookup once per frame to calculate a deltax/y for a lookup into the texture
LOTS AND LOTS (a months worth) of nasty tricks to improve speed....
sin/cos are 8:8 fixed point that vary from 1 to -1 (360 degrees transposed into 256 steps)....
line start address table is 16bit
pixel translation tables etc etc etc....
i think if pere would post the vbscripts we use for the tables, then it might make a bit more sense (maybe not)....
for a good explanation of HOW the algo works you might try looking here:
http://www.drdobbs.com/architecture-and ... /184416337
LOTS AND LOTS (a months worth) of nasty tricks to improve speed....
sin/cos are 8:8 fixed point that vary from 1 to -1 (360 degrees transposed into 256 steps)....
line start address table is 16bit
pixel translation tables etc etc etc....
i think if pere would post the vbscripts we use for the tables, then it might make a bit more sense (maybe not)....
for a good explanation of HOW the algo works you might try looking here:
http://www.drdobbs.com/architecture-and ... /184416337
Re: ROTATING IMAGES PMODE3
Yes, it looks like what I'm thinking of, although expressed a little differently:
https://en.wikipedia.org/wiki/Transform ... x#Rotation
This was more like the way it was expressed in Nintendo documents.
https://en.wikipedia.org/wiki/Transform ... x#Rotation
This was more like the way it was expressed in Nintendo documents.
Re: ROTATING IMAGES PMODE3
lots of ways to perform a rotation... shearing is fast....
but this is faster...
the *bad* thing here is the 2bpp limit, so we have to spend time looking up 4 pixels in a texture and combining those into one byte to plot
essentially you just have a lookup that provides dx/dy for a given line through a texture (sin/cos)... once you know the X and the Y step, you just ADD the X and Y step....
all subsequent lines follow the same angle as the leader, the only thing that differs is the start point (but thats just a 90 degree relationship between sin/cos)
you ONLY need to rotate one single point per frame (upper left) so ONE sin/cos lookup PER FRAME.....
but this is faster...
the *bad* thing here is the 2bpp limit, so we have to spend time looking up 4 pixels in a texture and combining those into one byte to plot
essentially you just have a lookup that provides dx/dy for a given line through a texture (sin/cos)... once you know the X and the Y step, you just ADD the X and Y step....
all subsequent lines follow the same angle as the leader, the only thing that differs is the start point (but thats just a 90 degree relationship between sin/cos)
you ONLY need to rotate one single point per frame (upper left) so ONE sin/cos lookup PER FRAME.....
Re: ROTATING IMAGES PMODE3
Hello,
There are two different solutions applied, one for machines with just 32k
and another for machines with 64k.
The 'main' difference is that the image is converted into a 'texture' 128bytesx128rows = 16,384 bytes (16k)
Every byte representing a PIXEL, for speed reasons.
On 64k machines the image is converted into one big texture 256bytesx126rows = 32,256byte (about 32k)
The 2 rows reduction is done to avoid overwritting the SAM bytes ($FF00 on and FE00 on for CoCo3)
This change allows for very fast table access compared to the used for 32K machines
Being the texture that big, we cut it into two files that are loaded into RAM and copied to high RAM in MAP1
Once done, the program switches to MAP1 to start rotating the big texture.
I think that I would better upload here the source files that contain the tables, each with a description
of the equation that is implementing
Please feel free to put any question that could arise. I will look for the last VBS files used for each version ...
cheers
pere EDIT: Source for 32k UPDATED. Adding the VBS files
There are two different solutions applied, one for machines with just 32k
and another for machines with 64k.
The 'main' difference is that the image is converted into a 'texture' 128bytesx128rows = 16,384 bytes (16k)
Every byte representing a PIXEL, for speed reasons.
On 64k machines the image is converted into one big texture 256bytesx126rows = 32,256byte (about 32k)
The 2 rows reduction is done to avoid overwritting the SAM bytes ($FF00 on and FE00 on for CoCo3)
This change allows for very fast table access compared to the used for 32K machines
Being the texture that big, we cut it into two files that are loaded into RAM and copied to high RAM in MAP1
Once done, the program switches to MAP1 to start rotating the big texture.
I think that I would better upload here the source files that contain the tables, each with a description
of the equation that is implementing
Please feel free to put any question that could arise. I will look for the last VBS files used for each version ...
cheers
pere EDIT: Source for 32k UPDATED. Adding the VBS files
Re: ROTATING IMAGES PMODE3
if you want a really *indepth* explanation, then you can study this
http://www.drdobbs.com/architecture-and ... /184416337
http://www.drdobbs.com/architecture-and ... /184416337