Mail Archives: djgpp/1997/03/04/19:34:38
Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk> wrote:
>Ove Kaaven writes:
>>1. Using POLYTYPE_PTEX, polygon3d_f bombs with SIGFPE when looking at
>>my (vertical) wall at extremely small angles (wall and camera ray
>>almost parallel). Here's a traceback, just in case.
>Argh: I don't like the sound of that!
>Are you sure the problem is the small angle, and not the Z coordinate
>being extremely small? Drawing polygons with a zero Z will result in a
>division by zero, and it's possible that if your input Z values are
>extremely small, rounding errors are truncating them down to zero.
That was not the case; the distance seemed to not matter.
And the real problem might appear to have been leftover object files
from 2.2 beta? Sorry to trouble you for that.
(I can imagine you must have had a difficult time fixing that for the
release.)
>>2. The perspective-correct mapping is also somewhat slower than what's
>>appropriate for games like Doom or Duke3D. By looking at the Allegro
>This is true. But a Doom engine is a very specialised case involving a
>lot of restrictions on what can be displayed, which I don't think is
>appropriate for a general-purpose lib like Allegro.
Well, if it's really general-purpose, then it should have misc.
specialized routines, to cover every case. (Am I right, or am I
right?)
I don't mean to restrict the potential of Allegro, you should still
have polygon3d for "normal" 3D, I was just thinking that additional
specialized routines (vertical3d, horizontal3d) would just extend its
potential even further, to fast Doom-like games, if the speed of the
generic polygon3d can't be improved much on.
>>vertical surfaces, or even better, the method described in zed3d
>>(letting the logical scanlines you map onto be slanted themselves) to
>>have a very fast perspective mapper?
>I'm pretty sure that would be slower than my method, because it wouldn't
>allow multiple pixels to be processed in unison with 32 bit writes, and
>tracing arbitrary lines through video memory would do bad things to the
>bus bandwidth and SVGA bank switching. My perspective divides are very
>slow on a 486, but almost free on a pentium since they are pipelined to
>run in parallel with the integer instructions for the previous set of
>pixels...
Hmm, I thought to have found ATEX so much faster than PTEX that that
would be viable (but on memory bitmaps, of course). Maybe that was
just another 2.2 beta thing.
>>3. What should I give Shawn for his excellent library?
>Send me a complimentary copy of any programs you write with it.
sniper.exe (yuk)? Or do you also want the 2-days-of-development
shoot-the-target school lab "hit" (heh heh "everyone completed v1.0 in
15 seconds, even the slightly braindead Hans, so he liked it") ?
>>4. Where should I post this to keep it from being off-topic?
>I don't think this is off-topic. I don't have a copy of the group
>charter handy, but I'm pretty sure that djgpp-specific issues like FPU
>exceptions and libs like Allegro are appropriate (the best way to do
>texture mapping is more dubious, but I'd be tempted to give that the
>benefit of the doubt and allow it as well, as long as it didn't turn
>into a lengthy thread). Am I right? (DJ? Eli???)
Hmm, what I suspected. At least any follow-ups to this is likely to be
somewhat off-topic.
- Raw text -