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