Were there any MS-DOS games or graphics software that were known to take advantage of VESA BIOS Extensions/Accelerator Functions (VBE/AF)?
some of the functions defined in the standard are ... Bit Block Transfers (Bit Blt), off screen sprites, hardware panning
Now that Amiga/Atari ST games relied on hardware blitting and sprites very heavily, I'd be surprised if MS-DOS game developers wouldn't start using similar capabilities as soon as video cards started supporting them.
Yes, there were, even though AF became available rather late in the day for DOS games (1996). However AF was never successful or even really relevant.
In the nineties, supporting graphics resolutions beyond those defined by VGA was complex; see Fractint’s source code for evidence of that. Some programs had driver interfaces (notably, AutoCAD and Windows), but for most DOS programs, support was limited to whatever the developers knew or whatever was handled by the underlying library they used. The VESA BIOS extensions were introduced to alleviate this to some extent, and became popular quite quickly (for the time). VBE was designed as a firmware extension, supported by display adapters’ option ROMs, but it could also be implemented by TSRs. Many manufacturers’ implementations of VBE were sub-par, and of course older cards didn’t have them; a company named SciTech carved a niche for itself with its UniVBE tool, which provided a high-quality VBE implementation for a large number of cards. This allowed developers to drop chipset-specific code and rely on VBE instead (at least to set video modes, palettes, and obtain a framebuffer). Many games even shipped UniVBE, or included built-in runtime versions (e.g. Grand Theft Auto).
At the time, manufacturers were also adding acceleration features to their display adapters: hardware-supported functions such as bitblt, drawing geometric shapes, and even handling the mouse cursor. VBE didn’t provide access to any of these, but the target markets were higher-level anyway (AutoCAD, Windows, OS/2...) and drivers could be relied upon to provide an interface to the accelerated features.
SciTech, alongside UniVBE (and SciTech Display Doctor), also developed a Multi-platform Graphics Library, and this did include functions which could benefit from hardware acceleration. They proposed AF to VESA, no doubt based on interface ideas (if not an actual implementation) between MGL and UniVBE, following a driver-based model (VBEAF.DRV) rather than firmware-hosted functions.
Unsurprisingly, any game which used SciTech’s Multi-platform Graphics Library 4.0 or later (1997) for operations such as MGL_bitBlt would end up using VBE/AF functions if MGL determined that that was appropriate.
At least one other DOS library included support for VBE/AF, Allegro (which started life on the Atari ST, although it wasn’t released there). Shawn Hargreaves, the original developer of Allegro, also developed an alternative VBE/AF implementation (replacing UniVBE), FreeBE/AF. I’m not sure that any commercial game was ever developed for DOS using Allegro. See Pac-Horror for one example of an actual game which looks for VBEAF.DRV (the tell-tale sign of a program attempting to use VBE/AF).
It’s possible that some games included VBE/AF support without using a third-party library.
I imagine that SciTech hoped that other companies would also provide AF drivers, and that other developers would rely on AF for graphics. But by the time AF came out, Windows 95 dominated the desktop, and DirectX had made it viable for games, with widespread support from hardware manufacturers (July 1997 saw the release of DirectX 5). SciTech themselves didn’t push AF much after this, and moved on to another driver architecture (Nucleus, which formed the core of SNAP).
At the time where new capabilities came, the market was very fragmented. It was the 80486 era.
Some PCs had low end graphic cards that couldn't do anything (like Tridents, etc) and the top of the line, at that time, was the ET4000 from Tseng Labs.
A common problem is that you couldn't access the whole video memory at once, but by segments. Also, on some cards writing to video memory was very slow (let's not even think about reading).
Due to segments, it was more practical to draw video frames in main memory and then copy the whole thing to the video ram as switching segments not only took some time but made drawing code very complex.
The fastest way to draw sprites on a PC at the time was to compress the sprite in RLE with a width matching the width of the screen and generate code that would simply draw the sprite: copy x bytes to the buffer, skip x bytes in the video buffer, copy x bytes to the buffer, etc. It was almost impossible to switch the screen banks in a high performance way.
Things started to get standardized with VESA, normalizing the cards themselves, and SciTech making a driver supporting many cards and giving access to the whole buffer on many models. It looked good for a couple years, but I don't recall anyone using card specific features.
Eventually the Pentium came out and, all of this became phased out as the VESA architecture was tied to the 80486.
So, to answer the question: I don't remember anyone (I worked on different commercial game projects back then) using card specific features. Usually development was made with cards that exposed the whole video buffer because it was simpler to see when things go wrong. Afterwards, the display was either done directly in video ram for fast cards (they would just put data in a small stack and then write it to their main ram, freeing the CPU faster), or in ram and then copied to video afterwards for small ones.
