From: leathm AT solwarra DOT gbrmpa DOT gov DOT au (Leath Muller)
Message-Id: <199703311107.VAA23606@solwarra.gbrmpa.gov.au>
Subject: Re: Allegro 3d question/bug?
To: sigma AT ctv DOT es
Date: Mon, 31 Mar 1997 21:07:10 +1000 (EST)
Cc: djgpp AT delorie DOT com
In-Reply-To: <333C387F.7E61@ctv.es> from "Jose Manuel Lopez-Cepero" at Mar 28, 97 10:30:39 pm
Content-Type: text

> with an FPE with the only traceback on some obscure _triangle+1055. So
> nice the triangle func ends at about 20 bytes... The instruction pointed
> was a 'fldcw', but the instruction above (that theoretically created the
> FPE) was a 'fistp' (I have *no* idea on fpu programming...) My impulse
> was to use FSDB, but hey, it won't work with graphics modes :-(

fistp can be a real pain if you try to write a 32bit integer value while
the fpu is in 64/80 bit mode. You say you have no experience programming in
asm, so I assume this is compiled code by DJGPP - in which case I have
no idea... DJGPP is normally very good (overly good... ;) at loading and
storing the correct control words... if you coded the asm, make sure the
fpu is in single precision mode, this might help (can anybody back me up
on this? I had this problem a while ago and solved my problem by doing
this... I think...)

> I then tracked the possible cause of the error on the drawing of
> polygons with *very* (-8000 or so) large coordinates. Elliminating them
> solves it, but sometimes one of these falls on the screen and then the
> routine dies. Any help? ;)

I would suggest making sure you don't have polygons that large in your
rendering at all: split them up... :)  And I am a little confused as to
what you mean by very large coords... are you talking world or view space?
and if your talking view, do you mean the z value is very large? If you have
clipped the polygons correctly to your view volume, you shouldn't have  this
problem...
 
> Another thing is profiling. I can profile it OK but the routine is
> _very, very, very_ slow! A scene that was drawn at 36 fps with no
> trouble now used 2 seconds for a single frame. There is a routine that

Are you using a pentium? If  you are, use the profiling registers of the
pentium - the code runs at the same speed, and is accurate to a cycle. If
your using a 486, then, ummm, heh heh... ;)  I would actually suggest using
uclock() on a 486 as this should give fairly accurate results, without
killing performance...

Leathal.