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

["Ben Davis" <ben@xxxxxxxxxx>]

Instructions about merging with the BeOS patch at the end of this message...

> I was meaning to apply the mixer one; I'll do that now.  The poly3d
> one will have to wait for someone who understands it.

If it helps, here's a summary of the poly3d patch:

When polygon3d(_f)() is called, the old code takes the first three vertices
and uses them to work out whether the vertices of the polygon are specified
in clockwise or anticlockwise order. Then a double-linked list of edges is
created (excluding horizontal edges or edges clipped off the top or bottom
of the bitmap), and it's always created in clockwise order. That is, if the
vertices go anticlockwise, they are read in reverse order when creating the
edge list.

In the new version, the edge list is created in the same order as the
vertices. Later on, when doing the polygon, the variables 'left_edge' and
'right_edge' may not actually be at the left and right. They will be
reversed if necessary at this stage.

This eliminates the need to deduce whether the vertices go clockwise or
anticlockwise, so the routine now works when two of the first three vertices
are coincident, as sometimes created by clip3d_f().

I also modified the code so that _fill_3d_edge_structure(_f)() returns an
int, 1 if the edge has been created in the list successfully, 0 if it is
horizontal or clipped out of existence. That way, the vertices' coordinates
are converted to integers only once; in the old code it was done twice.

I renamed two functions to follow the '_f' suffix convention (even though
they aren't quite equivalent in this way ... ?), and added a prototype to
aintern.h. It could be that these prototypes are unnecessary, but I thought
it was safer to leave them, and I wanted to be consistent.

I updated the test and an example so that they don't exclude the bottom and
right edges of the texture bitmap. Finally I replaced a section of the docs
on how u and v are used, clarifying all the vagaries of shared vertices,
excluded texels and so on.

The patch does work - I'm using the modified version now on my computer, and
it hasn't gone wrong once.

--------------

> > Also note that, if the poly3d patch is to be applied, it will have to be
> > fiddled a bit. See my last e-mail for details.
>
> Don't worry, patch is usually smart enough, and if not it'll alert
> you of conflicts.

It'll alert you of conflicts then - I did look at the file properly before I
piped up :-)

The BeOS patch (the one applied recently) inserts the following block of
code somewhere in poly3d.c:

/* Dirty hack to make this to work with BeOS. This is the second very
 * strange hack on BeAllegro: see midi.c for the other one.
 */
#ifdef ALLEGRO_BEOS
   { int i; for (i=1; i; i--); }
#endif

My patch inserts the following line *in exactly the same place*:

if (edge->bottom < edge->top) return 0;

I don't think PATCH would risk dealing with this automatically somehow.

It looks to me as if the BeOS patch is designed to force the compiler to
reload a variable from memory or something (most likely owing to a compiler
bug). It may be that my block of code inadvertently has the same effect. I
think we need to try applying my patch to the older version (without the
BeOS patch), see if it works under BeOS, and then do the BeOS hack again
manually if necessary.

> BTW, it'd make it easier if you would use forward slashes as
> directory separators.

Sorry. I won't inflict my Micro$i$m on you again.

Ben Davis