www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/04/11/04:32:28

Date: Thu, 11 Apr 1996 11:24:59 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "o'toole casey" <cotool1 AT umbc DOT edu>
Cc: djgpp AT delorie DOT com
Subject: Re: GRX20 Speed
In-Reply-To: <4kfcg7$2bh@umbc9.umbc.edu>
Message-Id: <Pine.SUN.3.91.960411112018.27524N-100000@is>
Mime-Version: 1.0

On 10 Apr 1996, o'toole casey wrote:

> 3d program was running at about 16 FPS.  So I commented out all of the
> transform and draw functions and only left the ClearContext and
> GrBitBltNC functions.  I was STARTLED to see that I could only achieve
> around 40 FPS just clearing a memory context then writing it to the
> screen in 320 x 200 x 256 mode.  A similiar program written in 
> Borland C 4.5 REAL mode accomplishes 160+ FPS.  
> 
> Now, I imagine in order to accomplishe the speed Im looking for that
> Im going to have to switch back to real mode and write my own
> bitblt functions.. I read about this in the DJ-TUT file somewhre..

I'm not sure you aren't jumping to conclusions too fast.  I hear that GRX 
2.0 is not polished enough in some areas, so you might as well look into 
the source of those bitblt functions.  If handled correctly (e.g. with 
the `nearptr' facilities of DJGPP) there is no reason that bitblt should 
be slower than in real mode, since no mode-switching should be involved.
In fact, with SVGAs that sit on a 32-bit wide bus (VLB or PCI), you might 
even see greater speed, because in real mode you move in 16-bit words.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019