www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/06/17/00:28:35

From: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Graphic Acceleration ?
Date: Mon, 15 Jun 1998 20:58:27 +0100
Organization: None
Message-ID: <xK7roKAjzXh1EwzA@talula.demon.co.uk>
References: <01bd947a$c427b720$92c809c0 AT chessa> <6m3brb$qoq$2 AT news DOT ox DOT ac DOT uk>
NNTP-Posting-Host: talula.demon.co.uk
MIME-Version: 1.0
Lines: 58
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

George Foot writes:
>VBE/AF drivers can sometimes be obtained from hardware manufacturers'
>web sites, but unfortunately this isn't common; 

I could even say it is very rare. I've been told that there is a free S3
driver floating around somewhere, and apparently Tseng wrote one that
they have for some reason never releasd, but I've been unable to locate
either of these myself. To the best of my knowledge, the SciTech Display
Doctor and the FreeBE/AF project are the only current sources for these
accelerated drivers.

>You can find out more about FreeBE/AF from Shawn's web site:
>
>    http://www.talula.demon.co.uk/freebe/

Hurrah! Come on people, get stuck in and help write some more drivers
for this! I've implemented support for my Matrox card, and we have
Cirrus and Mach64 drivers by Michal Mertl and Ove Kaaven, but there are
plenty more cards just waiting for a volunteer to accelerate them...

>Indeed, the video card can't access main memory, and so
>memory-to-screen blits aren't accelerated.  

Some cards do support a kind of quasi-acceleration for mem->screen
blits, though, which Allegro will use wherever possible. The card
provides a block of memory mapped I/O registers, which the program can
write to instead of the normal video memory, and the accelerator engine
then transfers data from these locations into the appropriate part of
the screen. This is no faster than a normal software routine for
fullscreen copies (it is still limited by the speed of the processor and
video bus), but can give huge speed improvements when you are writing to
a misaligned destination address, because the processor can still write
dwords to these I/O registers, and the shift to an odd address is
handled internally by the video card. This can help a great deal with
things like tile map engines, that might be drawing an entire screen of
32x32 images to an odd pixel location.

>Some cards also support hardware cursor display but I'm not sure 
>whether or not Allegro (or any other program) uses this.

Allegro will use it wherever possible, although this support currently
isn't very well tested (SciTech don't support hardware cursors on the
Matrox yet, so my FreeBE/AF Matrox driver and the Allegro code were
developed in parallel: that is obviously dangerous because if I
misundersood any parts of the spec, I will have made the same mistake in
both places and so failed to notice it). Hardware cursors are really
cool, though. Because they are overlayed on top of the screen image
rather than being an actual part of it, you don't need to turn them off
while updating the underlying image, which eliminates cursor flicker,

Reminder to the original poster: these things only work with recent WIP
versions of Allegro, though. Allegro 3.0 doesn't properly support VBE/AF
acceleration.


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
"Miracles are nothing if you've got the wrong intentions" - Mike Keneally

- Raw text -


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