Sender: nate AT cartsys DOT com
Message-ID: <37433E36.76780C62@cartsys.com>
Date: Wed, 19 May 1999 15:41:58 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.5 i586)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: New convert has a question
References: <7hv665$pni$1 AT news6 DOT svr DOT pol DOT co DOT uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Ghalos wrote:
> 
> Recently having jumped ship from Borland C++ I found that my project would
> not compile.... well I expected some problems.  Anyway I will have to change
> my graphics functions because as I understand it I cant use the:
> 
> unsigned char far *screen_ptr = 0xA0000000L;
> 
> screen_ptr[x + (y << 6) + (y << 8)] = val;
> 
> thing anymore.
>     I trawled a bit to find out how it can be done under DJGPP and found
> LOTS of ways (including the THIS MAY DESTROY YOUR COMPUTER way) I just
> wondered... which way is the fastest and most reliable for use in Mode 13h?

Far pointers are quite safe and reasonably fast:

_farpokeb(_dos_ds, 0xa0000 + x + (y * 320), val);

If you have a buffered graphics algorithm (draw to a memory array and
blit to the screen), you can use dosmemput; that's about as fast as you
can get.

[Btw: Interestingly, GCC generates better code for `y * 320' than for
`(y << 6) + (y << 8)'.  Try them and see.  Hint: The `lea' instruction
can multiply by five!]
-- 

Nate Eldredge
nate AT cartsys DOT com