Message-ID:	<38627205.C1BAE55D@NO.SPAM.PLEASE.nic.fi>
From:	Antti =?iso-8859-1?Q?Koskip=E4=E4?=
	<antti DOT koskipaa AT NO DOT SPAM DOT PLEASE DOT nic DOT fi>
X-Mailer:	Mozilla 4.6 [en] (Win95; I)
X-Accept-Language:	en
MIME-Version:	1.0
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: nearptr...
References:	<83tjjf$3cg$1 AT newsg3 DOT svr DOT pol DOT co DOT uk>
Lines:	34
Date:	Thu, 23 Dec 1999 21:03:33 +0200
NNTP-Posting-Host:	212.38.225.96
X-Trace:	uutiset.nic.fi 945971996 212.38.225.96 (Thu, 23 Dec 1999 19:59:56 EET)
NNTP-Posting-Date:	Thu, 23 Dec 1999 19:59:56 EET
Organization:	NIC Tietoverkot Oy - NIC Data Networks Ltd.
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Ghalos 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)

It's stable if you know what you are doing. The paging mechanism provides
additional protection. (That's why when Quake crashes, it's always a
page fault, not GP.)

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

YesNo. If using double buffering using system RAM, it doesn't help.
If drawing directly to LFB, it saves additional segment overrides.
(Use fastvid!)
Id uses it because it's so flexible. If you REALLY start reading the source,
you'll find near pointers EVERYWHERE, not only in graphics. In sound DMAs etc...

An interesting thing: Somewhere in the source (well 1.01 src anyway) there's
a comment something like

"We disable LFB mapping when it's not needed, since some cards can't stay
mapped in all the time."

Now what the heck does that mean???

> Ghalos - greg AT holdridge7 DOT freeserve DOT co DOT uk

-- 
- Antti
- To reply, remove you-know-what.

- Raw text -