delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/01/31/00:46:38

From: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Allegro Vesa mode graphics
Date: Thu, 30 Jan 1997 20:08:16 +0000
Organization: None
Distribution: world
Message-ID: <gRdbzIAw+P8yEwlA@talula.demon.co.uk>
References: <32e9265d DOT 3993736 AT news DOT primenet DOT com>
<s8eIIEBjhS7yEwuh AT talula DOT demon DOT co DOT uk> <32EF7C30 DOT 771B AT rug DOT ac DOT be>
<MPG DOT d59be2183f0da01989690 AT news DOT netwizards DOT net>
NNTP-Posting-Host: talula.demon.co.uk
MIME-Version: 1.0
Lines: 23
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Ansel Sermersheim writes:
>Seconded.  Even if it works, get and use Univbe (called Display Doctor 
>now).  I'm running a PCI ATI m32 chipset.  Before, with allegro 
>autodetecting vesa 1.2 mode, I got 26k putpixels per second.  After 
>Univbe, it went to 660k 8-)

The difference between real mode VESA and a linear framebuffer can
certainly be spectacular, but those figures are hardly typical. The
major expense with the VESA 1.2 API is calling the bank switching
interrupt, and when drawing pixels to random locations, a bank switch is
needed for virtually every pixel. With larger drawing operations that
are more bank-coherent, the speed difference becomes far less (eg.
blitting an entire 640x480 image onto the screen only requires 5 bank
switch operations). So your example is extremely biased: timing random
rectangles or 32x32 sprites would give a far more meaningful comparison.

VBE 2.0 is still faster, though, just not by quite as much as you
implied :-)

/*
 *  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'.
 */

- Raw text -


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