[CSDb] - User Forums - Spherical Coords

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?

2004-11-20 10:29

Oswald

Registered: Apr 2002
Posts: 5094

Hi Cybernator !

what one-der does is:

it uses a rotation matrix. With a rot matrix you normally get your rotated coordinates by doing:

xcoord= xco*xxm+yco*yxm+zco*zxm

where: xco,yco,zco = original coords

xxm, yxm, zxm = the matrix elements to get the rotation of the x coord

so ycoord, and zcoord is calculated similarly just with different matrix elements.

(if you already know this, sorry for boring you:)

now the trick is with the matrix elements.

you precalc before the rotation xco*xxm, yco*yxm, zco*zxm, etc... BUT you dont use all possible coordinates, u only use coordinates like ...-32,-24,-16,-8,0,8,16,24,32... which can be done pretty FAST. if u precalc this stuff to t he zp, u get a code like in one der.

lda xco*xxm
adc yco*yxm
adc zco*zxm (sbc is used if the given coord was negative)
sta xcoord

voila! oh, and the coordinates are stored in a self modded way, guess you already figured that out :)

about the spherical stuff... I dont know... triple check your equations, they are probably incorrect.

2004-11-20 12:45

Cybernator

Registered: Jun 2002
Posts: 154

> *snip*
> (if you already know this, sorry for boring you:)

I've had enough time to figure out how these matrices work. :)

> you precalc before the rotation xco*xxm, yco*yxm,
> zco*zxm, etc...
> BUT you dont use all possible coordinates, u only use
> coordinates
> like ...-32,-24,-16,-8,0,8,16,24,32... which can be done
> pretty FAST.
> if u precalc this stuff to the zp, u get a code like in
> one der.

Neat! :) Though I guess this is gonna make troubles when importing .max
models.

> lda xco*xxm
> adc yco*yxm
> adc zco*zxm (sbc is used if the given coord was negative)
> sta xcoord

> voila! oh, and the coordinates are stored in a self
> modded way,
> guess you already figured that out :)

You mean they are hardwired in the speedcode, rite? Yes, that's the first thing I figured out.
This is no problem 'coz I'm not going for object transforms. And even if I was, again I see no problem. :)

> about the spherical stuff... I dont know... triple check
> your equations, they are probably incorrect.

The PC experiment simply uses: x=r*sin(theta)*cos(phi); y=r*sin(theta)*sin(phi); z=r*cos(theta)
I stole these, haven't tried to figure out how they work. :)

For cartesian to spherical, I use:
r=sqrt(x*x + y*y + z*z); theta=arccos(z/r); phi=arctg(y/x)
I'm sure the problem doesn't occur here. If it did, the object wouldn't distort _while rotating_.

Thanks a lot, Os!

Btw, is projection handled in Oneder (Wonder? :))? When rotating the object around the X axis (in usermode), I can't see any perspective transform.

2004-11-20 17:24

Oswald

Registered: Apr 2002
Posts: 5094

right one der doesnt do perspective transformations (just look at the code..) also another trick is obvious: it does not ORA the pixels...

the screenmode should be also noted, it uses 3 charsets, each layed out like:

0,1,2,3...31
32,33,34..63
64,65,66..95

obviously: one char row is exactly 256 bytes in memory, which makes calculations easy.
(2 table lookup and one ora table lookup to get the addy) look at the code.

the spherical stuff is still over my knowledge, but from my experiences the trouble is with the equations...

either you mixed up something when implementing the code for stuff like:

sin(theta)*cos(phi)=(sin(theta+phi)+sin(theta-phi))/2
sin(theta)*sin(phi)=(cos(theta-phi)-cos(theta+phi))/2

after having done several 3d rotators, I know: if ur object distorts when rotating about a specified axis, either the equations are wrong, or you mixed up a sine/axis in the code.

2004-11-20 20:32

Cybernator

Registered: Jun 2002
Posts: 154

> also another trick is obvious: it does not ORA
> the pixels...

Yeah, that bugged me. As far as I can see, there're no runtime modifications on the bitmask table. So I guess some pixels get cleared, but I really can't notice anything (except that if I stop the rotation, I can never see two pixels near each other with respect to the X axis).

> obviously: one char row is exactly 256 bytes in memory,
> which makes calculations easy.

That won't help me, I have to go for sprites.

> either you mixed up something when implementing the code
> for stuff like:
> sin(theta)*cos(phi)=(sin(theta+phi)+sin(theta-phi))/2
> sin(theta)*sin(phi)=(cos(theta-phi)-cos(theta+phi))/2

Nope, those were just some non-implemented ideas about how I'd handle the multiplication on C64. The PC version multiplies those the natural way. :)

2004-11-21 13:10

Optimus

Registered: Jan 2002
Posts: 122

I will make a guess since I had gone into exactly the same problem a long time ago when I first tried to code a 3d dots rotator on PC. Only one of the three rotation was working, the rest distorting the object in a strange way. However, my code was not using the spherical coords way but the very common equations for 3-axis rotations (I didn't used matrices then, but it must be the same in another way). I am not sure if it's the same with your code..

I handled the 3 rotations separately. And so my mistake was that I always tried to rotate from the base object, because that's how I wrote the equations in paper. At each frame I should 1) make X-rotation from the base object, 2) make Y-rotation from the X-rotated object, 3) make Z-rotation from the already X&Y rotated object. But now I am thinking it, I am not sure if it's the case for your code, because spherical coords are not dependent from base x,y,z but from 2 angles. Perhaps something on the conversions from cartesian to spherical and back?

I guess I have to try coding the spherical rotation myself and figure out if I go into problems. 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..

2004-11-21 17:57

Monte Carlos

Registered: Jun 2004
Posts: 359

Perhaps it's the precision.
Outside, where r is greater, you get a higher inaccuracy.
But this must not be a drawback, because the velocity increases simultaneously.

2004-11-22 11:32

Krill

Registered: Apr 2002
Posts: 2980

the code required to calculate the matrix can be optimised to take 9 or 10 raster lines, it all involves only a fixed amount of adds and shifts, using those sine addition theorems. (you'll need the formulas for two sin/cos terms and those for three sin/cos terms.)

for +h2k, i made the objects in lightwave 3d on the pc and then wrote a little pascal tool to convert the object file containing the points coords (in 4-byte real numbers) to c64 ints. 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. the scaling is simply done by a sine with a bigger amplitude.

and i dont recognize the missing ora by just looking at the normal effect (without user mode), so why do all coders get so upset about that? ;)

2004-11-22 14:04

Oswald

Registered: Apr 2002
Posts: 5094

krill: coz the missing ora feels somehow unfair/cheating :)

2004-11-22 15:51

JackAsser

Registered: Jun 2002
Posts: 2014

If the missing ORA stills looks the same as with it then it's just lame to keep it. i.e. non-optimaized. Demo coding is ALL ABOUT cheating. Not cheating and having abdundant instructions is just lame. :D

2004-11-23 08:44

Optimus

Registered: Jan 2002
Posts: 122

>ORA in Oneder

Funny. I didn't noticed that before. Not only that but yesterday while I was coding sine dots (on the CPC) I had mistakenly forgotten to OR the pixels, but it took myself a while to notice that :)

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) =)

2004-11-24 17:19

Cybernator

Registered: Jun 2002
Posts: 154

Hugi's such a great piece. Thanks for the link Optimus! Btw, was the sinus generator by Baze using Taylor's stuff?

Ben wrote:
> Can you describe the type of distortion
> you experience?

Erm... Hardly! :) If possible, take a look at the distortion yourself. Uhm, something crossed my mind.. If I wanted to make such a distortion on purpose, I wouldn't have been able to. :P

> However, are you sure your projection
> functionality properly handles sign/phase
> changes?

There's no projection implemented. The X and Y coords of the rotated object are directly used, Z is thrown out. According to the book from where I've taken the formulas, Y axis goes right, Z goes up, and X comes out. So practically I mix them, 'coz on monitor X goes right and Y goes down, but I don't think that can cause a distortion. It must be a very stupid bug. I'll write the thing from scratch. In fact, as soon as Oswald said that Oneder wasn't using spherical coords, I've just thrown the idea. :)

All these maths and floats (thanx for the PDFs, White Flame) freak me out sometimes. I'll just have to dive in the PC-scene as well. Lotsa stuff can be learnt from there. (now I deserve an asskick :P)

Btw, the fire-ish effect in "Halfway There" (the very first one) by Dekadence.. Does it have a formal name? I'd like to google for some info.

2004-11-25 12:27

Optimus

Registered: Jan 2002
Posts: 122

>optimus, on c64 sines are not generated runtime, but are precalculated.

Do you mean that this is how the Kernel ROM sin routine does it? (Else, of course I am aware that democoders are using precalculated sines and don't generate them in realtime, the link was just interesting for people who want to pregenerate them in 256b intros or so)

2004-11-25 12:35

Optimus

Registered: Jan 2002
Posts: 122

>Btw, was the sinus generator by Baze using Taylor's stuff?

Baze's words: "well I'm not quite sure but that algorithm simulates a harmonic oscillator"

I had his emails with further explanations which I can't find for the moment, I think we talked about this and I had sent them either to you (or another guy?) a long time ago. Last time, I couldn't understand how it works (and I was supposed to be the math student ;), perhaps in the future I will. There are lessons in my uni I keep loosing, having a lot of connections with maths from demomaking I read around here.. ;P

2004-11-25 14:46

Oswald

Registered: Apr 2002
Posts: 5094

Optimus: I meant that demos use precalced sine tabs, iirc the kernal uses same tables but not much... but really no idea how it calx the sine... this also a way to precalc sinetabs, simply use the kernals floating point accumulator and its sine routine.. :)

2004-11-25 15:13

WVL

Registered: Mar 2002
Posts: 902

emulating an oscillator would be pretty easy.

the math :

let's say you've got a pendulum moving around, you can write the forces acting on the pendulum like :

F = -k*x (x being the offset from the center, k being the spring constant).

the equation of motion becomes :

d2 x(t)    -k*x
------- = ------
  dt2        M

the solution to this is that x ~ some sine

an emulation would be :

have the variables x,v,a,t

set x to -1, v&t to 0,a to whatever

loop :

1 store the value of x in the sine at position t
1b t=t+1
2 a=-k*x
3 v=v+a/M*dt (make dt=1 ;)
4 x=x+v
5 check if x is -1 again ,in which case the sine ends and the loop stops.. 
(a better check would be that x< -0.99 and speed is negative or something)

that's it..

btw, the amplitude of the sine is set by choosing the correct starting value for x at t=0.

the frequency of the sine is set by (sqrt(k/m)) (iirc) ;)

2004-11-25 15:19

Graham
Account closed

Registered: Dec 2002
Posts: 990

some amiga and pc coders used oscilators for their sine calculation. i remember sanity had one in their amige demo-os too. but you need lots of bits and on c64 its propably smaller to just store a quater of the sine and mirror the rest.

2004-11-25 15:51

WVL

Registered: Mar 2002
Posts: 902

it's true that you need lotsa bits. but in return you only have to do add's. if you want a large difference in the sines you need to calc, oscillators are pretty good IMO.

ofcourse my favorite way is to add 2 sines to get new sines with different amplitudes (amplitude ranging from 0x to 2x the original sine).

2004-11-25 21:06

Cybernator

Registered: Jun 2002
Posts: 154

> I think we talked about this and I had sent
> them either to you (or another guy?)

Yes, it was me. :) I have that somewhere on the HD, or maybe I've burnt it on CD.

> Last time, I couldn't understand how it works
> (and I was supposed to be the math student ;)

<weed_mode :P>There's one nasty thing about these sciences, you can't just sit and learn. It takes practise, and it's a pain to practise something you can't see a result of. Solving numbers is just so boring, unless you can use that in your demo (the result I'm talking about :)). It took me some time to understand how the rotation formulas are derived, after which I'm not coding this stuff blindly, or at least I feel so. It seems so simple now.. Or does it? One needs to know some of the fundamental trig identities in order to derive. I have no idea how these identities are derived. I just used them blindly. At uni I'm having quite some troubles with physics, electrotechincs (or whatever it's called in English), and with math as well. I'm having enough motivation to stop my LDAs and STAs for a while, and spend more time on linear algebra. Although I don't get much of WVL's explanation (even if it's veeery familiar :)), he gave me enough motivation to spend more time on physics as well. Hmm... Anyone's got any idea why should I learn electrotechincs? :P</weed_mode>

If I understood the article in Hugi, functions like sin, cos, ln, on a computer are actually calculated by some approximations. Quite interesting. In fact, this discussion turned pretty interesting. :) Another thing which I'm really curious about: how does one calculate the value of PI? All I know is that it's the ratio of the circumference of a circle and its diameter. Say the diameter is 1, the circumference would then equal PI. But how do I calculate PI? (they've stopped, let us continue :))

2004-11-25 21:27

WVL

Registered: Mar 2002
Posts: 902

calculating PI is a really tedious job. The best way might be to use some kind of series, derived from an integration in the imaginary/real plane around a point where the value of the function you want to integrate becomes infinite.

(this is real hard to explain, so i won't)

you get something like

PI/4 = 1 - 1/3 + 1/5 = 1/7 + 1/9 - etc..

but this converges very slowly -> you have to do a lot of calculations to get a reasonable accuracy!

just imagine adding 1/1001, which you do after 500 steps -> it still changes the calculated value in the 3rd decimal. So you need WAY MORE than 1000 steps, to get 3 decimals correctly!!

ofcourse there are faster ways, but in general, forget about it and just use PI=3.1415926536 ;)

2004-11-26 10:14

Graham
Account closed

Registered: Dec 2002
Posts: 990

there's countless ways to calculate pi. most formulas used to calculation millions of digits from pi involved some fast converging arctan formula. but in 1995 a completely new way and much more efficient way to calculate pi was found: the Bailey-Borwein-Plouffe algorithm. with that algorithm you can calculate the n-th hexadecimal digit of pi without calculating the previous ones. very interesting, especially because you can find similar formulas for other numbers like log(2) or sqrt(2).

http://mathworld.wolfram.com/bimg673.gif

2005-02-28 12:32

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.

2005-02-28 18:55

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..

2007-08-24 14:21

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.

2007-08-24 14:21

ready.

Registered: Feb 2003
Posts: 441

Oops, I should have clicked EDIT....
Of course the white glimmerings are sprites.

2007-08-24 14:31

Oswald

Registered: Apr 2002
Posts: 5094

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.

2007-08-24 14:47

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?

2007-08-24 15:12

Oswald

Registered: Apr 2002
Posts: 5094

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.

Refresh

Subscribe to this thread: