From: George Foot 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> NNTP-Posting-Host: sable.ox.ac.uk To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Tue, 16 Jun 1998 16:56:31 +0100 in comp.os.msdos.djgpp Andrew R. Gillett 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