labc-3dc@web-4b.berkeley.edu (Andy McFadden) (04/21/89)
I brought this up once before, but the avalanche of responses quickly overwhelmed me :-). Here goes again... I'm sure most people have seen games like Stellar 7, Arctic Fox, and Elite. While fairly simple, the graphics are nonetheless realistic 3-D. Question is, does anybody have source/object/vague general notions of how to do 3-D transformations in assembly language? I have a couple of old Nibble magazines, but those requires some transcen- dental functions and square roots (the latter of which is not well handled in the GS toolbox... +/- 3...). Is there a better/faster way? On a related note, has anybody come up with a faster line drawing routine than Applesoft hires? If you've ever looked at the code, you'd know that writing faster code would be difficult... understanding the code is hard enough in itself... -- fadden@cory.berkeley.edu (Andy McFadden) ...!ucbvax!cory!fadden labc-3dc@widow.berkeley.edu
lmb7421@ultb.UUCP (L.M. Barstow) (04/22/89)
In article <23400@agate.BERKELEY.EDU> labc-3dc@web-4b.berkeley.edu (Andy McFadden) writes: >Question is, does anybody have source/object/vague general notions of >how to do 3-D transformations in assembly language? > >I have a couple of old Nibble magazines, but those requires some transcen- >dental functions and square roots (the latter of which is not well handled >in the GS toolbox... +/- 3...). Is there a better/faster way? > How about taking the transcendentals and changing them into series expansions...then all you have to do is run about 3-4 terms of the series expansion through the computer (something that, if programmed with care, can be done without too much reliance on SANE) I make no claims on the ability of this method, as I have never actually programmed it, but it should be faster than using SANE. Using tricks like multiplying by bit-shifting, and storing polynomials in bit-patterns, you should be able to create some fairly fast code. -- Les Barstow LMB7421@RITVAX.BITNET ...rutgers!rochester!ritcv!ultb!lmb7421.UUCP "I know you think you know what you thought I said, but you don't realize that what you thought I said was not what I meant"
shankar@bedrock.SRC.Honeywell.COM (Son of Knuth) (04/22/89)
In article <722@ultb.UUCP> lmb7421@ultb.UUCP (L.M. Barstow (674SPS)) writes: >programmed it, but it should be faster than using SANE. Using tricks >like multiplying by bit-shifting, and storing polynomials in ^^^^^^^^^^^^^^^^^^^^^^^ >bit-patterns, you should be able to create some fairly fast code. ^^^^^^^^^^^^^ What trick is that? --- Subash Shankar Honeywell Systems & Research Center voice: (612) 782 7558 US Snail: 3660 Technology Dr., Minneapolis, MN 55418 shankar@src.honeywell.com srcsip!shankar
hentosh@amethyst.bucknell.EDU (04/22/89)
>I'm sure most people have seen games like Stellar 7, Arctic Fox, and >Elite. While fairly simple, the graphics are nonetheless realistic 3-D. >Question is, does anybody have source/object/vague general notions of >how to do 3-D transformations in assembly language? > >I have a couple of old Nibble magazines, but those requires some transcen- >dental functions and square roots (the latter of which is not well handled >in the GS toolbox... +/- 3...). Is there a better/faster way? > >On a related note, has anybody come up with a faster line drawing routine >than Applesoft hires? If you've ever looked at the code, you'd know that >writing faster code would be difficult... understanding the code is hard >enough in itself... > >fadden@cory.berkeley.edu (Andy McFadden) I wrote some fast 3d routines awhile ago, I don't have the source code but the general idea is that you compute the functions for the possible inputs and then place them into a lookup table. Then if you want a value just look it up. Now if do some checking of the position functions you will see that you don't need much accuracy for the functions so your table is actually quite small than you would think. I don't know what routines applesoft uses to draw a line, but a fast one I know is to take the end point and subtract the other end point from it. Choose the point that is the lower one to use as your subtrand. Now the delta_y over delta_x is the slope of the line. Start at the position that you subtracted and draw a dot. If the delta_x is greater than the delta_y then draw the next dot to the right of the previous and subtract one from the delta_x, otherwise draw the next dot above the previous position and subtract one from the delta_y. repeat until both delta_x and delta_y equal zero. This method is fast becuase it doesn't use division. You will note however it is for lines that only have a positive slope. To do the negative slope subtract from the delta_y and move down instead of up on your check. Also this algorithm is nice in the sense that if you give it the same two endpoints, it will always draw the same line. (You won't have any stray pixels if you try to erase a line by drawing another one over it) I leave the rest to you, have fun. -- InterNet: hentosh@amethyst.bucknell.edu | 'Ever have deja vu and amnesia BITNET : hentoshr@bknlvms.bitnet | at the same time?' AppleLink PE : RobertH128 | -- Steve Wright
kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) (04/22/89)
In article <722@ultb.UUCP> lmb7421@ultb.UUCP (L.M. Barstow (674SPS)) writes: >In article <23400@agate.BERKELEY.EDU> labc-3dc@web-4b.berkeley.edu (Andy McFadden) writes: >>Question is, does anybody have source/object/vague general notions of >>how to do 3-D transformations in assembly language? >> >>I have a couple of old Nibble magazines, but those requires some transcen- >>dental functions and square roots (the latter of which is not well handled >>in the GS toolbox... +/- 3...). Is there a better/faster way? >> >How about taking the transcendentals and changing them into series >expansions...then all you have to do is run about 3-4 terms of the >series expansion through the computer (something that, if programmed >with care, can be done without too much reliance on SANE) > >I make no claims on the ability of this method, as I have never actually >programmed it, but it should be faster than using SANE. Using tricks >like multiplying by bit-shifting, and storing polynomials in >bit-patterns, you should be able to create some fairly fast code. Most commercial games don't actually do the 3-D computation on the fly-- instead, they compute the actual bit-image of the shape rotated at various angles and store those directly into memory. There could be dozens of different rotations all stored in memory at once. They can then 'rotate' the object by just copying directly to the screen the bit-image of the correct rotation. All of the calculations for the proper shapes can be computed before-hand using BASIC if so desired. For 'on-the-fly' type graphics, you are probably best off computing a table of approximate sines and cosines, and using that with a fixed point representation. If possible, look into how Applesoft does shape table rotations...it's a pretty good method. I also don't understand what the storing polynomials in bit-patterns means exactly...what polynomials??? NEVER USE SANE!! You must be joking if you were seriously considering using that! Find the actual code that does integer multiplications, and recode that directly into your programs...it's an efficient routine, but calls through the tool manager slow it down a lot. Kent Dickey KADICKEY@phoenix.arpa KADICKEY@PUCC.Bitnet
Jerry.Kindall@f10.n226.z1.FIDONET.ORG (Jerry Kindall) (04/22/89)
A good book on graphics algorithms is Microcomputer Displays, Graphics, and Animation by Bruce Artwick of Flight Simulator fame. It's published by Prentice-Hall. Artwick doesn't give much source code, but he outlines the algorithms required for various graphics functions in enough detail that a competent programmer ought to be able to handle them. :) - Jerry Kindall Mail to: crash!pnet01!pro-beagle!jerryk -or- jerryk@pro-beagle.cts.com -- Jerry Kindall via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!10!Jerry.Kindall
thrash@jolnet.ORPK.IL.US (Richie Tozier) (04/23/89)
well there was a program a while back that was from sublogic that created 3-d 3-d (code?) programs or whatever..it was the one they used to make flight simulator I (heh i still remember that baby ;-)
labc-3dc@e260-3f.berkeley.edu (Andy McFadden) (04/25/89)
In article <8904220157.AA04218@amethyst> hentosh@amethyst.bucknell.EDU writes: [chop chop] >I don't know what routines applesoft uses to draw a line, but a fast one I >know is to take the end point and subtract the other end point from it. [description of algorithm] I tried this once. It wound up being slightly slower than Applesoft, because I was using lookup tables... the fastest way to go about it seems to be this algorithm, doing some fancy calculations to get the next bit/line position. Probably the fastest way is to have 8 subroutines, one for movement in any given direction. Woz's routines (source can be found in the Programmer's Assitant #1 manual, along with the code relocator source, etc) manage to pull this off on an 8-bit computer, but bear a strong resemblance to spaghetti. Since the hires screen is non-linear, the computations involved are a little weird. >-- InterNet: hentosh@amethyst.bucknell.edu | 'Ever have deja vu and amnesia -- fadden@cory.berkeley.edu (Andy McFadden) ...!ucbvax!cory!fadden labc-3dc@widow.berkeley.edu