Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Spherical Coords
2004-11-19 20:27
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?
 
... 27 posts hidden. Click here to view all posts....
 
2004-11-23 14:28
Cybernator

Registered: Jun 2002
Posts: 154
Optimus wrote:
> I was wondering lately why everyone
> uses the matrix rotations, since the
> spherical seems to have less calculations
> (If your objects are already stored in
> spherical coords). I guess it's because
> there are only rotations on 2 angles, not
> enough for games, but cool for an object
> rotator in demos and nobody would notice..

With spherical coords, one should be able to represent every possible position on the sphere. So X, Y, Z rotation should also be possible. I don't know how it's to be done, though.

Krill wrote:
> that was fairly easy, i dont remember
> any problems occuring because of the steps
> oswald mentioned. actually the objects have
> coords of say -15 to 15, in steps of 1.

If the step is 1, I see no problem either. :) At first I wrote a .3DS extractor. Later, upon a suggestion by Raf/Samar, I made an ASE (Ascii Scene Export) Parser. One adventage of ASE files is that they are textual. You can easily open them with Notepad and see in what range the coords are. It's the best if you keep'em between -1.0 and 1.0, so that you can easily set them at the desired range later.

> then wrote a little pascal tool to convert
> the object file containing the points coords
> (in 4-byte real numbers) to c64 ints

Now that you mentioned it.. :) I'm really currious about the IEEE format. How floats are stored, how one does math on'em (at lowlevel). Then how one calculates eg. a sinus of a given angle (assuming there's no coprocessor, and you have to handle all this in software), etc. :) Been googling without much of luck. Can anyone point me a tutorial on some of this stuff? Perhaps I should also go through the C64's kernel disassembly.

JackAsser wrote:
> Demo coding is ALL ABOUT cheating.

Democoding has different definitions. Some say it's about cheating, some say it's about art.. Some even say it's a way of living. :)
2004-11-23 18:11
Optimus

Registered: Jan 2002
Posts: 122
>Then how one calculates eg. a sinus of a given angle

There is this article on HUGi (http://www.cfxweb.net/modules.php?name=News&file=article&sid=585) and I remember there was another one that I found somewhere on Hugi coding digest (http://www.pouet.net/prod.php?which=10807), with lotsa interesting coding and math articles..

Would be interesting for me to read it too and figure how it works. Till the moment I always precalculated sines, used a 20byte sine generator on PC intros blindly without knowing what it does.. :P
2004-11-24 00:42
White Flame

Registered: Sep 2002
Posts: 136
> I'm really currious about the IEEE format.

I don't remember where I got these from, but there's some good IEEE floating point info here:

http://www.white-flame.com/files/fp/
2004-11-24 09:00
Oswald

Registered: Apr 2002
Posts: 5094
optimus, on c64 sines are not generated runtime, but are precalculated. 99% of the time you have a sine table with 256 entry, mostly in 8 bit in 2's complement format.(entrys ranging +-128) Sometimes 16 bit format is better. But thats the rarer case.
2004-11-24 12:15
Ben
Account closed

Registered: Feb 2003
Posts: 163
Off topic:

If you insist to calculate Sine values, and dislike interpolation and scaling from a table, you might want to resort to using the Taylor expansion approximation, i.e. something like sin(x) = x - (x^3)/3! + (x^5)/5! - (x^7)/7! + ..
This is converging fairly rapidly.

You can of course use tables for x^n. However, as there is lack floating point calculation functionality, you will experience some problems with the division. You might want to use log/exp tables with a multiplier to make x^3 sufficiently large (you will need to go for short or long integers anyhow) and can account for the multiplier later on.


On topic:

Can you describe the type of distortion you experience? In the past I encountered some trouble due to the redundancy to describe points using angles (i.e. { 180 - a, b, r } ~ { a, b + 180, r } and such ).
However, are you sure your projection functionality properly handles sign/phase changes?
2004-11-24 12:56
Oswald

Registered: Apr 2002
Posts: 5094
ben, imho the taylor expansion is too complicated for a 6510, the only case when you would want to use it is when u do a 4k/256byte/etc intro, but then the needed log/exp whatever tables are already bigger than the sine u need. I saw in cruzers 256 byte dycper a pretty small routine that generated a sine wave. check c64.ch sources for details.
2004-11-24 13:24
Ben
Account closed

Registered: Feb 2003
Posts: 163
Off topic, @Oswald:

It is quite laborious, and perhaps yet has very few applications. People wanting to calculate sine values with greatly varying parameters might like it anyhow.

There are expansions that use only a few squared values and a few scalars (I believe the expansion is named after Padre or something like that).. Anyway, this still involves quite some algebra.

Anyway, as we are talking about discrete outcomes in the range [-128,128] I bet you can resort to discrete approximations which are indeed fairly simple. (One rule of thumb I recall: close to 0, sin(x) ~ x).
I will check out Cruzer's routine. Nice to have a source base for C64 stuff.
2004-11-24 14:06
Krill

Registered: Apr 2002
Posts: 2980
hmm, linear approximation using a 256-stepped 16-bit sine worked well enough for me. check bar4kode, i generated a $0800-stepped 24 bit sine with it there for the twisting bar, and i dont think one would notice any difference compared to a taylor-generated sine at all.
2004-11-24 15:22
Ben
Account closed

Registered: Feb 2003
Posts: 163
@Krill:
I guess you mean inter/extrapolation with linear approximation. I reckon 256 steps should indeed do a good job. I guess the number of steps can even be drastically reduced by mirroring and removing redundancy. I guess all it would take is running some test and stretch the limits.

I guess I am mistaking the C64 to be used for scientific applications ;) Damn.. I am getting old :)
2004-11-24 16:59
Krill

Registered: Apr 2002
Posts: 2980
ben:

of course i did not store the full 256 steps sine in the 4k, but instead just the first 64 steps (0 to pi/2) =)
Previous - 1 | 2 | 3 | 4 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Andy/AEG
csabanw
Alakran_64
rambo/Therapy/ Resou..
RetroGL
psenough
slimeysmine
TPM/Silicon Ltd
t0m3000/hf^boom!^ibx
Devil/Clique
wil/VCC^CTG
E$G/HF ⭐ 7
sln.pixelrat
Guests online: 117
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.048 sec.