We use Device Independent Bitmaps (DIBs) to store and manipulate all of our graphics objects during the game. DIBs are independent from the specific hardware the application runs on and support various properties.

All of our bitmaps are inserted into the application resource as binaries during compilation. All of the bitmaps used in this game are uncompressed (as opposed to RLE4 or RLE8 bitmaps), 8-bit per pixel palette-base. All of the images share a single unified palette.

To handle the DIBs, there are various Win32 API functions and structures. MFC does not supply any native C++ support for DIBs.

We came across 2 different DIB classes (both of them published in CodeGuru and both of them are named CDIB):

CDIB by El Barto - http://www.luc.ac.be/~ef00/ebgfx Supports only TrueColor DIBs (32 bits per-pixel: RGBA) Does not support any palette - cannot be used in 256-colors palette-based resolutions Gives fast direct access to the bitmap itself Supplies many graphical effects functions - most of them are not used in this application Supports transparent pasting of one DIB rectangle into another - uses a color key for the transparent color. Very useful for our game

CDIB by Jorge Lodos Encapsulates the DibLook sample given with Visual C++ / MFC Supports various color depths and compression techniques Reads / Write DIB (BMP) files Supports palette and color manipulation Does not support any access to the pixels themselves

Since none of these libraries supplied exactly what we needed, we took the best from both and combined them into our own CDIB class with the following features:

	Encapsulates the DibLook sample given with Visual C++ / MFC
	Supports various color depths and compression techniques
	Reads / Write DIB (BMP) files
	Read DIB from resource
	Supports palette and color manipulation
	Optimized for 8-bit pixel manipulation
	Gives fast direct access to the bitmap itself (8-bit DIBs only)
	Supports transparent pasting of one DIB rectangle into another - uses a color key (palette index) for the transparent color. Very useful for our game

To learn more about DIBs, refer to the MSDN-Online site under the DIB section.

For displaying our main game map during the game play we needed a fast engine. The default technique most programmers employ to display bitmaps (or DIBs) is the famous BitBlt function. BitBlt is very powerful, however, since it's part of the GDI, it must use the GDI objects (palettes, regions, clipping etc.). This power of BitBlt is very handy but it effects its performance considerably.

Another technique, created especially for game-oriented applications is the DirectDraw library. This library, being part of DirectX, supports optimized access to the graphics hardware and promises top performance. The library is best suited to deal with full screen applications. Since ours is a windowed (dialog-based) application, we found DirectDraw to be an overkill for our needs.

Finally, we settled somewhere in between the GDI's BitBlt and DirectDraw.
We stumbled upon the DrawDIB libraries.
This library is not new - it's been around since the Windows 3.1 days (uses for VFW - Video for Windows). It has a low overhead and it is especially designed for fast DIB drawing to the screen, without using the GDI (faster).

Major features of DrawDIB

	Supports many formats of DIBs
	Has build-in palette support
	Can display sub-rectangles of a DIB anywhere on the screen (good for optimizations)
	Tailored especially to work with DIBs
	Small image footprint
	We already has a class encapsulating its API - CDrawDIB by El Barto - http://www.luc.ac.be/~ef00/ebgfx

To support sound in our game we had two options. We could use the old and faithful multimedia API (or MCI) which plays WAV or MIDI files from resource or disk.

We chose to use the more advanced (and a bit more complex to use) interface of DirectSound (introduced in DirectX). We used the simplest interface of DirectSound (IDirectSound) that requires DirectX3 or above.

DirectSound features:

	Supports multiple sound formats (we used 8-bit 8000Hz mono - for best performance).
	Supports automatic mixing of several sound effects in real-time.

We load all of the sound samples in advance (during initialization) into memory buffers. Each sound effect has a unique buffer allocated for it. All the sound effects are stored (like other binary data) in the game's executable resource.

To learn more about the DirectSound API, refer to the DirectX site under the DirectSound section.

To transfer packets between computers we had to pick between many options. The simplest one with the best performance would be the WinSock API. But this option limits us to LAN / Internet connections only and requires a lot of coding effort.

We chose what we believe to be the best solution for multi-player games communications. DirectPlay (from the DirectX library) was designed especially to support multi-player applications.

We used the simplest interface of DirectPlay (IDirectPlay2) that requires DirectX3 or above.

Major features of DirectPlay are:

	Simple API to create and manage sessions and players.
	Supports server-client architecture internally.
	Supports various transport layers (LAN, Internet, Modem to modem, Direct cable connection etc.) transparently.
	Supports automatic keep-alive messages.
	Implements connection dialogs for various transport layers.