Gothic is driven from an AMD K6 300Mhz PC running Windows 98. The game logic and core skeleton is written in C++ using MFC and Microsoft Visual C++ 6.0. Windows provides many multimedia functions for video playback, audio, etc. that I am intimately familiar with and it was easiest for me to leverage that existing functionality. Windows also provides my machine with networking, remote management, configuration files, etc that make development and maintenance easier . For example, updating animations or audio assets are simple network file copies and I can analyze debug output of a game in progress through the network.
Couldn't you use Linux / BeOS / Amiga?
Probably. I know there are real time versions of Linux available which might address some of the issues I've gotten around other ways. There may be some Linux libraries and packages which do much of the same things I can do with Windows. While I have no great love for Windows, I am already very familiar with Windows programming, the development environment, debugging tools, libraries, etc. This project has taken up a lot of time already, and if I had to spend time learning a new environment and toolset, it would never get done. The software is only one piece of this beast.
Real Time Issues:
Windows 98 gives uneven real-time response. Often you can have tight control and prompt, on time responses. However, Windows does have a habit of occasional long delays, sometimes as long as 250ms or so with 50ms delays being common. This is usually unnoticeable and acceptable for user interface or game logic functions.
However, when attempting to do tight timing of a solenoid coil pulse, an extra 50ms delay in response can cause a transistor to have too much current flow and be destroyed. There are many ways to solve this, such as hardware pulse generators or a Windows real time kernel modification. For me, it was easiest and most flexible to use a small slave PC running DOS to control real-time I/O.
This is an old crappy Epson laptop I had lying around that now serves as a real-time PC I./O interface. The game software makes requests to the real-time PC via an RS232 serial port for a given coil, lamp, relay, etc. to be pulsed, turned on, turn off, flash, etc. for a given period of time. The real-time PC runs in a small, tight loop of C code, counting milliseconds and controlling the I/O interface board. It has a resolution of about 1ms for event processing. The real-time PC also watches its own performance and reports any events that were executed late. Even during the busiest of periods, this old 10Mhz 8086 machine is never late more than 2ms -- well within my acceptable range. Ironic how a ten-year-old machine running a dead OS is able to better keep real time performance than the newest, hottest PCs...(of course, it's doing NOTHING else...)
At some point in the future, when I feel the low level software development is mostly complete, I will replace the laptop with a small microcontroller.
The game display in the backglass is a grayscale 640x480 VGA monitor tinted red. Since the system is capable of displaying any high resolution grayscale image, we can design the score and animations to be in any visual style of our choosing, including photorealistic or video (although we donšt like those particular styles used in a pinball). The display is driven by DirectX and Direct Show. This high resolution display also allows for detailed debugging information.
Stereo sound driven by DirectSound. Multichannel CD quality digital audio with MIDI support.
The game will keep track of an individual player's preferences, playing time, accomplishments and unique high scores. This information will also be available as a web page, updated in real time directly from the pinball machine.