At first look the Python bindings for DirectX, DirectPython were looking pretty promising. The API set is small, the included docs seem verbose enough to actually be useful, and the included samples illustrated using vertex and index hardware buffers directly which is one of the things I didn’t feel like grepping through the OGRE code to figure out how to do. In running the samples I did observe several on them disappear when I tried the few key commands they supported, but that was the only immediate red flag.
I figured I’d have a look at the Python bindings for OpenGL, PyOpenGL quick to see how they compared. First off there weren’t any samples included with just the basic download, but that’s now big deal. After downloading the samples I found that none of the would run without going and downloading an additional DLL and some additional Python libraries. Still not a big deal and once they were running I didn’t observe any of them disappearing before I closed them. I did run into a few that were using an fairly old library for which there is no pre-built Win32 binary. Didn’t feel like dealing with that, but the code is still useful.
One piece of data that I discovered while working with PyOpenGL and OpenGL was that modern graphics cards now support geometry instancing. As this seems highly likely to beneficial to my games, I decided that whatever 3D rendering library I was going to write code against first needed to support instancing. Although DirectX 9.0c does support instancing DirectPython does not (well it’s the ability to call through the COM methods directly, but there are other ways to that as well, and I believe it would more productive to just write the code in C++ then in Python in that case), so that’s out (I may need to write something against DirectX in C++ in the future and then make Python bindings for that, but that’s basically an optimization that can wait until later). I also checked OGRE and it does not have support for instancing, so that is now definitively out as well. I ran across another open source rendering engine called Irrlicht that all has Python bindings and investigated it enough to determine that is also does not support instancing. Next I checked the PyOpenGL bindings for OpenGL extensions and found that the instancing extension (EXT_draw_instanced) does have bindings.
At present I’m also more inclined to go with OpenGL then DirectX from the standpoint of future proofing. All versions of DirectX up through 9.0c have been available for developers to freely redistribute with their games; however, DX10+ is currently only available on Vista and Microsoft has indicated that it has no intention of making it available separately from Vista. Unless Microsoft changes its tune in the future, this means XP users–that is to say most users–are running on an OS for which there will be no version of DirectX beyond 9.0c made available to take advantage of the new capabilities of graphics cards. On the other hand graphics cards manufactures (NVidia in particular seems to be really committed to its OpenGL drivers) make available their newest hardware capabilities via OpenGL extensions. These hardware specific extensions frequently become official ARB OpenGL extensions, and the ARB extensions becomes frequently become part of the next rev of the OpenGL specification. While dealing with hardware specific extensions does suck on a number of levels, its nice to at least have the option to use more advanced features, vs. being forever frozen to what DirectX 9.0c supports.
So at this point if PyOpenGL doesn’t work, screw Python I’m going home to C++ at least the rendering subsystem. Since wxWidgets is written in C++ and I’m just calling through to it via wxPython, the language switch won’t affect any of my current API or library choices.