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 developes 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).