RE: [AD] Bug in clip3d_f() / polygon3d_f()

["Ben Davis" <ben@xxxxxxxxxx>]

> Ok, go ahead ! But there is some things I'm wondering about :
> 1. why did you rename the clip_polygon_segment functions in your patch ?

Consistency. Most of the time when a function has fixed and floating point
versions, the floating point version is suffixed with _f. I noticed their
behaviour is not quite the same though. The polygon3d(_f)() functions only
use the floating point version, which takes an int for its height - but the
triangle3d(_f)() functions use the fixed-point version - which takes a fixed
for its height. I thought this *might* be a bug in the sub-pixel accuracy,
but I was already making a lot of modifications - I thought we could leave
it until afterwards. For all I know, it isn't a bug, and there's a good
reason for it.

> 2. if you plan to remove fill_edge_3d_structure[_f]() from aintern.h why
> did you add the formerly named clip_polygon_segment_fixed to the headers
> ?

I saw there were several functions in there, which might have been able to
be removed. Some of them were from polygon.c (the 2D polygon renderer) as
well. I decided it was safer to leave them in (just in case they do, or ever
will, be shared between polygon.c and poly3d.c), and so I added the other
one too.

> > I'm happy to do number 1. As for number 2, here's a quote from the docs:
> >
> > "The u and v coordinates are only required when doing texture
> > mapping, and specify the position of the point in the texture
> > bitmap, for example 0, 0 maps the vertex onto the top left corner
> > of the texture, and if the texture is sized 32x32, setting u=32
> > and v=16 maps the vertex to the point half way down the right edge
> > of the texture. The u/v coordinates wrap at the edge of the
> > texture, so with a 32x32 texture, u=v=32 is the same as u=v=0.
> > This can be used to tile textures several times across a polygon."
>
> Well, there is nothing about top left corner of texels.

But this encourages a user to set up a polygon like this:

V3D_f vtx[4]={
{0,0,1,0,0,0},
{100,0,1,32,0,0},
{100,100,1,32,32,0},
{0,100,1,0,32,0}};

The user would then hope that the texture appears nicely framed in the
texture - not slightly off, like the first programs I wrote before I
realised what Allegro was actually doing.

> > I think "the top left corner of the texture" is the top left
> corner of the
> > texture, not half a texel's width and height into the texture. Likewise
> > "half way down the right edge of the texture" does not mean
> slightly further
> > than half way down, and beyond the right edge of the texture :-P
>
> This is *your* interpretation. But I agree the doc is ambiguous and
> there is a need to clarify it. Here is a quote of the modification you
> are suggesting for the docs :
>
> "The u/v coordinates wrap at the edge of the texture, so with a 32x32
> texture, u=v=32 is the same as u=v=0. This can be used to tile textures
> several times across a polygon. Note that setting whole numbers for u
> and v indicates the top-left corner of a pixel in the texture bitmap, so
> if you set u=32, the last column of pixels that will be rendered is at
> u=31."
>
> There is one big issue :
> - On one hand the original doc tells (and you keep it) that u=v=32 is
> the same thing that u=v=0.
> - On the other hand, a few lines later, you tell that u=32 rendered the
> texel u=31.
>
> The docs are now more ambiguous than they used to be :-) I now think
> your convention is tricky : we are now supposed to tell the polygon
> renderer to draw up to the texel u=32 in order to get the texel u=31
> drawn ?!? And what about the texture tiling features (now u=32 is not
> the same thing that u=0) ?!? IMHO that is not a good idea and I prefer
> the old convention.

Compare this with bitmap clipping. Although there is a function which takes
inclusive values, when you set the values directly, cr and cb indicate the
first column/row not to be drawn to. Compare it also with the way the right
and bottom edges of the polygon are not drawn - something you told me, Bertr
and :-) It is a very common technique in programming to specify a start
value and then the first value *not* to be used.

Also note that u=32 was *never* really the same thing as u=0. My
modification doesn't make it any more so or less so. In addition, tiling
still works properly.

Also note that, in the tests, the edges of the texture used to be only half
a texel thick. Now they are a full texel thick. Nice :-)

I thought it was logical that the whole number part of u and v should
indicate which texel - the fractional part should indicate whereabouts in
the texel. Whole numbers include whole texels - half-integers (1.5, 2.5,
etc.) include half-texels.

Anyway, enough self-righteous justification :-) If we keep the new
convention, here is a proposed replacement for the docs. Tell me what you
think.

"The u and v coordinates are only required when doing texture mapping, and
specify the position of the point in the texture. Think of the texture as an
infinite plane with the texture bitmap tiled across it. We can refer to
pixels in this plane as texels. Remember that each texel is a block, not
just a point. Let's consider a texture bitmap sized 32x32. When you specify
0, 0, you are referring to the top-left corner of the top-left texel. If you
then specify 32, 0 for another vertex, you are referring to the same point
in the tile to the right in the texture plane. If you map a polygon between
these points (and others), note that you won't see any of the second tile -
the polygon stops just short of the texel, since texels are blocks, not
points. So coordinates on the right and bottom of the texture plane are
non-inclusive. You can also specify fractional numbers for u and v, to
indicate a point part-way across a texel. Since the texture plane is
infinite, you can specify larger values than the size of the texture. This
can be used to tile the texture several times across the polygon."

Ben Davis