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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


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.