From: "George Kinney" Subject: Re: Is the FAQ wrong about FAR/NEAR ptr speed Newsgroups: comp.os.msdos.djgpp References: <33D29BAD DOT 43F3 AT lausd DOT k12 DOT ca DOT us> Organization: The Unknown Programmers Message-ID: <01bc9594$2a38df80$f78033cf@pentium> NNTP-Posting-Host: 207.51.128.247 Date: 21 Jul 97 04:59:09 GMT Lines: 34 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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.