Mail Archives: djgpp/1997/07/24/13:50:13
csantill AT lausd DOT k12 DOT ca DOT us wrote in article
<33D29BAD DOT 43F3 AT lausd DOT k12 DOT ca DOT us>...
> from: csantill AT lausd DOT k12 DOT ca DOT us
>
> Thanks to Sinan I'm finally using working FAR PTR mode 13h hack stuff
> & I accidentally got the NEAR PTR hack stuff working on my own. I
> decided to test the speed difference & I found there was none!
> Everybody on the net(including the mailing list) thinks the NEAR PTR
> stuff is faster but on my system it is the exact _SAME_ as the
> FAR PTR stuff(about 90 FPS which is great; leaves alot clocks for
> animation & game AI). But I want to find if it is just my system. I've
> included my code to see if there is any difference. Ive got a
Well, I can tell you that on my system the farptr access is just as fast
as well.
Setting the selector with _farsetsel and using the _farns* forms can be
another improvement. It showed more of a performace gain than near vs.
far on my P75. (It has an on-board S3 Trio32 for video)
I ran the test on my 486/50 (with a modified generic OAK87 based card)
and nearptrs were just slightly faster. I don't know if this is
signifigant since the video systems being compared differ drastically
in their performance in general.
Personally, I didn't like the risk of using nearptr functions, and was
pleasantly surprised to find out farpoke*s were as fast as they are.
Also, I checked what the FAQ had to say about optimizing _far* funcs, and
yup, they do reduce to a couple of ops with optimizations turned on.
At any rate, they seem to be as fast in most cases, and they are safer.
A reasonable trade off IMO.
- Raw text -