Multiplatform Game Programming in OS/2 - Part 1
| Part 1 | Part 2 | Part 3 |
|---|
Summary: Start writing games in OS/2 that are easy to port to multiple operating systems. In this introduction, Robert discusses some of the technologies available for OS/2 that would assist a game developer and how each relates to other popular platforms. Also: Gaming News in the OS/2 world.
This article is the first in a series covering cross platform game development using OS/2 as your development base. We are going to focus on programming and platform issues, but will delve into gaming design issues where they seem appropriate. The ultimate goal of course, is to produce commercially viable gaming software for OS/2. These articles are mainly aimed at the experienced programmer. I expect that beginners will be able to get a lot out of them as well, but will have to do a bit more homework to keep up. I'll do my best to provide references to detailed explanations of topics where I don't have room to cover them here.
Having done some informal analysis of the computer gaming industry, I've come to the conclusion that platform independence is the only way to go. I believe that if you design right from the start to support multiple platforms, then it shouldn't be prohibitively expensive to develop software for more than one platform. There are a number of companies who apparently agree with me. id software's games have been ported to a number of platforms (including OS/2,) Stardock has published games for both Windows and OS/2, and Polyex covers even more platforms, up to and including BeOS.
I'm not an expert on every platform around but I will be planning with the following platforms in mind: OS/2 Warp, BeOS, Linux, Windows 95, Windows NT 4.0, and Mac. Of those, I have the most expertise in OS/2 and Windows and I have dabbled enough in BeOS to appreciate it. I'm hoping Linux and Mac experts will offer me pointers should I go astray.
If it isn't immediately obvious why you would want to develop commercial games on OS/2 rather than Windows, which is where most gaming effort is being placed today, the simple reason is that OS/2 is a lot nicer environment to work in and can still give you all the tools you need to get the job done. I develop by running two machines connected with a coaxial Ethernet. One is my development system running OS/2, all my compilers, and various tools. The second system lets me test programs, crash the machine, and reboot without having to restart my development tools all the time. And because there is little other than operating systems installed on the test machine, there is little disincentive to nuke one OS and replace it with another when you run out of bootable partitions.
I thought I would start this series off with an overview of gaming applicable technologies available in OS/2 and look at how relevant they are to current state-of-the-art gaming.
Contents
OpenGL
OpenGL is available for OS/2 Warp 3 and above and is probably the most under appreciated portion of OS/2. OpenGL is a cross platform 3D graphics library, first developed by Silicon Graphics although but now managed by the OpenGL Architecture Review Board (ARB) which is a panel of representatives from many familiar companies. It is designed to be accelerated with hardware, and is available on all the platforms I mentioned above and more. It supports texture and bump mapping, lighting, fog, motion blur, depth of field cues and a ton of other special effects. Even if you aren't familiar with OpenGL, there's a good chance you've used it playing Quake II. You can find out more about it at (www.opengl.org).
OpenGL 1.0 is included in Warp 4, but you can also obtain OpenGL 1.0 with Pentium Pro optimizations and OpenGL 1.1. On OS/2, OpenGL renders scenes with software, which means the frame rates aren't great, especially if you try to use more advanced effects, but there are two key features it possesses that are very relevant to 3D game developers. First of all, all OpenGL implementations must implement all OpenGL functionality, this means that your OpenGL code developed on OS/2 will work, pretty much unchanged, on all those other platforms, including those with hardware acceleration like Windows and soon BeOS. The second benefit is that it is a complete polygon renderer with nearly every goodie you could want, which makes it great for prototyping effects before you go to the work of adding them to your hyper-optimized cross-platform software renderer.
You're probably wondering why I'm talking at all about software rendering in these heady days of games defined by flashy special effects powered by increasingly muscular hardware graphics accelerators. If you have played Descent Freespace without these hardware accelerators, you know.
Today's increasingly muscular CPU's have the power to produce spectacular graphics effects even without hardware acceleration. Add to this an interesting article from the September 1997 Game Developer magazine which discusses the possibilities of combining the spectacular pixel fill rates of hardware with the coolest new software graphics algorithms, and it is hard to ignore software rendering. This isn't to say that I don't want to see universal hardware for 3D rendering under every operating system, I'm just saying that until that happens, you can still do a lot with a Pentium II.
Hardware acceleration for OpenGL on OS/2 doesn't really exist right now. IBM has developed it, including drivers for the Omnicomp 3Demon SX88 adapter, but it seems you need a $25,000 OpenGL source license from silicon graphics to get access to it. And no graphics card vendors are currently making drivers for OpenGL on OS/2. Scitech has stated unofficially that they will be bringing hardware accelerated OpenGL to Windows, Linux and OS/2 pretty much simultaneously, but with them focusing on some great new 2D drivers for OS/2, that seems to be quite a ways off yet.
The files you need from IBM's FTP site to get programming with OpenGL are: OGL9635.ZIP (OpenGL 1.0 with fixes) and OGLGOLD.ZIP, AUX.ZIP and GLUT.ZIP which implement OpenGL 1.1.
If you are going to build OpenGL applications, you should use the libraries (.LIB) for OpenGL 1.1, and use the 1.0 .DLL's which are quite a bit quicker. Only use the 1.1 .DLL's if you need 1.1's advanced features. One word of caution: if you have OpenGL apps compiled for OpenGL 1.0, they will not work with the 1.1 .DLL's without a recompile. You should also look at The OS/2 OpenGL Developers Mailing List Homepage which has a great deal of information on OpenGL for OS/2, plus Perry Newhook's OpenGL programming series at EDM/2.
DIVE
Direct Interface Video Extensions (DIVE) provides direct access to PM's video buffer and is the chief means of bringing high-speed graphics to the OS/2 desktop. It is comparable to DirectDraw in Windows and BDirectWindow in BeOS. DIVE provides several levels of access to video memory from low level direct memory access up to the high level DIVE blitter which can copy your image data to the screen, taking care of managing overlapping windows and converting your image data to the data format used by the display.
DIVE's high-level blitter has garnered some well-deserved criticism for its lack of dirty-rectangle support (it does include dirty-scanline support, but that isn't so useful,) but such functionality is available if you are willing to write the small extra amount of code needed to use DIVE's direct video buffer access features. In fact, I have seen significant performance improvements from using direct buffer access over the DIVE blitter in some cases.
DIVE performance seems to depend highly on your video card driver. I have been beta testing Scitech's new GRADD based video drivers, and DIVE performance with them is exceptional.
Other terms you may have heard in combination with DIVE are EnDive which adds hardware acceleration for blitting and stretching, and Full-screen DIVE which was to allow switching a windowed DIVE PM program to a full screen for gaming. Since EnDive requires help from your video drivers, it is implemented on some systems, and causes problems on others. On one system here, EnDive nearly doubles the frame rate of my DIVE examples, so it is worthwhile looking into. Full-screen DIVE was an idea that withered on the vine. The current implementation in GAMESRVR works for 320x200 with 256 colours and that's about it. It is supposed to allow you to set higher resolution modes, but that API just doesn't work. Unfortunately IBM lost the will to complete it and for today's games isn't worth looking at.
Full-screen VIO & Mouse
OS/2 full-screen sessions support high resolution graphics with as many colours as your video card supports. If you want your game to run full-screen and are willing to do your 3D rendering yourself (as no OpenGL is available here), this is the way to go since it allows you to choose your resolution and colour depth on the fly, unlike the PM desktop. The only word of caution is although video driver support for higher resolutions is generally pretty good, you might find yourself limited to plain VGA's 320x200 with 256 colours on some video adapters.
Also, IBM revised the documentation for VIO at some point, dropping documentation of several important functions. If you are looking for documentation, look for PRCP.INF, not the documentation in the Control Program Guide in the OS/2 toolkit.
Mouse support in full-screen sessions works in both text and graphics modes, but there are a few tricks to getting it to work. I'll be covering this in more detail in a future article.
Even though these interfaces are both 16-bit, they still offer very good performance. Don't shy away from giving them a try. Their 16-bitness does, however, cause some problems on compilers that include older versions of the OS/2 toolkit. For some reason these interfaces were plagued with pointers not being declared as 16-bit in their definitions. This made for a lot of tough debugging on compilers such as Borland C++ 1.01. If you run into trouble with calls to these functions crashing, check out their declarations in BSESUB.H in your TOOLKIT\H directory very carefully, or get the Warp 4 toolkit.
DART
OS/2's DART libraries provide easy to use, low-latency access to sound output on Warp systems much like Be's Media Kit and Windows DirectSound do. DART is a fairly simple interface that allows you to send buffers of digitized sound directly to the sound card without having to wait for MMPM to play the sounds for you. MMPM can take up to a second to start playing a sound which means that when you pull the trigger you have to wait for the bang. DART allows you to reduce that delay to an unnoticeable hundred-or-so milliseconds.
DART also allows you to reliably feed sound continuously to the sound card, something very tricky with MMPM. Also, DART works in both full-screen and PM windowed sessions, making it the right choice for gaming audio in OS/2.
The one obvious thing missing from DART is a facility for mixing multiple audio tracks. On Windows, BeOS and Linux there are facilities for mixing audio easily. In OS/2, you are going to have to look at one of the available toolkits which we'll examine next month, or roll your own - which isn't too hard either.
DART also lacks support for advanced audio features like hardware mixing, 3D positional audio and Dolby surround sound. Hardware mixing is nice, but hardly a necessity since mixing audio isn't very CPU intensive. I'll also address Dolby surround next month.
That only leaves 3D positional audio which I suspect will remain a Windows-only gaming feature until CPU's get a whole lot faster.
Joystick Driver
The OS/2 joystick driver GAMEDD.SYS supports reading one or two regular analogue joysticks on OS/2. If you are looking for gamepads, force feedback and digital sticks, at least for the moment, you're out of luck. You can get the joystick driver at IBM's device driver site, just look under any of the joystick devices listed there.
SMP, Multitasking, Multithreading, Synchronization
You may have noticed that all the operating systems I mentioned above are multithreaded, multitasking, memory protected operating systems (more or less). Threading is just too nice a feature to do without when you are developing a game. With continuing rumours of an Aurora client release I keep hoping that SMP will gain broader use, since it offers wonderful potential for better frame rates in games. Even without SMP, threading lets you easily compartmentalize portions of your game: communications, rendering, input, video, and audio streaming. Being easily able to separate all these functions makes them a lot easier to design, debug and port to other operating systems. OS/2 offers a wide variety of handy synchronization techniques. Fortunately they are all based on simple semaphores, so they are portable to one degree or another to other operating systems.
TCP/IP and UDP
The internet and its communication protocols have become the de-facto standard for multiplayer games, especially with cable modems and DSL finally making the scene. OS/2 contains a complete implementation of the BSD sockets specification, which is available on just about any OS you can name. These supply TCP for guaranteed delivery as well as UDP for low-latency (although less reliable) packet delivery. If you are just looking to port to Windows, OS/2 also implements Winsock.
Serial Ports
Any BBS operator will tell you that OS/2 is a dream for servicing a lot of serial ports. And even with internet gaming, I'm still a frequent null-modem game player. Unfortunately for developers, there don't seem to be any real cross-platform standards in this area so you'll likely be writing serial drivers for every platform you port to. Fortunately, the serial port is not a complicated device so platform independence isn't very tough.
Real-Time MIDI
OS/2's Real-Time MIDI (RTMIDI) subsystem allows you to play MIDI music files if you have a MIDI driver for your sound card. This system gives you great control over playback and if you have the right sound card, can give you very high quality music output in your game. If you are interested in branching audio that matches the soundtrack to the tempo of the gameplay, this is the place to start.
TIMER0.SYS
The high resolution timer driver TIMER0.SYS was added to support the real-time MIDI system, but can also be used for down-to-the-millisecond timing. If you take the time to develop a device driver it is capable of providing interrupts to your game as often as every millisecond. Applications can get the address of a free-running millisecond timer for timing their activities. The only caveat is that DOS applications will not have timer services while a device driver is installed. Documentation can be a little tough to find, but it is in the MMPM device driver reference available at IBM's Developer Connection Device Driver Kit.
MMPM/2
Multimedia Presentation Manager/2 (MMPM) is the heart of sound and video processing on OS/2. I have already talked about many of the technologies that fall under the MMPM banner, but there are still a few more of interest. MMPM does a lot of different things, far more than I could possibly cover here, so I highly recommend browsing the Multimedia Application Programming Guide, part of the OS/2 Warp toolkit for a lot more information.
MMPM provides programmers with Media Control Interface (MCI), an extremely easy to use string based interface for controlling any multimedia device in the system. You can use it to play sound and video files and it allows extensive control and information on the playback process. From a cross-platform point of view, MCI is also supported in Windows.
If you want to play CD audio as background music in your game, MCI is the easy way to do it. The great thing about this is that the sound quality is great, it requires very little CPU power, and it doesn't interfere with the playback of sound effects through MMPM or DART.
If you want digital video in your game, video playback in OS/2 is controlled through MMPM. It supports a number of video formats (codecs) including Ultimotion, Indeo 2.1, Indeo 3.1, Indeo 3.2, DIB, FLI, FLC, and MPEG-1. If you are looking for wider video support, there are after-market codecs for Quicktime, Microsoft's RLE and others. The only problem with MMPM's video playback is that it only works in PM, so if you are running a full-screen game you're going to have to jump through some hoops to add video.
Ultimotion is IBM's video compression system. What makes it worth mentioning here is that the complete specification for it is available online (UMSPEC.ZIP), and there is even source code for an Ultimotion playback system available in a UNIX program called XAnim.
This is one video format that you could implement for cross-platform video that would even work in an OS/2 full-screen session. Ultimotion produces very small files, can be played back with software, has decent video quality, especially for live-action video, and is free.
If you are willing to sacrifice cross-platform support, MMPM's Multimedia I/O File Services make it easy to read and write a multitude of file formats for audio, video, and bitmaps. Just a few of the supported formats are WAV, FLI, AVI, BMP, JPEG, PCX, and TGA. If you are writing a cross-platform game you are better off to write your own PCX file reader and be done with it.
MMPM also offers MIDI music playback support, similar to what you will find in RTMIDI but without as much control and with higher latency. Where RTMIDI requires driver support to work, MMPM's MIDI seems to work with pretty much any sound card.
The now defunct Entertainment Programming Developer's Kit
Back when Warp 3 was spreading like wildfire, IBM decided to try to get OS/2 into the forefront of gaming. If you were following OS/2 at that time, there were whitepapers and reports on how OS/2 was the ultimate gaming platform. They read pretty well and IBM even developed the Entertainment Programming Developer's kit which contained a number of new technologies and libraries aimed at supporting gaming on OS/2. The kit included OS/2 Warp Net, Input, Video, and 3D.
Warp Net was designed to allow multiplayer gaming over the internet and LANs. The API was designed to support many protocols, but the first (and last) implementation only supported TCP/IP. It does provide basic multiplayer support suitable for multiplayer card games, but if you are planning to do a real-time action game with more than a couple players, or want to play on your LAN, you're probably going to have to implement your networking yourself.
Warp Input was already discussed above, it's the OS/2 joystick device driver. Warp Video is DIVE, EnDive and GAMESRVR also discussed above. Warp 3D was the BRender™ library from Argonaut. Unfortunately this toolkit required a non-free license from Argonaut and other than a few sample applications, it was never used for much. That said, BRender is still very quick and produces some nice graphics.
While there were definitely some worthwhile things gained from the OS/2 Entertainment programming kit, IBM quickly dropped support for it, removing the web site documenting gaming efforts on OS/2, and the gaming toolkit was never released as anything other than a beta.
The game programming book of the month is "Black Art of 3D Game Programming" by Andre Lamothe (ISBN 1-57169-004-2 Waite Group Press). This book is a veritable encyclopedia of game programming techniques. I have yet to find a more complete overview of 3D graphics, multiplayer techniques, AI, sound, voxel graphics, optimization and more. Even though the book focuses on DOS programming, it does a great job of taking you through every aspect of game programming and is well worth having on your shelf.
Next time we'll talk a bit about choosing your cross-platform tools and have a look at some of the more interesting graphics and sound libraries available for OS/2. I hope I've given you an appreciation for some of the useful gaming technologies included in OS/2 and that all of you will take this as an opportunity to expand OS/2 as a gaming platform. Please feel free to drop me an e-mail if I miss anything important.
Gaming News
Stardock has announced that their new game Monopolization, the sequel to Entrepreneur, will not be developed for OS/2, citing poor sales of previous gaming products and technical difficulties with DIVE as the reasons. They have stated that they will continue to consider publishing OS/2 gaming titles developed by others.
Stellar Frontier's developers continue to release free-to-try versions of their pre-release software. Despite anything it says on the download pages at Stardock, you can give Stellar Frontier a try yourself just by downloading it.
The source code for the GameCode library which offers Windows and Mac support for a wide variety of game developer needs including user interface, sound, palette management and more has been released. If you're looking for a porting project, this one is worth a try.
Westwood's Command & Conquer Red Alert works great in OS/2 but if you love the game, you have to play the add-on packs Counterstrike and The Aftermath. The add-on packs offer several new missions each, include many multiplayer maps, and improve the game's features in a number of areas. Unfortunately the add-ons don't work in an OS/2 DOS full-screen session because they can't find the CD-ROM drive. Talking to Westwood's support got the standard response "we don't support OS/2" so I decided to try and fix things myself. If you are ready to play, have a look at my web site and download the fix.
Reader feedback
"Programming games on OS/2 is as silly frankly as programming games on any OS. I've been a game programmer from way back in the Atari and Amiga days. I used to write assembler for the hardware in the 8-bits, and 16-bit for games. Basically running a game and beating up the OS with DirectHEX and DIVE really defeats the purpose of what you are doing." - TheDoctor
