From: ellman AT xs4all DOT nl ()
Newsgroups: comp.os.msdos.djgpp
Subject: ALLEGRO: Re: Q for the 3D gurus
Date: 14 Jun 1997 13:16:14 GMT
Organization: XS4ALL
Message-ID: <5nu5iu$9ci$1@news0.xs4all.nl>
References: <33A1C937 DOT 34DC AT cam DOT org>
NNTP-Posting-Host: xs2.xs4all.nl
Lines: 53
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

In article <33A1C937 DOT 34DC AT cam DOT org>, Vic  <tudor AT cam DOT org> wrote:
>Hullo! 
>I'm in the (slow and painful) process of doin a (full 3D volume) polygon
>clipping for allegro...
>virtually I wrote all the functions but the bastard dies on me(
>crashes). In my attempts of debugging it I found that the plane
>(equation finder) and intersection (check for intersection and get it)
>functions work fine. So I guess the problem is in my function for
>setting the frustum (since the actual poly clipper just calls the
>intersect functions on a bunch of arrays)...
>does anyone know a good way of setting the frustum? Should I set it
>according to the resolution? Or to the variables set by set_viewport ?

Are you remembering to do 3D cliping in viewspace/cameraspace (ie. before
you persp_project() your points)? After perspective projection, the vertices
of a polygon no longer lie on the same plane.

I've also been experimenting with a 3D polygon clipping routine for Allegro,
but at the moment, it only clips to the Z=K plane (for any given value of K).
Every so often, when I orient my 3D world (which in this case, consists of one
long corridor) in certain orientations, my program crashes with an FPE (I have
no way of knowing if it's a divide by zero, overflow/underflow, etc). I have
extensively looked at my code, and it seems allright. I have come up with a
theory that Allegro's polygon_3d() function cannot handle extremely
large X and Y values. I am clipping my polys to the Z=40.0 plane. With floats,
it crashes, and with fixeds, the polygons end up in all the wriong places.
Maybe if I tried clipping to the fustrum as well, I could limit polygons' X
and Y co-ords in screenspace to the visible screen area. Usually, the fustrum
consists of six planes. The near z=K plane, the far z=K' plane, and the four
following planes: 
x=z, x=-z, y=z, y=-z. Finding the interception of a line with these planes is
a lot quicker than finding the interception of a line with a generalised plane
of the form Ax+By+Cz=D .

Another theory that I have is that points that are extremely
close to the clip plane could result in an underflow error.

I think (but I'm not sure) that there might be a way to change the behaviour of
the FPU when it comes accross an error condition. Is it possible to just let it
ignore divide by zeros, overflows (give the largest number as the result),
underflows (give 0 as the result), etc?

AE.

PS. I have discovered a bug in Allegro's ATEX_LIT and PTEX_LIT modes.
When the light values span the range 255-0, sometimes after it reaches 0, the
light-value wraps back to 255.

--
Andrei Ellman -- URL: http://www.xs4all.nl/~ellman/ae-a -- ae1 AT york DOT ac DOT uk
"All I wanna do is have some fun     :-)      ||  ae-a AT minster DOT york DOT ac DOT uk
 I've got the feeling I'm not the only one"   ||  mailto:ellman AT xs4all DOT nl
     -- Sheryl Crow      :-)    ||       It's what you make of it.