delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/06/16/20:30:47

From: George Foot <mert0407 AT sable DOT ox DOT ac DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Graphic Acceleration ?
Date: 16 Jun 1998 23:54:29 GMT
Organization: Oxford University, England
Lines: 63
Message-ID: <6m70jl$2al$1@news.ox.ac.uk>
References: <01bd947a$c427b720$92c809c0 AT chessa> <6m3brb$qoq$2 AT news DOT ox DOT ac DOT uk> <xK7roKAjzXh1EwzA AT talula DOT demon DOT co DOT uk> <MPG DOT fefe50f51139c229897a3 AT news DOT virgin DOT net>
NNTP-Posting-Host: sable.ox.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

On Tue, 16 Jun 1998 16:56:31 +0100 in comp.os.msdos.djgpp Andrew
R. Gillett <a DOT gillett AT virgin DOT net> wrote:

: What kind of speed increase over VESA2L does VBE/AF give? My newest 
: project runs in 800x600x16bit, so it is a tad slow. My video chipset is 
: Tseng Labs ET6100, btw.

It depends to a large extent on what exactly you are doing.  Your
programs will need to be written in a certain way to benefit fully
from the acceleration without being rendered totally useless if
acceleration is not available.

As an example of what I meant there, with acceleration you can blit
from screen to screen very quickly -- but you mustn't be tempted into
relying on this because if acceleration is not available your game
will be extremely slow (since screen to screen blitting is usually
done in Allegro by blitting to a memory buffer first).  You have to
take a little care to ensure that it will work both on accelerated
cards and on unaccelerated or unsupported cards.

The general way to do this and still take advantage of accelerated
screen-to-screen blits is to first find out whether acceleration is
available for this function.  If it isn't, your game should continue
to store its sprites in memory.  If acceleration is available, you can
allocate an off-screen buffer and put as many of your most-used
sprites there as you can; this will depend upon the amount of
available video memory of course.  This way your code will be blitting
from memory if there is no acceleration (or not enough video RAM to
store the sprite in the off-screen buffer), and it will be blitting
using hardware acceleration from the off-screen buffer to the
displayed screen if the acceleration and video memory are available.

Screen-to-screen blitting is probably the most significant accelerated
feature.  If you download the FreeBE/AF source distribution you can
see all of the possible accelerated functions.

There are other senses in which an AF driver can be faster than other
drivers, in particular VESA 1.x.  Allegro communicates with VESA 1.x
using interrupts, which is a very slow way to do it.  I've written a
FreeBE/AF driver for the Avance Logic (which I haven't got around to
sending to Shawn yet... sorry!), and the first thing that I noticed
was that the bank switching using my driver was far faster than the
VESA driver's bank switching.  Calls to AF drivers are just like calls
to your own functions, and all my bank switcher needed to do was a
couple of port writes.

I think VBE/AF is potentially useful for more than just hardware
acceleration; it's a way of providing chipset-specific drivers as
loadable modules.  In this way, the game can be distributed without
the chipset-specific video drivers, and people can then download only
the driver they want to use.  Plus of course they only need one copy
of this driver; programs will find and use it automatically.

I don't know whether or not it would be practical (or desirable) to
convert Allegro's existing chipset drivers to FreeBE/AF drivers and
remove them from Allegro; this could save image size and Allegro
source size but might annoy people who don't like the idea of
downloading their video driver separately.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk

xu do tavla fo la lojban  --  http://xiron.pc.helsinki.fi/lojban/lojban.html

- Raw text -


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