From: broeker AT acp3bf DOT knirsch DOT de (Hans-Bernhard Broeker)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: nearptr...
Date: 23 Dec 1999 18:49:31 +0100
Organization: RWTH Aachen, III. physikalisches Institut B
Lines: 51
Message-ID: <83tnbb$ri1@acp3bf.knirsch.de>
References: <83tjjf$3cg$1 AT newsg3 DOT svr DOT pol DOT co DOT uk>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 945971376 15049 137.226.32.75 (23 Dec 1999 17:49:36 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 23 Dec 1999 17:49:36 GMT
X-Newsreader: TIN [version 1.2 PL2]
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Ghalos (greg AT holdridge7 DOT freeserve DOT co DOT uk) wrote:
> browsing the Quake source I think I discovered that it uses
> __djgpp_nearptr_enable()... does this mean that this method is feasible??
> (previously I got the impression that this was a risky and unstable way to
> do things)

When has being risky ever stopped a game programmer from using some
method :-)? Nearptr mode is not unstable, but most definitely
risky. Plus it doesn't work at all on less forgiving platforms, like
Windows NT. For me, those two arguments alone would suffice to make me
stay away from nearptr mode.

> 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??

Not really, if applied properly. The basic trick is to arrange your
code in a way that avoids use of the single-byte/word/dword functions
_far{poke|peek}*, wherever possible. Concentrate on _movedata()
instead, which technically also belongs to the _far* family of
functions, but doesn't suffer that much overhead. The copy loops
themselves will be as fast as your hardware can do, then.

The underlying assumption is that video RAM is slower than system RAM,
even more so if you consider read operations. So you want to do as
much as possible in system RAM, and only then transfer the result to
video, *once*, in single blit operation. For this blitting step, I
doubt any nearptr() code will be able to beat _movedata() by more than
a few permilles. 

Only if your code writes to video memory in a less strongly organized
way, you'll see any noticeable advantages of nearptr mode. Those small
advantages are that it needs neither segment selector setting nor
segment overrides, both of which enlarge the code and cost CPU cycles.

IMHO, the real advantage of nearptr(), compared to _far*() calls is
just some syntactic sugar. During the era of mode13h games, coders got
so accustomed to treating the framebuffer as a normal C array that
many think this is *the* one and only way to do graphics progamming.
People have been sort of spoiled by this simplicity, and many aren't
willing to face that it may not always be that simple.

Not that I'd dare to claim that _this_ was the reason ID chose
nearptr() mode, of course -- they have far better insight than the
average game coder. I seem to recall they had been using Watcom
before, which supported a nearptr-like method, only (the 'fat DS
hack'), so they wanted to use it with DJGPP, as well.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.