Mail Archives: djgpp/1997/04/01/16:20:06
Hello!
Leath Muller wrote:
>
> > with an FPE with the only traceback on some obscure _triangle+1055. So
>
> 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...)
It is DJGPP code; the Allegro lib, more specifically.
> > 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
Hey, if it was so easy... ;)
> 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...
The problem is that once projected the coordinates fly up to a value
that overflows the poly routine. I think the clipping is being good done
(I placed it and it seemed to work), but the trouble is now when I get
very (*very*) close to a polygon with relatively large world
coordinates; the projection routine would map correctly the vertex that
falls into the screen, but the other ones would get to the edge.
Example: a vertex on 0,0 and others on 30,0 and 30,30, getting closer to
the first one, when z gets small then dividing by it (what project does)
is really a multiply. I have to display it because 0,0 maps on the
screen, but meanwhile the 30's on the coordinates project to larger
values, larger, larger... crash :-)
> > 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
I wish I would ;)
> 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...
I'll try to.
Many thanks
--
_*
\ |/_|\/||\ sigma AT ctv DOT es
_\|\/| ||_\ (formerly Sigmatech) Jerez / Cadiz / Spain
- Raw text -