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

[Bertrand Coconnier <bcoconni@xxxxxxxxxx>]

Ben Davis wrote :
> 
> 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.

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.

> 
> 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).

> 
> 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 :-)

Right;-)

> 
> 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.

I agree :-) In fact you made me understand that due to the way Allegro
computes gradients it "forgets" one texel. Therefore in the very first
version of the polygon renderer, the right column and the bottom row of
the texture were not drawn : this was a bug. In order to fix it, Calin
Andrian added 0.5 to the gradients to shift the whole texture of a
half-texel to the up/left corner. That way, the bottom row and right
column were drawn and the top row and left column were still drawn but,
as you said, edges of the texture were a half-texel thick.
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.

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. 

George Foot wrote :
> 
> The only thing which makes me hesitate to apply the patch is
> that it might impact people's existing code, but IMHO those
> people are probably unaware of the current system and think that
> it already *is* working the new way. :)

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).

	Bertrand.