www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/08/16/01:05:03

Message-ID: <32141C89.5DB5@gbrmpa.gov.au>
Date: Fri, 16 Aug 1996 15:00:25 +0800
From: Leath Muller <leathm AT gbrmpa DOT gov DOT au>
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: buffer -> screen transfers
References: <320647A3 DOT 5827 AT cadvision DOT com> <3209b332 DOT 21898266 AT news DOT wolfe DOT net>

> Also, you can improve the speed on this by disabling the memory
> protection and assigning a pointer directly to video memory.  Here's a
> sample fragment...

<code deleted>
 
It improves speed a LOT! :)
 
> I haven't had much time to mess with VESA programming so maybe someone
> else can say if there are any problems with this when you do bank
> switching.  Also, remember that this disables all memory protection,
> so use __djgpp_nearptr_disable() when you are done with your video
> manipulation.  The video pointer must be reassigned if you disable,
> and then re-enable memory protection.  The enable / disables are slow,
> though, so use them sparingly.

If your not in the final development stages of your program, it ends up
OK to use the farnspoke etc routines because your not too worried about
speed. What I did, was wait until I knew my routines were debugged fully
(fully? yeah right... ;) and then used the __crt0_nearptr_enable (or
similar) flag at the start of my program to disable all memory
protection.
This has the advantage of not having to call the enable/disable calls
all the time, and increases the speed of video intensive subroutines a
LOT!

Its probably also a good idea to use a linear framebuffer if your
interested in speed so that you dont have to worry about bank
switching...

Leathal.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019