Date: Thu, 23 Dec 1999 19:18:54 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Ghalos <greg AT holdridge7 DOT freeserve DOT co DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: nearptr...
In-Reply-To: <83tjjf$3cg$1@newsg3.svr.pol.co.uk>
Message-ID: <Pine.SUN.3.91.991223191503.8268L-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 Thu, 23 Dec 1999, Ghalos wrote:

> browsing the Quake source I think I discovered that it uses
> __djgpp_nearptr_enable()...

Near pointers were *invented* at id Software's request, so naturally they 
use it.

> does this mean that this method is feasible??

It is feasible, yes.  Who said it isn't?

> (previously I got the impression that this was a risky and unstable way to
> do things)

It is extremely risky.  The extent to which it is unstable depends on 
your code: if your code is unstable, so will be nearptr.

It should be obvious that id Software invested much more time and 
resources in testing their code than any average DJGPP user could
ever do.

> I can't seem to get the clock resolution to change correctly
> and so I can't accurately benchmark this method against the _far* methods...
> is it much faster??

In most applications, it is not faster.  Don't forget that moist (all?)
the time-critical graphics in Quake are written in tight hand-optimized 
assembly.