Mail Archives: djgpp/2001/01/29/13:51:33
In article <953s8i$nsc$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE>,
Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de> wrote:
> [Could you all please reduce quoted content to the part you're
> actually referring to? Thanks.]
>
> Tom St Denis <stdenis AT compmore DOT net> wrote:
> >> On Sun, 28 Jan 2001 20:35:53 GMT, Tom St Denis
<stdenis AT compmore DOT net>
> >> wrote:
> [...]
> >> >I get 850,000 hlines per sec with DJGPP and 400,000 with MingW.
> >> >
> >> >Any clues to why it's slower?
>
> > Well it gets wierder. My 3d library+test runs at the same fps in
djgpp as
> > ming. It's only tests/test.exe that differs.
>
> That latter one is not a surprise at all, IMHO. Unless yours is an
> extremely strange 3D library, it's almost certainly going to be
> limited by other factors than execution speed of single API calls. Or
> if it's limited by API call processing, then the API call it
> bottlenecks is hardly ever going to be hline(). 3D textured and
> lighted polygons exercise other functions much more heavily.
>
> Actually, I'd be surprised if a 3D library ever executed a single call
> of the hline() method. Horizontal lines simply don't happen often
> enough, in 3D, to make it worthwile checking for this special case and
> calling the specialized hline() for them.
Um with POLYTYPE_FLAT I thought it always uses hline to draw scanlines,
that would make sense since they are fast to draw.
At anyrate I think it may be either a bug in test.exe or like they said
API overhead.
Tom
Sent via Deja.com
http://www.deja.com/
- Raw text -