In article <1179665460.4706.11.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:

...

There is some coe in line3d.c that sets and clears this bit, but apparently noone else pays attention to it except as a side effect of comparing user float flag to 1 or 0.

What's the purpose of this second bit?

To force the use of floating point routines in the line3d.c module when the ZVIEWER variable is less than 80. [...]

The problem is that the code that uses this doesn't check explicitly for bit 2, just whether or not user float flag is non-zero. So its not clear which code is just supposed to run when user float flag is non-zero and which code is supposed to run when the 2nd bit is set. Furthermore, setting this second bit causes other code depending on the user float flag to become unpredictable as some of the code tests user float flag being non-zero and some of the code tests user float flag being exactly 1. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

Why not just set the user float flag? Why set bit 2?

Is there some condition where you *don't* want to use floating-point but *do* want to use floating-point for lines?

Yes. If the original image used integer math and ZVIEWER is less than 80. I suspect the thought was that if the original image was done with integer math then the 3D image could also be rendered with integer math. Later, it probably became clear that there were cases where floating point math was appropriate for rendering an image created with integer math.

It just feels redundant to set bit 2, particularly since all the other tests in this file just test if user float fleg is non-zero or zero.

Yes, it is redundant. Also, using usr_floatflag isn't the correct way to force the use of floating point. The floatflag variable should have been used. That way, usr_floatflag would be untouched, floating point would be used, and it would be transparent to the user (until a PAR is generated).

The problem is that the code that uses this doesn't check explicitly for bit 2, just whether or not user float flag is non-zero. So its not clear which code is just supposed to run when user float flag is non-zero and which code is supposed to run when the 2nd bit is set.

The floating point 3D rendering code would execute when the image being rendered was generated using floating point (float flag = 1), or if it was generated with integer math and ZVIEWER is less than 80 (but not 0)(float flag = 2).

Furthermore, setting this second bit causes other code depending on the user float flag to become unpredictable as some of the code tests user float flag being non-zero and some of the code tests user float flag being exactly 1.

I believe that once the image is loaded and rendered, the second bit of usr_floatflag is reset to zero. It looks to me like the overflow flag could have been used instead. Jonathan

In article <465040A9.29267.35B777@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:

As the original author of the 3D transformation (ah, those were the days, designed and coded it from first principles without the benefit of either knowledge or experience), I don't see the point (any more) of using integer math for the 3D transformation. [...]

So just gut the integer 3D stuff? At some point *all* the 3D stuff will be gutted in favor of OpenGL or Direct3D, so might as well ditch the integer processing now. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>