From: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: linear screen access under vbe2.00
Date: Thu, 16 Jan 1997 20:05:21 +0000
Organization: None
Lines: 27
Distribution: world
Message-ID: <4matOxABoo3yEwN+@talula.demon.co.uk>
References: <5bbier$1j6 AT lyra DOT csx DOT cam DOT ac DOT uk>
NNTP-Posting-Host: talula.demon.co.uk
MIME-Version: 1.0
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

>im trying to write to a 65k screen mode using djgpp. i managed this 
>quite easily with the far pointer method, but it was slow so i decided 
>to go for the nearptr method instead.

In my experience, nearptrs don't make very much difference with complex,
optimised drawing operations. Allegro is written entirely with far
pointers, but I once did a test of rewriting some of the functions with
the nearptr technique. It did help a bit with the simpler routines (the
putpixel went about 3% faster) but with anything of any complexity, like
blitting a 32x32 image to the screen, the difference was too small to
measure. To my mind the real benefit of nearptrs is ease of use, since
they can be treated as regular C pointers, not speed...

>    videoptr[320+640*240+__djgpp_conventional_base] = 0xffff;

The videoptr is a pointer to a short (16 bits), so the array index is
multiplied by two in order to calculate the actual memory address. You
really don't want to do that to the __djgpp_conventional_base :-) Try
something along the lines of:

        videoptr = (short *)(mi.address + __djgpp_conventional_base);
        videoptr[320+640*240] = 0xffff;

/*
 *  Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
 *  Ghoti: 'gh' as in 'enough', 'o' as in 'women', and 'ti' as in 'nation'.
 */