🚀 go-pugleaf

On Tue, 10 Sep 1996, Lord Shaman wrote:
> I'm not. I'm writing a polygon drawing engine
> for TRIANGLES only, which can have any orientation in space and each
> vertex has a seperate texture space co-ordinate (u,v) in the texture
> pixmap. This allows stretched, distorted and scaled textures without
> hassles. A scanline renderer would be prefferable, but is not necessary.
> (Constant Z lines mean a lot of buffer changes in SVGA unless I use
> double buffering) Also, linear interpolation will NOT do, it is far too
> inaccurate to give satisfactory results. This game will be realease (if
> ever) at a time P6s/K6s will be popular and therefore will have a tad
> more power than your avarage computer today. Double precision floating
> point is used everywhere so far, so no fixed point rubbish please.
> (A lot of FAQs assume you're writing for a 386sx, which is NOT true.)
> Quake's monsters use the method I just described. And no, John Carmack
> doesn't want to tell me how he did it.
> 	If you have ANY information, wether it is just some maths you saw once,
> a URL, or a FAQ that is more practical than the comp.graphics.algorithms
> FAQ, or a tutorial that has more than how to do a DOOM engine, please
> email me. A book title is totally useless.
> 
>                                    thanx in advance . . . the Lord
> Shaman.
>     
> ----------------------------------------------------------------------
>             "My aim is life is to become immortal, or die trying."
>           http://www.nlc.net.au/~shaman  or  mailto:shaman@nlc.net.au
Well if you are planning that far ahead you might want to consider direct 
3d. But to answer your question. Heckbert's web page has a complete 
mathematical explanation of how to do it. YOu might also want to look at 
chris Heckers texture mapper from Game Developer magazine. He has the 
best explanations of correct rasterization I have every seen. YOu will 
need to add Z buffer support but that shouldn't take more than a couple 
hours. Lastly is my simplifed expanation.	
	1) divide your texture coordinates by Z which makes them linear 
in screen space
	2) interpolate the linearized texture coordinates and 1/z across the 
		polygon
	3) At each pixel divide u/z and v/z by 1/z to get the u and v's.
There are loads of ways to speed this up focusing mainly on the fact that 
gradients can be quickly calculated for triangles and ways of avoiding 
the divide per pixel. The common ways of avoiding the divides every pixel 
are span line subdivision, triangle subdivision where you break the 
triangle into smaller parts, lines of constant Z, and quadratic 
interpolation rather than linear. These have all been hashed out in 
detail in this forum over the past year.
	Lastly, I wouldn't be suprised to learn that Quakes monsters are 
linearly interpolated. Over the relatively small delta Z of a monster the 
effects of perspective are not that noticeable especially since the 
average triangle size is pretty small.

David Matiskella
matiskel@aa.washington.edu

Daniel Phillips says:
>David Matiskella says:
>>Lastly, I wouldn't be suprised to learn that Quakes monsters are 
>>linearly interpolated.
>
>They're not, which you will realize as soon as you get eaten by one :)

Never being one to take myself at face value, I checked this, and,
you know, it's *darn hard* to find a monster with a polygon big
enough to verify this.  My conclusion is: maybe, maybe not.  
Remember, they tweak the design each week.  There's no doubt the
rendering is crude - no sub-pixel stuff here.  That makes sense,
it significantly increases the monster count.

---------------
Daniel Phillips
phillips@dowco.com

David Matiskella <matiskel@aa.washington.edu> says:
>Lastly, I wouldn't be suprised to learn that Quakes monsters are 
>linearly interpolated.

They're not, which you will realize as soon as you get eaten by one :)

---------------
Daniel Phillips
phillips@dowco.com

Lord Shaman wrote:
>  This game will be realease (if
> ever) at a time P6s/K6s will be popular and therefore will have a tad
> more power than your avarage computer today. Double precision floating
> point is used everywhere so far, so no fixed point rubbish please.

Double Precision Numbers?

What Are You Doing Then, A Bean Compared To A Super Tank?

And, yeah sure while we're at it, while don't you write a routine that
calculates spacial values for each pixel of the texture map, eh?

> (A lot of FAQs assume you're writing for a 386sx, which is NOT true.)
> Quake's monsters use the method I just described. And no, John Carmack
> doesn't want to tell me how he did it.

>         If you have ANY information, wether it is just some maths you saw once,
> a URL, or a FAQ that is more practical than the comp.graphics.algorithms
> FAQ, or a tutorial that has more than how to do a DOOM engine, please
> email me. A book title is totally useless.
> 
>                                    thanx in advance . . . the Lord

Keith Bugeja wrote:
> 
> Lord Shaman wrote:
> >  This game will be realease (if
> > ever) at a time P6s/K6s will be popular and therefore will have a tad
> > more power than your avarage computer today. Double precision floating
> > point is used everywhere so far, so no fixed point rubbish please.
> 
> Double Precision Numbers?
> 
> What Are You Doing Then, A Bean Compared To A Super Tank?

Lord Shaman should be using 10-byte reals as this avoids load/store
conversions
(from the floating-point coprocessor, Keith!)
(Disclaimer: I don't have the timings for the coprocessor, I am just
guessing.)
--
Q. How many WebMasters does it take to change a lightbulb?
A. 200 OK

-----BEGIN GEEK CODE BLOCK-----
GCS/M d+ s+:(+)> a- C+(++)$ !UV(++) P--- L !E(++)
W+(++) N++ o? K--? w++ O- M- V !PS !PE Y? PGP---
t+ !5(+) !X !R tv(+) b+++ DI+ D+ G e++ h !r !y
------END GEEK CODE BLOCK------