Hi Chastity,
Wow! A lot of questions to answer here. I'll do my best to answer them so bare with me as I try to explain things as best as I can. As far as PyGame goes it is a cross-platform Python wrapper for the SDL API that works on Mac OS, Linux, and Windows. While I like the simplicity of PyGame and SDL it still leaves a lot to be desired. SDL only has very generic input device support for keyboards, joysticks, and mice so if you have a specific type of controller with advanced features like force feedback support you are out of luck. SDL_Mixer also has its drawbacks. A lot of features I use in DirectX such as changing the frequency/pitch of the sounds in real time isn't currently available with SDL. SDL_Mixer has a software mixer for doing virtual 3d audio, but it is not as realistic or as good as the hardware mixing you get with an API like OpenAL. As a result PyGame and SDL based games lack features that you could get with better game libraries such as DirectX, OpenAL, FMOD, etc. Which Python doesn't support to my knowledge. So I wouldn't really recommend Python if you wanted to create the next Shades of Doom or Mysteries of the Ancients. When it comes to C# .NET it certainly could be used to create a game like Q9, Mysteries of the Ancients, or Shades of Doom. In fact, Mysteries of the Ancients is currently written in C# .NET. However, it is unfortunately first and foremost a Windows based programming language. Although there is a cross-platform framework called Mono and cross-platform game API called SdlDotNet it is less than a perfect gaming solution. For one thing I've heard that Microsoft is trying to take the Mono project's developers to court over various copyright issues, and who knows how long C# .NET will continue to be supported on Mac OS and Linux. So legal issues would not make C# .NET a great solution right now for cross-platform development in my personal opinion. Even for strict Windows development I've had my fare share of problems with the language. First, Microsoft released a DirectX API for C# .NET, called Managed DirectX, which has a number of bugs and is no longer officially supported by Microsoft. Second, in 2007 Microsoft released an alternative to Managed DirectX called the XNA Framework which has some screen reader accessibility issues. The main accessibility problem is the tool they use for building soundbanks, setting up sound properties, etc isn't accessible for a totally blind user. Third, SdlDotNet has the same general limitations as PyGame. Last, there is the SlimDX API which is pretty good, but their documentation isn't as good as it could be. They often have you look things up in the official Microsoft documentation for C++ which means you need to understand C++ on some level to be able to red and fully understand the docs. There is another sound API, FMODEX, which is really good, but if you use it for commercial games it is quite expensive to license. Bottom line, C# might be a good language to know and use, but it doesn't have a lot of great choices for game programming libraries. There are a few other things about C# .NET you might want to be aware of before you consider using C# .NET for game programming. When you compile a C# .NET or VB .NET application using Visual Studio .NET it converts your source code to something called MSIL, the Microsoft Intermediate Language, which gets read and run by the .NET runtime. As a result your application can easily be hacked and cracked and reverse engineered by a skilled .NET developer. So if you ever decide to create commercial programs you will have to purchase an obfuscation tool to scramble the MSIL code so that only the framework can read it, but if someone tries to reverse engineer the game they get nothing but jumbled garbage in their favorite disassembler. From a commercial developer's perspective .NET based languages are something of a security risk. Personally, I have come to believe the one and only true option for game development is good old C++. Besides myself I know of several accessible game developers who also are now turning to C++. I know that Draconis Entertainment is developing a new game engine in C++ that runs on Mac and Windows, Philip's Q9 game was written in C++, and a couple of other game developers are now looking at C++ for their future games. I think several of our audio game developers have tried other things like visual Basic 6, C# .NET, Python, etc and found them lacking. The C++ language is beginning to take a foothold as the game language of choice for accessible game developers, and there are a number of reasons why. First, there are plenty of free C++ compilers and tools out there such as Visual C++ Express, MinGW, Cygwin, etc for example. As a result you don't really have a lot of start up costs. If you want to buy books and license certain libraries that is fine, but as a rule you can get decent tools and libraries for free. Second, C++ is the most widely documented language around and is what most documentation, libraries, and tools are designed for. You might as well say C++ is the programming standard for most professionals. Third, instead of going through a special runtime framework like .NET you can access most libraries directly taking out the middleman. This is often nice as languages like C# .NET doesn't have access to everything directly as it usually has to go through a middleman like .NET to access the lower level libraries and APIs. As a result just about everything you can think of is natively available to a C++ developer without having to find some piece of middleman software to bridge the gap. A case in point is DirectX. In C# .NET you need something like SlimDX or Managed DirectX where with standard C++ you can just include the libraries and headers in your project and start programming using it. No middleman to connect your .NET app to the API you want to use. This is without a doubt a huge advantage. There are lots of reasons why I think C++ is the right choice, but it comes at a bit of a price. C++ isn't as simple and easy as Python or Visual Basic so takes longer to be a skilled programmer in it. It has something of a steeper learning curve which is why many new programmers want to stay clear of it. However, I believe the advantages of learning it are worth the time and energy spent on learning it. Now, you asked about Sapi support. It really isn't too hard to learn and use Sapi support in a game. The Sapi 5.x SDK comes as part of the newer Windows Platform SDK that ships with Visual C++ Express and therefore I would recommend using Visual C++ Express to learn programming with if you want to use Sapi. The simplest hello world program using Sapi 5 would look like the example below. you would add sapi.lib to your Visual C++ project and write a simple "Hello World" program like this one.

// Header includes
#include <stdafx.h>
#include <sapi.h>

// Name: main(int, char).
// Description: Entry point for the application.
int main(int argc, char* argv[])

// Create apointer for the Sapi voice
ISpVoice * pVoice = NULL;

// Initialize com support
if (FAILED(::CoInitialize(NULL)))
return FALSE;

// Initialize Sapi 5 support
HRESULT hr = CoCreateInstance(CLSID_SpVoice, NULL, CLSCTX_ALL, IID_ISpVoice, (void

// Speak "Hello world!"
if( SUCCEEDED( hr ) )
hr = pVoice->Speak(L"Hello world!", 0, NULL);
pVoice = NULL;

// Uninitialize com support

// Exit the program
return TRUE;

There you have it your first "Hello World" program written in C++ using Sapi 5 support. While it might look pretty intimidating to a new programmer it is actually pretty simple once you get use to using C++. It isn't that bad at all.


Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.

Reply via email to