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 > 3D stuff - need recommendation
2003-11-20 21:07
Cybernator

Registered: Jun 2002
Posts: 154
3D stuff - need recommendation

I'm working on a glenz vector, and I need some recommendations about what techniques to use. I've already done one, which I'm not very pleased of. (I've read a lot of docs regarding 3D, if that matters!)
Ok, first of all I need a routine, which will be able to handle arbitrary coordinates of the vertices, ie. not just 1, 0, -1... It should be fast, and accurate enough to produce nice-looking effect. Now, I wonder which way to use for multiplying. Using a table f(x)=(x*x/4) is not very accurate, especially if I include the divide by 64 in it. If I use the mathematical way, it doesn't seem to have enough accuracy if I use an 8bit result (the original 16bit divided by 64). This is what I'm talking about:

x'=x*ma + y*mb + z*mc

If I divide each of the multiplies (x/y/z * ma/mb/mc) by 64 and add them up, it'll lose accuracy (at least that's what I get on screen). I may need to multiply and add everything and THEN divide by 64. But this needs 16bits, and that means even slower calculations.

I wonder if the loss of accuracy is maybe something else I'm doing wrong, thus I ask. Do you think the table should work ok, or is there any better method? I'd like to get something like the vectors in Attack of Stubidos III, or the transforming cube in Loaded/Fairlight (near the end, with the freak at the left :))

Well, this is all for now.
2003-11-21 07:28
Puterman
Account closed

Registered: Jan 2002
Posts: 188
I don't get it, why don't you do what other have done before you; think for yourself or read someone else's code? What's the point of coding stuff if you don't want to do the hard work yourself?
2003-11-21 08:14
CyberBrain
Administrator

Posts: 392
i don't get it, why does some coders think it's a death sinn to ask questions to other more experienced coders (in a certain context), who may have the solution to what you are stuck with, or a hint to which technique is the most efficient? What's the point of inventing (a bad version of) the deep plate (or maybe rasterbars would be a better example) for the 783921721th time?
2003-11-21 10:56
Puterman
Account closed

Registered: Jan 2002
Posts: 188
The point is that if someone asks you "Did you really code that kickass vector part?", you can answer "Yes" without bending the truth too much. As I see it, that's pretty much what demos are about.

2003-11-21 11:36
Oswald

Registered: Apr 2002
Posts: 5017
I dont get it, why stupid people must slag down someone who actually wants to LEARN something. Why dont you just keep your shut up. This fuckin coding forum is actually opened for questions like THIS. So if you dont want to help, then keep your mouth closed, but dont kill the spirit in the few who still wants to learn and create.

A coder must go through a learning curve, a beginner cannot code for the first time the fancyest effects up to date. Everyone has to make his first rastersbars, first plasma, first filledvector etc.


Cybernator:

you do something wrong if your routine is not accurate enough. I use the f(x)=(x*x/4) method to multiply, and my 3d calcs are as accurate as in most of the demos. I divide with 128 instead of 64, but I dunno how much this affects things.

I calculate my rotation matrix, and afterwards the rotations using this routine, so when I get a final perspective projected coordinate, its preceeded by about 11 (roughly) multiplyes (and with those divs by 128)

maybe the tables you use are not accurate enough. if you use basic for the precalculations its wise to take care of the roundings of the numbers like this:
poke location,(number+0.5)

or:
take extra care on the Carry bit during the multiplication.

or:
if you take a negative of a number sometimes its better to do:

eor #$ff
clc
adc #$01

here is how my routine looks like (from the top of my head), maybe this will help a bit.

a=number1
y=number2

sta tablo1
sta tabhi1
eor #$ff
clc ;one might try
adc #$01 ;to remove this
sta tablo2
sta tabhi2

lda (tablo1),y
sec
sbc (tablo2),y
sta resultlo
lda (tabhi1),y
sbc (tabhi2),y
sta resulthi

asl resultlo
rol resulthi ; resulthi is our result divved by 128
rts


generally all (99%) routines in demos are working with 8bit. the result after a multiply is 16 bit, but its _always_ trunced to 8bit.


happy coding,

Oswald
2003-11-21 18:34
Puterman
Account closed

Registered: Jan 2002
Posts: 188
Well, Oswald, someone who's coded a realtime glenz vector part might be a beginner to you, and someone who thinks that there's a point in experimenting and learning stuff on his/her own might be horribly old fashioned (or, as you put it, "stupid"), and I guess it was very (or as you might have put it, "fucking") stupid of Hollowman to figure out how to get the above mentioned vector parts fast and accurate on his own, so I'll shut up about it now.
2003-11-22 12:47
Cybernator

Registered: Jun 2002
Posts: 154
Phew! It seems to be working, although I'll have to implement the polygon filler to make sure that the projections are ok. There's something I don't get about this. This is how I calculate the projection table (in C):

for (j=0; j<256; j++)
{
char nr=(char) j;
nr+=40;
proj[j]=(BYTE) (max_mag/nr*100);
}

Nr will be equal to j in two's complement, ie. if j=255, nr will be -1. I add 40 to move the cube away from the camera. Max_mag is the magnification factor. To zoom out, I just multiply by a value smaller than 1 (which means dividing). And 100 is an arbitrary number I found to be working ok. But when I do the following, it doesn't work...

ldy z
lda proj,y
ldy x
jsr smul
sta x
ldy y
jsr qmul
sta y

(smul sets up the pointers according to A, qmul assumes they are already setup)

I've noticed that Soiled Legacy adds 128 to z, and it's then used as an index in proj. I placed this in my code and it worked. I understand that this actually converts the two's complement number into an index, but when I calculate my table, I convert J in two's complement. So why do I still need to add 128? Instead of adding 128 at run-time, I've changed the last line of the table-generator to the following:

proj[(BYTE) (j+128)]=(BYTE) (max_mag/nr*100);

So, it turns as if I add 128 to the Z coordinate. Can't understand why is this needed...
2003-11-24 08:39
Oswald

Registered: Apr 2002
Posts: 5017
puterman: argh... well then when I asked you stupid questions about linux on irc, then why you didnt told me that I should figure them out by myself the old fashioned way ? :) anyway lets close this argue.. its pointless... and excuse me for the hard words, I just got too upset.

(glenz vectors were done 10 years ago, so my opinion is that that kind of routines are for beginners... we saw zillions of them.. a good coder must show better routines)

Cybernator:

the problem with the projections could be:

- not taking care of signs of numbers (+/-)
- the offset 40 is too small/big
- qmul/smul setup aint done the right way (or you dont your usual div by 64 afterwars)
- your projection table is wrong:

my projection table uses only positive numbers. To simplify things: projection has nothing else to do than to as deep Z is as much you have to div the coordinate (wich can be either positive/negative) but taking negative numbers into the table will generate a mess according to the above. (yeah this must be the problem!!!)

In soiled legacy I add 128 to Z to make it always positive, you are right with a clever projection table this is avoidable. But dont take negative numbers into it!!! an X coordinate left of the origo (lets say its negative) after the projection might go to the right side (becames positive) due to negative numbers in the projetcion table, thus your object gets messed up!!!
2003-11-24 12:06
Puterman
Account closed

Registered: Jan 2002
Posts: 188
Oswald, just to answer your question: because demo coding is about doing stuff yourself, while learning to use Linux (or writing applications for it) is the kind of stuff that no one should have to learn the hard way. Because of the lack of good documentation for newbies (or the difficulty in finding it, because there's too much of it), asking newbie questions is the best way to learn some details.

To me it's pretty obvious that you use work in completely different ways when you write demos and when you write applications. When you write demos you do as much as possible yourself, while you try to borrow as much code as possible from other people. When you write demos you optimize stuff as much as possible, when you write applications you tell the compiler to optimize the code (and if you forget it, you won't notice much difference in most cases). I could go on for a while about it, but I leave it as an exercise to the reader to meditate on the subject.
2003-11-24 13:50
HackZ0id
Account closed

Registered: Sep 2002
Posts: 6
While this may be true for the c64 scene it's far from a law of nature. Several of the few demos that exist for the Vic-20 are distributed with source.

Actually I think that the even the application-writers on the c64 would benefit from more people and groups sharing their demo source's.

When talking credz and stuff, what makes your credz less valid if you would distribute the source? If several groups would start distribute their source, that source would actually give extra credibility that they source is their own and that innovation has been done!

If many started GPL their source that would also provide a simpel way for coders to point out that they actually took this or this routine originally written by someone else and optimized or did it better. Their effort, small or large, would become clear as day, when comparing the sources.

GPL and freely distributed source also often drives coders to make the source nice and readable, which they can benefit from themselves if they want to continue or enhance a demopart afterwards.
2003-11-25 08:08
Oswald

Registered: Apr 2002
Posts: 5017
puterman: I dont really get your point. Anyway: since I am on the internet I always found coders to be friendly and helpful to all my questions, so do I with others. I've been chatting of how to do different routines with Graham, Crosbow, Krill just to name the better ones.. And I have helped out countless ppl with coding. At the end it doesnt really matters if someone helped you with his suggestions how to code your routine or not. It was done by you entirelly anyway. One must have the 90% of the knowledge to code any kind of routine and the rest are just ideas, dirty tricks etc... I think even coding such a limited machine needs a huge background of knowledge on this level. Should every coder invent FLI by himself ? Once something was done it will be used by the rest, so everyone adds a little to the whole...
 
... 5 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 - 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
iAN CooG/HVSC
Toggle/Padua
psych
icon/The Silents, Sp..
Hok/Remember
Scrap/Genesis Project
Airwolf/F4CG
MCM/ONSLAUGHT
Guests online: 137
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Wafer Demo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (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.044 sec.