OS/2 Game Developers' Report on DIVE

By Chris Shabsin with Kent Lundberg
Last Update: 22 November 1994

At a recent M.I.T. OS/2 USERS GROUP meeting, we had a most excellent presentation for developers interested in writing games for OS/2. The presentations centered around DIVE (Direct Interface Video Extentions). The DIVE architecture permits very fast graphics display (fast, like the multimedia software full-motion video) in a Presentation Manager window. (Basically, DIVE gives you a pointer to the frame buffer in memory.)

The DIVE DLL is included in OS/2 Warp, and is supported on top of OS/2 2.0 and above through the use of Presentation Drivers. There was a beta of the DIVE toolkit on the Warp Beta II CD-ROM. There is information about DIVE contained on the Developer Connection 5 CD-ROM and in the DevCon 5 Newsletter.

The guest speakers were:

Lloyd Webber (ewebber@vnet.ibm.com). Lloyd is IBM's Brand Manager for OS/2 Games from Boca Raton. He is the "Marketing Head" in charge of communicating with game developers, making sure that they get what they want and need to produce OS/2 games. If you are considering writing an OS/2 game, I strongly suggest that you contact him. He is a very nice, very helpful man, and he is in a position to do a lot for you in terms of information and resources. And I mean RESOURCES. 'Nuff said.

Mike Cooper (also said his email address was ewebber@vnet.ibm.com). Mike is a programmer from the OS/2 32-bit Graphics Engine group in Boca Raton. He is working on the DIVE APIs, and will be extending them over the next few months. There are many improvements to be made to the DIVE support.

Jim Thomas (70642.3611@compuserve.com), President, WinWare Corporation. Jim is a private contractor that ported Doom and SimCity to OS/2. His company needs a better name.

Lloyd Webber started the presentations by talking a little about the marketting aspects of OS/2 and OS/2 Games. OS/2 Warp makes his job easier, because it is an ideal game platform. Multimedia (MMPM/2) and OS/2 virtual memory management, (and the flat memory model) along with a new Games toolkit, (the first one IBM has ever put out, basically the DIVE toolkit) provides game developers with an excellent 32-bit API. In addition, the DOS-settings notebook has been expanded with more settings for better compatibility, and default settings for 100 popular DOS games is now included in the Migration Database for when you install OS/2 and migrate applications. (About the only thing missing is a Joystick API, although a third party developer has written one and IBM is considering purchasing it). He also mentioned some things to look forward to in the future. Several ports are in progress. Maxis is thinking about porting their entire line of Sim Games to OS/2 (including SimCity 2000). An OS/2 version of Lemmings is being planned. Other large titles will be available/announced in the first quarter of 1995 (he belabored the point that these were LARGE titles, really big). "We're gearing up a lot for stuff to be ready for the Games Conference in April."

Mike Cooper talked about the internals of DIVE. He didn't talk about the specific APIs, but he gave a good overview. He's been a GRE programmer for five years, and now leads current efforts. In addition to DIVE, one of the things he's been working on is getting the number of required functions for video/printer drivers down from about 75 to 5.

He explained that the multimedia support in OS/2 2.0 was the begining of DIVE. In order to do "Software Full Motion Video" they really needed fast access to the screen, but they wanted to maintain device independence with respect to the video card.

DIVE has two different components, the driver and the DLL. DIVE gives you a pointer to a directly addressable frame buffer that maps virtually to system address space. The DIVE DLL handles all of the annoying stuff: clipping, color conversions (all modes except 4-bit), blitting, and stretch blits. All of the actual frame buffer access is done under the hood of the DIVE DLL.

If you absolutely want it, DIVE will give you a pointer to the actual frame buffer, so that you can access it using only the driver. But then you have to do lots of extra work. You are responsible for color conversion, for keeping track of the visible regions of the window and not overwriting other presentation spaces, etc. Normally, the DLL does all that work for you. The DIVE DLL makes it "totally device independent."

There are a lot of enhancements that they want to incorporate (they are also open to suggestions... this API is for the developers, and they want to hear what the developers want). The big improvements planned for the near future include making use of offscreen VRAM, and making use of accelerating hardware. Obviously both of these things would greatly improve the performance of DIVE.

Another thing that they are considering is a "PM Game Session." Game developers and users both want to control the resolution and color depth of the screen, often with conflicting wishes. IBM is considering letting an application open a new PM session, at whatever resolution it chooses, separate from the user's desktop, providing full-screen mode and access to PM DLL's, without the overhead of the Workplace Shell or seamless Windows.

Jim Thomas ported SimCity to OS/2. The rights for the OS/2 version of SimCity were brought from Maxis by Dux Software, who produced the X-Windows version of SimCity. He was hired by Dux Software to port SimCity from X-Windows to OS/2.

He claims it took a long time to port. Half of the game code used Tcl and Tk, and the OS/2 version of Tcl did not exist when he started (and there still is no version of Tk for OS/2). So there were no helpful tools for him to use (no X porting kit, and no Tcl), and writing the tools himself would have take as long (or longer, if he did them right) than porting the code. The rest of the code, in C, was not very clean, and there was a lot of kludges to get the timing right.

Some other things were wrong with the X-Windows code. It was single threaded (hense the timing kludges) and it also used separate windows (no parent/background window) for game play. In his first test version, the OS/2 version also had separate windows, and people didn't like it. So, some words of wisdom for people porting X to PM: fit the user interface within the environment and people will know how to use it. Most people are more familiar with an application opening one huge background window, and having lots of little winodws in front of it. Don't carry over the X UI weirdnesses.

SimCity does not use DIVE. It uses GPI, and it took a lot of optimizations so it was fast enough. It also uses multiple windows, so it would have had to use multiple DIVE instances, support for which did not exist when he started the port. It was just too early in the DIVE development to do that. It works fine now as it is, so he sees no reason to go back and change it. The next version may support DIVE, because it be be multiuser, and will require more frequent updates to the screen.

He also told us some internal SimCity specific stuff. SimCity uses a 4 megabyte array for the city tile map (expect some swapping when it first starts up). There are four threads: the UI thread, the animation thread, the game update thread and the disaster thread.

Why SimCity? Lloyd explained that IBM had to find some games to show off the operating system and the available resources like MMPM/2 and flat memory, so SimCity seemed like a good choice. At the time, they were worried that the Doom port might not work very well, so they looked at strategy games. IBM is doing two things to help games developers: first, IBM made sure channels existed for companies to sell OS/2 games. IBM also offered to pay some companies, but most weren't interested in development dollars, they were interested in assistance, information, and marketing help.

DOOM! Doom was written completely in ANSI C, so it was very easy to port. In fact, it only took half as much time as the SimCity port did (thank you, ANSI C). The DOS version uses double-buffering to do the animation, so he had to change that to use non-planar mode. The OS/2 version draws directly in a 320x200 area of system memory. Then it sends that to DIVE, and DIVE takes about 20 milliseconds to blit that buffer to the screen. The DOS version gets about 35 frames per second in 320x200 VGA mode, and the OS/2 version gets about 24 frames per second in a PM window. If the window is not 320x200, then DIVE uses a stretch blitter to send the buffer to the screen. Jim demonstrated this by resizing the window to tall-and-skinny, and short-and-fat (this was on the fly!). The game kept right on playing (although Jim had a lot of trouble play it in tall-and-skinny mode, because the targets were too thin to accurately aim at).

The game is multithreaded, and the multiplayer networking code is going in, real soon now. The network interface runs off installable DLLs. The first versions that come out will use Named Pipes and NetBios. There are problems with realtime synchronization when using TCP/IP with buffered stacks (that's why the DOS version originally used SPX). OS/2 uses buffered stacks, but they're working on a fix.

Jim explained that DIVE uses some hairy self-modifying code. Doom (or any other DIVE program) gets the visible region rectangles from the GDI, and passes them to DIVE. DIVE then sets up, in memory, optimized routines to blit to those specific retangles. When you call DiveBltImage (or whatever it's called) to blit from the frame buffer in memory to the screen, it uses those routines. Each time the visible region rectangles change (like when the launch pad floats to the top, which was demonstrated) the blitter routines in memory are reoptimized. What's supposed to happen in the future is have SetupBlitter figure out the best way to blit to the screen, and if there's hardware support for blitting, it'll exploit that. DIVE with hardware support is REALLY fast (a slow machine screamed internally in a beta of hardware assistance), DIVE without it is "fast enough," but IBM plans to improve it as much as they can.

When IBM approached Id Software about porting Doom to OS/2, they said, "We're don't the time or resources to do the port, but we'll let you have the source code if you want to do it." So IBM hired Jim and gave him the source code. It was a nice deal for everyone, and IBM has mostly been dealing with the marketing.

DEMO! Wow! Doom for OS/2 on the P60 that Jim brought along with him was amazing! It's just like it's in DOS, but everything appears in a Presentation Manager window on the desktop. Someone said at the OS/2 Warp Release Party in New York City that this is much much faster than the WinDoom demo.

Jim concluded his talk by recommending the book "Tricks of the Game Programming Gurus" (ISBN 0 672 305070) (includes CD-ROM full of shareware games and sample code, $45 list). He said that it contains everthing that you need to know to write Doom, or another great games.

Copyright 1994. Permission to reproduce this article only in its entirety (including this notice) is granted, provided you send a copy of the reproduction to:

M.I.T. OS/2 Users Group, M.I.T. Room 38-591
77 Massachusetts Avenue, Cambridge, MA 02139
phone (617) 253-1938 email os2admin@mit.edu

Chris Shabsin with Kent Lundberg