Date:	Sun, 27 Feb 2000 10:20:01 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Kalum Somaratna aka Grendel <kalum AT crosswinds DOT net>
cc:	djgpp AT delorie DOT com, trancelucid AT videotron DOT ca
Subject:	Re: Fastest bitblt?
In-Reply-To:	<Pine.LNX.4.10.10002261941000.1032-100000@darkstar.grendel.net>
Message-ID:	<Pine.SUN.3.91.1000227101940.14604S-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sat, 26 Feb 2000, Kalum Somaratna aka Grendel wrote:

> However it is worthwhile to consider the fact that ID software extensively
> used nearptrs for the code for Quake.

id's code was heavily hand-optimized assembly, so it made sense to
squeeze every bit of performance in their case.  I doubt that many
DJGPP users would spend so much effort in optimizing their code.
Without that, nearptr is almost of no effect on the speed.

In fact, I challenge you (or anybody else) to come up with a
non-trivial program where there's a significant difference between
farptr and nearptr methods (assuming, of course, that neither variant
does anything stupid to slow it down).  I once tried both approaches
on a few programs, and was unable to see any measurable effect.

> Just see how much more nicer the code would be if written with nearptrs
> enabled,

You can hide farptr inside a C++ class, so it will look as nice as
nearptrs.

- Raw text -