Date: Thu, 21 Oct 1999 17:06:18 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Tom Fjellstrom <tomcf AT connect DOT ab DOT ca>
cc: djgpp AT delorie DOT com
Subject: Re: Plague of the slow 'blit' routine :)
In-Reply-To: <380E497E.273EE838@connect.ab.ca>
Message-ID: <Pine.SUN.3.91.991021170208.4001C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Wed, 20 Oct 1999, Tom Fjellstrom wrote:

> I've been playing around with mode 13h, and the
> only thing I've been really stuck on is my 'blit'
> routine. Suffice it to say it is extremely slow.
> It may have to do with '__djgpp_nearptr_enable()'ing
> before blit and '__djgpp_nearptr_disable()'ing after,
> for every bitmap

These two functions are very slow, because they issue a DPMI function 
call.  You should call them as seldom as you can.  The FAQ explains what 
are the circumstances when you MUST call them.

However, in general, I'd suggest to toss the idea of using nearptr hack, 
and switch to dosmemput and farptr functions instead.  They are almost as 
fast as nearptr, even in tight loops, don't require an expensive call to 
__djgpp_nearptr_enable, and don't disable memory protection.

The FAQ clearly recommends not to use nearptr, so why do you need to mess 
with it?