(This column first appeared in the November 8, 1994 issue of PC Graphics Report)
Yep, I actually used to write video games. Back in the early days of the PC, I developed a graphics animation library on the PC, and a game called Fleet Sweep, a Space Invaders take-off that ran on the original IBM PC on a CGA display. If you look for it hard enough at a software flea market, you might actually find a copy of it. Around the same time, I also helped port JumpMan to the IBM PC and PCjr.
The sort of animation routines I developed were state-of-the-art for that era. I designed and developed routines to handle software sprites, player-missles, flicker-free overlap of animated objects, and even double buffering via selective rectangular updating. I also developed a graphics editor to go along with all the animation code. Of course, back then, state of the art was all 2-D stuff. Rather flat, but with enough action to still make your heart rate surge. Alas, except for some die-hard end users, no one took games seriously at the time, least of all vendors of PC hardware technology.
When I look around me today, I notice that everything pertaining to game development has changed. First of all, the game technologies have totally eclipsed the sort of technology I developed in the early ’80s. Where 2D was once the master, games have evolved to an action packed 3D look. It reminds me of the change painting went through once artists realized they could paint in perspective back during the middle-ages. With the new technology, and dropping PC costs, there has been a resurgence in the popularity of 3D games.
Where once games were an occasional pastime, they are now a complete obsession. Whole markets have been built around games, most notably the multimedia market of sound boards and CD-ROMs. As a result, it appears that game developers are no longer deemed third class citizens. Game developers now actually hold celebrity status. In a world originally dominated by the Borlands, Microsofts, and Lotuses, we now see companies like 47-Tec, Software Toolworks/Mindscape, id Software, Access, MicroProse, and others dominating the PC skyline.
The Game Developer Interface
Back over a decade ago, when I was a game developer, PC companies couldn’t care less that the company I worked for developed exciting computer games. For that matter, our efforts were frequently scorned. No one took game developers seriously.
It astounds me to no end how that scenario has changed. Now, it seems that game developers need to hire dedicated liaisons to cope with the time and bandwidth demands various PC software and hardware companies are attempting to impose on them by lobbying them to use their products and technologies. I’ve tried to categorize the groups I see lobbying for the attention of game developers, and come up with quite a large number:
2D API Vendors
This category is primarily focused around Microsoft and its attempt to get game developers to move to Windows via WinG. There are a few others in this group as well, but none significant enough to list.
3D API Vendors
This group seems to grow on a weekly basis. Current “members” include Argonaut, Criterion, Intel, Microsoft, RenderMorphics, and Silicon Graphics. All of these companies are offering some way of generating and manipulating 3D images in software, with some level of hardware acceleration occasionally recommended (especially in the case of SGI’s OpenGL).
There are several types of tools providers. There are those who have created products for other markets, but have accidentally discovered that their products are well suited to the games environment. This group includes Autodesk with 3D Studio and Animator Pro, as well as Macromedia and Asymmetrix with their respective products.
There are some games companies that have managed to build engines that are portable, such as what id Software has done with the Wolf-3D engine by licensing it to Capstone for use in Corridor 7.
Finally, there are companies who have designed products specifically for the game market. Usually, these are expensive, vertical market applications, some of which may require additional hardware. Wavefront is an example here. Tools providers are perhaps the least intrusive lobbying group, in the sense that they have proven their worth over time. They also seem to be the least pushy, which sits well with game developer attitudes (i.e. they tend to prefer passive selling vs. hard selling).
Say hello to MPEG, Indeo, Cinepak, and countless other methods for compressing and playing back video on a computer. Some require royalties, some only require use of the game developer’s name in press releases, and some change their focus and approach on a regular basis.
This category covers both hardware and software. There are a handful of key sound driver suppliers, who offer universal sound APIs under DOS to a large number of different sound boards. There are, of course, the large number of sound hardware vendors, who have wised up to the point that in addition to their own proprietary interfaces, always make sure to provide some backward compatibility to de facto industry standards. Of course, the companies responsible for those standards also need to advance their technology. Creative Labs, for example, has a developer’s program, which, in exchange for attending one of their annual seminars, offers free hardware.
Well, let’s see… there’s Microsoft with Windows 3.1, IBM with OS/2 3.0, and Microsoft with Windows 95. Microsoft is coming up with all sorts of reasons (and tools) for developers to switch to some flavor of Windows. Key benefits touted: Windows makes installation and configuration easier (in some ways, perhaps); Windows offers WinG and DCI support, which makes it almost like DOS frame buffer access (isn’t that what DOS is for?); Windows has integrated sound support (but developers complain about its lack of quality and real synchronization capability); and Windows 95 will probably support 3D via 3D DDI (when and if still to be seen). IBM is just starting to offer OS/2 as a games platform, but will probably have a pretty difficult time going up against the Microsoft momentum.
This will be the major push in 1995, it appears, with Artist, Matrox, 3DLabs, Yamaha, Cirrus Logic, SPEA, and Kubota all having announced new 3D acceleration hardware, and at least 6 other companies having made overtures in that direction in the last few months. Each one of these devices is interfaced with differently, and each offers differing levels and types of graphics acceleration. In other words, this area is a total mess. If a leader emerges out of the 3D API battles, and that API is viable with the 3D hardware being unveiled, there might be some hope for this new and growing category, but right now there seems to be too much noise resulting from competing overtures to developers.
2D hardware seems rather passe in comparison to sexy 3D hardware, doesn’t it? Ironically, games developers predominantly still use dumb frame buffer animation. This means that they don’t use even the simplest acceleration features commonly found in 2D SVGAs. And, even so, everyone wants the game developers to make the leap to 3D APIs and hardware… Nevertheless, a few pragmatic folk are trying to get games developers to take the 2D hardware acceleration step first. The benefits in game performance are significant, as ATI’s Fox demo at a recent GamePC Consortium meeting demonstrated.
Input Device Companies
If there is game developer lobbying category struggling to emerge, this is it. All PCs have keyboards, and most have mice. All the games I’ve tried support these two input devices. Beyond that are a variety of joysticks and game controllers (both are offered numerous flavors, and all are reasonably well supported in compatibility modes). Beyond that are 6 dimension (6D – X, Y, Z, roll, pitch, yaw) of freedom input devices. The 6D devices are sparsely supported at best, but with 3D-style games getting a lot of attention, the 6D input devices are a natural complement. But there are a lack of these devices at affordable price points. The least expensive appears to be the Logitech CyberMan (around $80), but without much finesse. Spacetec IMC is going to be releasing a “Space Player” (based on their Spaceball technology) for games shortly in a slightly higher price range, and beyond that, a few other manufacturers are also looking to release 6D input devices. The problem these manufacturers face is that they all, due to the lack of a uniform API, still have to peddle their devices individually to the game developers in order to convince the developers to free up precious resources to support the new input device. For some reason none of the 3D API companies I spoke to at last week’s GamePC meeting seemed at all interested in providing a 6D input API as part of their interfaces. Seems like a major opportunity is being ignored, since proper manipulation of 3D space is perhaps the biggest limiting factor in 3D application acceptance.
VESA’s promoting VBE/AI (VGA BIOS Extension/Audio Interface) and the forthcoming VBE/Core 2.0 specification (which includes protected mode VGA frame buffer access) to game developers, and The GamePC Consortium is trying to get all the groups listed above together with the game developers to figure out how to get better game performance out of PCs. Both efforts end up demanding even more time from game developers to keep up with.
So, by my count, there are at least 40 different entities (and that’s not even counting Microsoft and Intel multiple times for their different efforts) vying for the attention of all game developers. That means if each game developer devotes just a single hour to each vendor every couple of weeks, it requires a full time employee, what with the reports and summaries that person would have to generate. The reality of it is that some vendors alone take 40 hours a week while others require virtually no time for interaction. Scary use of bandwidth either way.
What Many Game Developers Really Want
There appears to be quite a bit of disparity between what most game developers seem to want, versus what all the vendors appear to be trying to sell them.
At the first GamePC Consortium meeting in late August, a number of developers spoke up about this particular topic, and here’s a summary of what the game developers wanted:
- No other software getting in the way
Game developers are typically performance freaks. That means that they don’t want anything getting between them and sheer performance on the systems their games are running on, which means that chunky operating systems, like Windows and OS/2 don’t really fit the bill, and which is why DOS, for all its frailties is such a popular games platform.
- A stable and consistent boot and install environment
Currently, DOS games (the majority) each seem to require specific boot environments, including varying (although often unrealistic) amounts of free low memory, disk caches (or none), memory managers (or none), a VESA VBE interface for the graphics board in the system, certain types of sound boards, and possibly some amount of extended memory. Windows fits this bill, to some extent, except that game developers don’t want Windows running when their game is running. Their game should have complete control of the system it’s running on, when it’s running. Alas, this is inherently contrary to the Windows design philosophy.
- Wanting to transparently support a variety of hardware
This does not mean putting extra layers upon layers of software APIs between the game and the hardware. It means that hardware designs should be compatible and consistent wherever possible, and only minimalistic APIs should be present, if absolutely necessary. Game developers don’t want to have to add special support for each type of graphics board and sound board out there (unless they get paid a lot to do it or find it to be really neat – the former is more likely than the latter). Windows fulfills part of this, but really gets in the way from a minimalistic API perspective.
- The ability to double buffer/page flipping
This seemed to be the major hardware feature request from game developers wanting to do animation. All it involves is being to create a scene on the graphics board, off-screen, and being able to flip to the display of that area during a vertical blank. Then the other page on the board gets updated and display in the same fashion. Ironically, most modern graphics boards are capable of this at lower resolutions (like 640x480x256 colors), but no APIs I know of actually take advantage of this hardware capability, yet.
- Being able to trigger an operation on a vertical blank
This includes page flipping, palette cycling, and general animation. This was the second most requested feature.
- Being able to use off-screen memory on the graphics board
This feature is related to the page flipping request, but reinforces the requirement for consistent graphics hardware memory architectures, since such consistency would allow developers to intelligently use off-screen memory for storage of sprites, textures, and text. If such consistency existed, then game developers would be much more likely to use BitBLTs and related graphics acceleration features. Tied to this request was linear frame buffer access, as most developers are using, or starting to use, DOS extenders.
- Being able to switch resolutions on demand
This allows game developers to select resolutions best suited for a given task, such as 320×200 for digital video playback, and 640×480 for other types of animation or display.
3D APIs just aren’t that important yet
Surprisingly, the game developers present at that GamePC meeting indicated that while they thought 3D was an important technology, it just wasn’t that important to them yet. They were more concerned about getting current games done for the ’95 Christmas season (which means finished software by next summer) then figuring out what to do with 3D.
Hardware Vendors vs. Game Developers
In all the varied discussions between these two groups I’ve been witness to of late, the hardware vendors universally seem to want to force game developers to use Windows, because that’s where all the vendors have focused their development efforts. Additionally, with the exception of a DOS MPEG API specification and VESA VBE (both worked on by a small subsets of the lobbying hardware vendors), none of the hardware vendors have bothered to get together to create DOS APIs and support for game developers. And DOS DDKs for the various 3D APIs appear to be difficult to come by, based on my experience, further hampering development in the DOS environment.
At the other end of the spectrum, the game developers are largely happy with DOS and comfortable with the DOS environment. In a few areas (as I pointed out earlier), Windows could be of benefit, but only if the game developers could just switch it off when desired – something that’s not exactly straightforward to do.
All in all, it appears that we’re getting nowhere quickly if vendors don’t listen to game developers and game developers aren’t vocal enough about what they want from vendors. But that’s life, isn’t it?