| |
Scout
Registered: Dec 2002
Posts: 1568 |
3D projection on the C=64 (or...how do I divide?)
Hi!
After 12 years I picked up coding again on the C=64.
What I want to make is a simple 3D starfield.
I know something about 3D programming, so that's no issue.
The only thing I stumbled on is how to implement 3D projection (X1=X/Z) and especially the dividing part of it.
How can I implement this on the C=64?
Any hints, tips?
Thanx!
R.
(Asm on the PC is so much easier ;-) |
|
... 25 posts hidden. Click here to view all posts....
|
| |
Scout
Registered: Dec 2002
Posts: 1568 |
Quote: the lacking accuracy of this approach is not to be ignored with 3d code. i might add that the best accuracy with this algorithm can be achieved by using the binary logarithm, but i guess you've already taken that one.
for more accuracy, the best thing is a plain binary division routine that calculates one bit of the result per loop pass, being as exact as you want it to be.
if you never coded such a thing, wait for some future issue of one of the disk mags where there are further chapters of my tutorial on maths in assembler published. i don't want to get into further detail here but i can send you sample routines or the chapter of that tutorial in german language, as i did not translate it to english yet.
Hi
I appreciate if you could send those routines/info.
It's no problem if the text is in German coz I can read it a bit (I'm dutch).
Thanx.
R.
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I have always precalculated everything => no need for division and other nasty realtime stuff :)
But if I'm going to make something in realtime one day, Perffs algorithm seems pretty smart... But if it's inaccurate how about this:
x/y = x*(1/y)
Then you just need a table of 1/x and to do a multiply. The latter can be done with this algorithm...
Let f(x) = x^2 / 4.
Then a*b = f(a+b) - f(a-b)
So with a table of squares/4 and 1/x you should be able to divide using adc and sbc. |
| |
Nightlord
Registered: Jan 2003
Posts: 131 |
cruzer:
i have thought of division using your approach but i ran into a problem that 1/x table starts to get inacurate for large x values. besides the f(a+b) and f(a-b) also becomes troublesome. since now typical a values are decimals and typical b values are fixed point reals between 0 and 1
i have the feeling that this should be fixable by playing with the tables but couldn't figure out how? so how do you handle these issues.
thanx in advance |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Nightlord: Do you need to divide by large numbers when doing 3d projections?
Any division routine on c64 is bound to be inaccurate or slow, so I guess you'll have to live with some inaccuracy. Then the trick is to make it just accurate enough to suit your particular need.
But as I said, I always precalculate everything, so I haven't got any experience with implementing a division routine myself.
And btw, I think Perff's routine looks smarter than mine. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
If you only want to make a 3D starfield end nothing else, just do like the game DELTA.
set a sprite and give it a different X position every rasterline.
The sprite is just made of a single vertical line in 1 color.
Do different sinus tables for each sprite, and it will look quite real to you.
|
| |
Nightlord
Registered: Jan 2003
Posts: 131 |
cruzer:
at the moment i am using division for 2d line slope calculation. it is precalculated in my engine which makes it bound between 0 to $40 and i store slopes as $xx.xx so i spend $40 x $40 x 2 = $2000 bytes which hurts my mind. since i don't use eors to fill and i fill line by line (this lets me to make surfaces with dithered patterns unlike eor)i need to take one step in y everyline and left/right slope steps in left and right boundaries of line. for this reason i could not find a way to use stephen judd's add-dx-until-bigger-than-dy approach. (it isnot applicable for me when dx > dy)
can any body give some fresh ideas.
|
| |
Oswald
Registered: Apr 2002
Posts: 5023 |
nightlord: my guess is, that using logs and exps is accurate enough for your routine, either u use this one, or the bloody slow, but hell accurate bit shifter killer one. (you can find this on steve judd's page)
and speaking of patterns, you can have 13 different ones if you use eorfilling a bit more trickyer: have 2 eor buffers, one with the odd, one with the even lines of your screen. then you draw each line into both of them, but with a different colour pattern for the pixelmasks. then you just eor to the screen in 2 go the odd and even lines, and voila you have patterns :) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
When dx>dy I guess you need to do an integer division for the Bresenham algorithm, although I have never tried to implement it on the c64. Maybe you can make some LUT-stuff for this, that doesn't fill too much. |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
You technically don't need to do a divide.
All's that Bresenham does is keep track of the slope's fraction in a numerator/denominator pair instead of in fixed point. When the numerator gets bigger than the denominator, you bump by 1 pixel and subtract the denominator from the numerator. If you change that comparison to a "while(num>=denom) { ++x; num-=denom; }" loop (with --x for the other direction obviously), the same general code will work no matter the slope. Whether that's faster or slower than doing a divide before-hand (to figure out the integer portion of the delta so you don't need to loop the num>demon compare) depends on the slope of the line. Where the delta is large, a divide is faster. However, if the delta is large, the line won't be very long, so it sort of evens out. The code is a lot shorter and easier to manage if you do a compare loop. |
| |
Nightlord
Registered: Jan 2003
Posts: 131 |
oswald: you are the master of odd/even lines
thx everyone |
| Previous - 1 | 2 | 3 | 4 - Next |
