From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: Graphic Acceleration ? Date: Mon, 15 Jun 1998 20:58:27 +0100 Organization: None Message-ID: 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 Precedence: bulk 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