Mail Archives: djgpp/1996/05/21/15:07:51
Xref: | news2.mv.net comp.os.msdos.djgpp:4096
|
From: | Shawn Hargreaves <slh100 AT york DOT ac DOT uk>
|
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: | <Pine.SGI.3.91.960521150856.16018B-100000@tower.york.ac.uk>
|
NNTP-Posting-Host: | tower.york.ac.uk
|
Mime-Version: | 1.0
|
In-Reply-To: | <Pine.SUN.3.91.960521075640.13486B@is>
|
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/
*/
- Raw text -