Re: [AD] bug in polygon3d()

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Bertrand Coconnier wrote:
> I have compiled and tested your example successfully on Linux, DOS and
> Mingw. Unfortunately, the bug has not occured... However the 3
> compilers I have used are 3 different ports of the same compiler : gcc.
> May be DO_PTEX uses some gcc specific stuff ?

I don't know what a gcc specific instruction would be, but AFAICS it's
some floating point assembler (of which I know nothing) and normal
assembler. However, under DOS (hence also djgpp), it calls 

   old87 = _control87(PC_24 | RC_CHOP, MCW_PC | MCW_RC);

then draws the scanline, then resets by calling

   _control87(old87, MCW_PC | MCW_RC);

from do_polygon3d() in poly3d.c. I don't know if this means anything
useful...

> Does your compiler complain when it compiles iscan.s ?

No.

> Can you also verify that your compiler generates the expected code ?

It seems that obj/watcom/alleg/iscan.asm is equivalent to
src/i386/iscan.s, from which it was generated (it is generated by
assembling the gcc-style assembler, then disassembling the result using
watcom's disassembler, then assembling this with watcom's assembler).
That is, assuming fstp and fadd are just watcom's names for fstps and
fadds. Also, I didn't check that all the numbers on the form +50H[esi]
correctly corresponded to the appropriate offset defined in asmdef.inc
or earlier in iscan.s. And I'm not very good at comparing six screen
pages of different dialects of assembler that I don't know particularly
well, without making mistakes... Can it be done automatically?

-- 
Sven Sandberg    svsa1977@xxxxxxxxxx    home.student.uu.se/svsa1977



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/