Xref: news2.mv.net comp.os.msdos.djgpp:4096 From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: Making the nearptr hacks use longs. Date: Tue, 21 May 1996 15:19:10 +0100 Organization: The University of York, UK Lines: 26 Message-ID: NNTP-Posting-Host: tower.york.ac.uk Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp On Tue, 21 May 1996, Eli Zaretskii wrote: > `dosmemputl' (and `movedata') already use 32-bit movsd, so I don't see > how you can get any real speed-up here. The only situation where nearptr > is faster is when you operate on single pixels or small groups of > pixels. If you need to move large buffers, `movedata' is as fast as > nearptr, but much more safe (as it doesn't disable memory protection), > and also works on any DPMI platform. Absolutely. I think the only benefit of near pointers is ease of coding, not speed. Writing 'screen_addr[x+y*w] = color' is a lot easier and more flexible than calling the farptr functions, but I've yet to notice any major speed differences between the two. Even when writing single pixels (which is the worst case for far pointers, requiring a segment load per pixel), when I did a test program that timed a mode 13h putpixel both ways, I only got a 3% speed increase with nearptrs. Using more complicated graphics routines (lines, blits, etc) I couldn't detect any speed difference at all... /* * Shawn Hargreaves. Why is 'phonetic' spelt with a ph? * Check out Allegro and FED on http://www.york.ac.uk/~slh100/ */