RE: [AD] polygon3d patch - and small mixer patch

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> Ben, how exactly does your patch effect texture coordinate alignment?  I
> followed a bit of the argument, and even added my 2 cents, but I don't
> recall exactly what the change you proposed was.  So, I don't know if I
> support it or not ^_^

Here's a summary:

In the current version of poly3d.c (the one on CVS, without my patch
applied), integer texture coordinates are mapped on to the middle of a
texel. Thus if you map a texture on to a quad using (0,0), (0,31), (31,31)
and (31,0), the edges will only be half a texel thick. To get around this, I
used to use -0.5 and 31.5 for my polygons, which didn't look very nice.

With my patch applied, integers are mapped on to the top-left corner of a
texel. Thus with the above coordinates, the edges are a full texel thick,
but the right and bottom of the bitmap are missing.

My patch also modifies the test and example programs to use 32 instead of
31, so that the edges are no longer missed.

Bertrand Coconnier and I exchanged messages for a while, and I eventually
won the argument - no hard feelings :-) There was also a suggestion to
modify the texture coordinates within polygon3d(_f)() so that they were all
inclusive, but that would cause all sorts of alignment problems, bearing in
mind that texture maps are not always right rectangles.

George Foot mistakenly thought the screen coordinates of 3d polygons were
inclusive, so that two polygons which shared vertices would be drawn with
some overlap. If this were the case, the texture mapping would have been
wrong. However, since there is no overlap, there is no problem here.

Jason, your previous message was pretty coherent, and agreed with me. The
only mistake was that you thought u and v were integers in Allegro, but in
fact they are floats (or fixeds).

> My vote is for integer texture coordinates to map to integer pixel
> coordinates, with the origin being in the upper left corner of
> the bitmap.
> If the distance between two vertexes (in texels) is 32, then 32 texels
> should be between them (in other words, one to one between texture coords
> and texels).
>
> Allegro's current conventions and conformity with other 3D libs like
> OpenGL and DirectX dictate this.

Well that's just as well :-)

In addition to texture alignment, my patch modifies the polygon drawing code
to handle the case where two of the first three vertices of the polygon are
coincident. Such polygons can be produced by clip3d_f(), especially with my
game and its precise camera positioning :-) The old code gets the
clockwise/anticlockwise discrimination wrong, while the new code uses a
method where such discrimination is unnecessary.

Ben Davis



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/