| |
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.
|
|
... 5 posts hidden. Click here to view all posts....
|
| |
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...
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
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!!! |
| |
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. |
| |
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.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
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... |
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
I agree with Oswald here: there's no shame in asking other people for help. After all, the coding is only part, how you 'use' it is what's important and that's something you've got to come up with yourself. |
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
Oswald: Feel free to disagree with me, but I think some questions are completely out of line (like your question on linecrunching a while ago). Other questions are okay. To borrow your example, FLI: it's very easy to check someone else's code to find out how it works. Posting a question about it is just lame. |
| |
tecM0
Registered: Jan 2002
Posts: 40 |
puterman: so if you dont like the questions why not STFUP
and read something else?
btw., i thing looking someone else's code and doing it the
same way (this mostly ends up in doing it without knowing how
it really works) is even lamer than asking a question
and doing a own code with some simple hints.
tecM0 |
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
tecmo: My reasons for not shutting the fuck up and reading something else are probably similar to the reasons why you're not shutting the fuck up and reading something other than my posts. |
| |
Optimus
Registered: Jan 2002
Posts: 122 |
I don't think Cybernator's message is bad at all! It shows that he has already worked a lot on something and just stumbled upon some errors and asks for help. The replies and technical details of this thread are preety interesting for me and other newbie coders too I believe.
The definition of lame would be to come here and ask: "I am new in 6510. Could you please write pleaz pleaz pleaz a code for me, which does a 3d glenz cube and giving me the opportunity to move it with the arrow keys and change shading or texture with space? I can send you also the music to insert it into the demo and send it back to me please. Thanks in advance!" (Which reminds me some real letters with stupid programming requests (I actually got the inspiration for the message in the quotes from them ;) that I was once reading in an old greek computer magazine,.. ahhh those were the times :)
But Cybernator is a very motivated new scener and has done a lot alone, asking for recomendetion about his mistakes and not the code itself! |
| Previous - 1 | 2 - Next |
