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

["Ben Davis" <ben@xxxxxxxxxx>]

> May be, but when I want a rectangle to be drawn from pixel (0,0) to
> pixel (31,31) I do not call rect(bmp,0,0,32,32,c) but
> rect(bmp,0,0,31,31,c) which is more intuitive.

But these are ints, and pixels can't be subdivided. Texels can.

> > 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.
>
> I know but what I mean is that tilling behaves in a strange way :
> according to your convention, drawing a texture from (0,0) to (32,32) is
> the same thing than drawing a texture from (32,32) to (64,64) so it
> seems a texel is shared (but it is not).

This doesn't bother me.

> So, you suggest to remove all those "0.5" and to "remind" Allegro to
> draw the last texel by incrementing the bottom/right texture coordinates
> by ourselves.

That's what we do with clipping rectangles, polygon3d()'s screen coordinates
(wasn't it you who changed the hline() call?), and for loops eg. for
(c=4,c<8,c++) goes from 4 to 7 :-) Also, if we subtract end from start, we
get width.

> IMHO we can reach that goal in another way. So far, the gradients for
> texture coordinates are computed this way :
> du = (right_u - left_u) / scanline_width
> while it should have been :
> if (right_u > left_u)
>    du = (right_u + 1 - left_u) / scanline_width
> else
>    du = (right_u - 1 - left_u) / scanline_width
> This way, the right column texel is not forgotten anymore and it
> prevents the user to increment the bottom/left corner texture
> coordinates by himself/herself. BTW the 0.5 texel shift is not needed
> anymore.

Doing this kind of expansion is *much* more complicated than that. Don't
forget the vertical expansion, and think (read: worry) about what to do with
diagonal edges.

A while ago I wrote half a 3D editor, and the editor could detect
neighbouring coplanar polygons and spread a texture seamlessly over them
all, given the texture coordinates for one of the polygons. The system you
talk about would completely mess up the alignment in this algorithm. I think
people who are clever enough to write 3D code wouldn't get confused about
the kind of sub-texel accuracy I was talking about. It's a small price to
pay to make them specify some of the coordinates exclusively, whereas trying
to get around an unwanted expansion is much harder.

Did you read my suggestion for a complete replacement for the docs? I
*think* it clarifies why texels aren't shared when they look as if they are.
It all comes down to the difference between continuous (float, sort of) and
discrete (int) maths.

With regards to your suggested modification, bear in mind the following.

Suppose you have three consecutive vertices with the following texture
coordinates (0,0) , (32,16) , (48,48) and similar screen coordinates. Say
this is the right-hand edge of the polygon, and we can assume the left edge
is such that these coordinates will be traversed in two segments.

In the first segment, the coordinates (0,0) will remain the same, and
(32,16) will become (33,17).
In the second segment, (32,16) will remain the same and (48,48) will become
(49,49).

So you'll get a discontinuity between the two segments. I don't think
there's any neat way to solve this, unless we leave the coordinates
unaltered. Believe me, I've seen this kind of problem before, and I know :-)
I think we have to retain the property that, if you subtract two texture
coordinates, you get the number of texels in between.

> If we change gradients computations the way I suggest, texture edges
> would be "full texel thick" and existing code should work the right way
> without any change in existing code (including test and examples).

It's no hardship to change the code, especially since my patch already does
it. As for Allegro users' code, I think George Foot is right - especially
about the similarity between Allegro and OpenGL - but then I would, wouldn't
I :-)

Ben Davis