| | Cybernator
Registered: Jun 2002
Posts: 154 |
Spherical Coords
I was doing 3D plots like those in Oneder, +H2K, Late Ejaculation, etc.. It all works a-ok, except that it's pretty slow. :) Took the liberty to disassemble the above mentioned demos and I ended up nowhere. The speedcode relies on some values stored on zeropage, but I can't realize what these values are. What follows is part of the speedcode from Oneder which handles one single plot.
The X reg is either 00 or 80 (which points to the bank I think), which doesn't really matter.
,8000 a5 7a LDA $7a
,8002 e5 94 SBC $94
,8004 e5 ac SBC $ac
,8006 a8 TAY
,8007 b1 e4 LDA ($e4),Y
,8009 85 e1 STA $e1 ; absolute ypos on screen (?)
,800b 9d 02 a4 STA $a402,X ; modifies a separate speedcode to clear the plot later
,800e a5 17 LDA $17
,8010 e5 31 SBC $31
,8012 e5 49 SBC $49
,8014 8d 21 80 STA $8021
,8017 29 f8 AND #$f8
,8019 19 00 41 ORA $4100,Y
,801c 9d 01 a4 STA $a401,X ; modifies a separate speedcode to clear the plot later
,801f a8 TAY ; absolute xpos on screen (?)
,8020 ad 71 43 LDA $4371 ; bitmask ($80, $40, $20, $10, 8, 4, 2, 1)
,8023 91 e0 STA ($e0),Y ; hit it! :)
Now what the hell are eg. the first three instructions?
--
I wonder if this is handled with spherical coordinates. Conversion from spherical to cartesian should be fairly simple to implement: x=r*sin(theta)*cos(phi); y=r*sin(theta)*sin(phi); z=r*cos(theta)
Now the cool stuff about the multiplication of the trig. functions:
sin(theta)*cos(phi)=(sin(theta+phi)+sin(theta-phi))/2
sin(theta)*sin(phi)=(cos(theta-phi)-cos(theta+phi))/2
Which is simply a matter of ADC/SBC. As for the multiplication of the radius, I guess several tables would do the job. I still haven't thought of a fast way to handle the projection, though.
Now, all this is cool, but I've got some trouble. I made a PC proggy to test these conversions. It loads a file containing vertices in cartesian coord. system. Then converts them to spherical, which means that the rotation is simple INC/DEC on the angles. These rotated angles are converted back to cartesian and plotted on screen. But something is wrong: incrementing of one of the angles works a-ok, but if I increment the other one, the object distorts. This shouldn't happen, rite? I mean, it's logical. Or maybe there's another way to handle this rotation (still hadn't reached this topic at university :)). Afterall, perhaps there's some bug in the proggy, but I can't find out what it is.
In case you wanna see the proggy, here it is: http://www.geocities.com/lazeristoski/polar.zip
Arrows handle the angles. A/Z handles the radius, but that is not important.
Is it a good idea to handle this with spherical coordinates?
|
|
... 30 posts hidden. Click here to view all posts....
|
| | peskanov
Account closed
Registered: Mar 2004
Posts: 17 |
Spherical cords work very fast and are ok for using tables.
Of course you can not rotate an object in spherical cords just adding to the values. To understand it, just look to a earth globe; lattitude (ecuator) and longitude (greenwich) are very similar to spherical cords.
If you take two points in the opposite side of the sphere, and add a value to it's longitude coordinate, both will rotate correctly over earth axis.
However, if you add a value to the lattitude coordinate, both will rise to the north pole, converging there.
To rotate a point in spherical coordinates, the fastes way I know is to convert to normal xyz space, and then again to spherical coord, but this time using other axis as reference.
On Amiga we used to create a table 8:8. Something like Phi:Teta for axis Z -> Phi:Teta in axis Y.
The steps are then:
- Take coordinates, axis Z as reference, add longitude. (ADD)
- Convert angles to a space with axis Y as reference. (LOAD)
- Add longitude for axis Y. (ADD)
- Convert angles to a space with axis X as reference. (LOAD)
- Add longitude for axis X. (ADD)
- Convert to XYZ space and plot (a few LOADs)
Fast, but very tricky in terms of precission, and very memory hungry.
I am not sure now, but I think the intro "A500 homage" used this tech.
|
| | Ben
Account closed
Registered: Feb 2003
Posts: 163 |
The big advantage of spherical coordinates is that one can refrain from thinking in cartesian coordinates.. so please feel free to do so :) There is little mysticism to it..
By incrementing radius degrees in each and every spherical vector, one should obtain rotation on a sphere in the cartesian system..
No back and forth conversion required, apart from a single conversion when plotting the vector in a 2D cartesian system..
|
| | ready.
Registered: Feb 2003
Posts: 441 |
Hi,
I first I wanted to start a new thread, but then I though the title of this one suits my question properly.
I can't figure out the priciple of the code behind the rotating textured sphere in Boogie Factor by Fairlight:
http://noname.c64.org/csdb/release/?id=19296&show=review
How much is it pre-calculated and how much calculation does the 6510 really do?
Thanks for help!!
Ready. |
| | ready.
Registered: Feb 2003
Posts: 441 |
Oops, I should have clicked EDIT....
Of course the white glimmerings are sprites. |
| | Oswald
Registered: Apr 2002
Posts: 5028 |
code to calculate one byte is:
lda $xxxx,x
ora $xxxx,x
ora $xxxx,x
ora $xxxx,x
sta screen
as precalculated as it can get, its just table lookups in a speedcode.
basically you precalculate a sphere mapped with indexes, the indexes point into a 16x16 texture. then you offset the table lookups with ,x to get it moving. |
| | ready.
Registered: Feb 2003
Posts: 441 |
mmh, so I guess the thread title does not fit anymore :(
Anyways, thanks. I had looked at the code before posting first, but I was tricked by the ORAs, which I still don't get.
If it is just a matter of display what's in RAM into a 16x16 char matrix, why can't I use simply
LDA $xxxx,x
STA $xxxx,x
every n-frames? |
| | Oswald
Registered: Apr 2002
Posts: 5028 |
every byte contains 4 independent pixels, thus you need 4 texture lookups for each byte. the texture is stored 4 times in 4 table, so you dont need to shift the pixels into their place by hand.
lda texturatable1+currenttexturingoffset4thispixel,x
lda texturatable2+currenttexturingoffset4thispixel,x
lda texturatable3+currenttexturingoffset4thispixel,x
lda texturatable4+currenttexturingoffset4thispixel,x
sta bitmap
edit: also its not just copying bytes, this is a kind of very primitive (precalculated) texture mapping. |
| Previous - 1 | 2 | 3 | 4 - Next | |
