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.

  • 2
    VBE/AF came out around the same time as Windows 95 and DirectX which even in it's infancy was considered by many to be the future of PC games.
    – Brian
    Commented Nov 14, 2019 at 15:26
  • 2
    While the Amiga included both a blitter and hardware sprites, the Atari ST had neither. The STE added a blitter years later, but few games were released that use it.
    – Brian H
    Commented Nov 14, 2019 at 16:41
  • 2
    As near as I can tell no video card manufacturer ever implemented VBE/AF in their firmware. There really wasn't much point, by the time it came out (1996) CPUs were fast enough that they could render 2D graphics in system memory and just copy it to video memory every frame. Games were moving towards 3D acceleration and Windows, making 2D acceleration under MS-DOS pointless.
    – user722
    Commented Nov 14, 2019 at 22:51
  • 2
    As a side note: the Atari ST didn't rely on hardware blitting and sprites since it didn't have either. The blitter came (too late) with the STE. All the Atari games do everything with the CPU.
    – Thomas
    Commented Nov 14, 2019 at 23:42
  • 1
    @Ross AF wasn’t designed to be implemented in firmware, it’s driver-based (which of course doesn’t preclude using firmware-provided functions to implement the driver). Hardware manufacturers didn’t provide AF drivers however, which is pretty much equivalent to the underlying point you’re making ;-). Commented Nov 15, 2019 at 6:09

2 Answers 2


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

  • I don't think Allegro was ever actually released for the Atari ST, I have the feeling that's just where the author first started writing it, before jumping ship for the PC. Which makes sense — it and the contemporaneous PC are both 32-bit ISAs with dumb framebuffers and good C compilers.
    – Tommy
    Commented Nov 14, 2019 at 16:32

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.

  • 3
    I think you're confusing VESA Local Bus (VLB), which was tied, more or less, to the '486 and VESA BIOS Extensions (VBE) which were not. The base VBE standard (ie. not including VBE/AF) is still supported by video cards today.
    – user722
    Commented Nov 15, 2019 at 2:08
  • It was tied originally. The VESA bus was tied to the 486, and this is the time where the first VESA drivers came along too. When the Pentium came, the VESA bus didn't make sense anymore, but the original VESA driver didn't either. The Pentium and the VESA extensions came at about the same time. This is the time we were transitioning out of MS-DOS as well. So the question covers the early VESA standard, which was 486/MS-DOS and a little bit (maybe 1 year) of transition between the first extensions and Win95. I don't remember the exact gap but it was quite short.
    – Thomas
    Commented Nov 15, 2019 at 3:01
  • 2
    The question is about the AF subset of VBE, and that puts it firmly in the Pentium era (which also explains why AF never mattered, it happened too late). Commented Nov 15, 2019 at 6:11
  • 2
    No, nothing ties VBE to the '486 or VLB.. The first version of VBE was published in 1989, while VLB was created in 1992. VBE is software, an extension of the IBM PC BIOS video interfaces, and can be implemented as part of the firmware of any VGA compatible card, regardless of the bus used. VLB is hardware, a bus based on the '486 memory interface. Also VESA is the name of an industry organization that defined many different standards, it's not actually the name of a standard.
    – user722
    Commented Nov 15, 2019 at 6:41
  • If you look at the first software implementation, they were called VESA drivers, it's even called like that in the BIOS of the TsengLab cards. When the manufacturers got onboard, that's the naming that stuck. The move to Pentium / VBE2 / Win95 happened in that order, so there was only a short time with the original drivers (VBE '1' if you can call it like that) were used with Pentiums. The nomenclatures are not related, but the changes still happened that once Pentiums started to become mainstream, the vesa bus was dropped, the vbe2 came out and then eventually ms-dos was phased out.
    – Thomas
    Commented Nov 15, 2019 at 14:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .