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

["Ben Davis" <ben@xxxxxxxxxx>]

Only just got George's e-mail - Outlook's forwarding isn't that reliable :-)

> > 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).
>
> That's still the case with the current code.  I think one
> important thing to consider is what the polygon rendering code
> does in any case -- if I tell it to draw to a screen region
> equal to the texture coordinates then I expect it to effectively
> blit the texture, with no artifacts and no missing pixel
> columns.  The old code wouldn't do this, and assuming the
> rasterizers do draw the pixels you specify, the new code is
> wrong too.

I keep referring back to bmp->cr and bmp->cb. These are exclusive :-)

> To explain this better, imagine we draw a square from (0,0) to
> (32,0) to (32,32) to (0,32), using the same values as the u,v
> coordinates in our 32x32 texture.  How long is each side of the
> square?  If it's 32x32, then Ben's solution is fine.  If it's
> 33x33 (as I expect) then the polygon drawing is inclusive of the
> endpoints, so the texturing should also be inclusive.  In this
> case we need to adjust the target u for each scanline.

Exactly. I'd rather the programmer had to do this, than use -0.5 and 32.5,
or settle for half-pixel-thick edges to the polygons.

> It think it might help a lot if the u,v coordinates
> to refer to the same position in the texel as the x,y
> coordinates do in the pixel.  Since line drawing generally uses
> the centres of the endpoint pixels, the old code would then be
> correct, but it depends how Allegro treats its fixed/float
> coordinates -- are whole numbers still the centres of pixels, or
> are they the top left corners?

Lines are a bit different. They sort-of have thickness 1 - the size of the
pixel. The coordinates passed to line() represent a pixel to be filled
completely at each end, rather than referring to an exact point, namely the
centre of the pixel. Edges on a texture have thickness 0, so they can't
really be compared with lines.

> I don't think it forgets a texel, I think it draws too many
> pixels and takes them all into account...

The polygon3d() functions do not draw too many pixels. You don't get pixel
overlaps.

> An important thing I'm trying to consider here is that if you
> draw two polygons which share an edge then you should be able to
> use the same vertex data for the shared vertices -- screen
> coordinates *and* u,v coordinates.  It looks like Allegro was
> broken already here, but I don't think your solution is correct
> -- I think this is better:
>
>     du = (right_u - left_u) / (scanline_width-1)
>
> This makes the u,v of the right hand edge be applied to the
> pixel before the last one drawn, because the last one is an
> overlap to the next tile of the polygon to the right.

Except that there is no overlap. Not convinced? Look at the file, and
explain away the hline(...,x+w-1,...) call.

> I'm not sure what to think of this extra pixel though.  If
> you're tiling polygons and sharing vertex data between them,
> Allegro is (probably) drawing an extra pixel so you need this
> u,v correction to be applied.  If you're just drawing single
> polygons, though, you might not think of it as drawing an extra
> pixel, though it will be making your polygons slightly fatter
> than they should be (if you specify the square I mentioned
> above, its dimensions ought to be 32 along each side).  Maybe in
> fact Allegro shouldn't draw this overlap pixel -- but there's a
> risk that this will make gaps between polygons due to rounding
> errors.  If we did that, though, there would be no need to tweak
> u,v coordinates or gradients at all.

Just that it doesn't exist :-)

So in conclusion, as I said before, I think whole numbers should refer to
whole texels, and half-integers should refer to half-texels. It's also quite
elegant, when you want a whole texture mapped on to a square polygon, to
specify the actual dimensions of the bitmap, eg. (32,32) rather than
(31,31).

Have I been good enough this Christmas to have my patch applied please thank
you Mrs Patterson? :-) (For those who don't know, that's a reference to
Kevin and Perry, Harry Enfield)

Ben Davis