Prior to getting sick I had been making solid progress on planning and design for the games I want develop as well as some core technology that will be useful more serious endeavors as well. Once I started feeling better I figured just start doing some coding to get more familiar with Python, which I haven’t done anything with since March ’07, and the libraries available for it. I got off to a good start with simple but extensible application framework. Then I figured I needed some a UI a little fancier then text on the console. I had previously done some poking around to find out what 3D graphics libraries where available for Python. Of those I found I had decided to with Python-OGRE, which are the Python bindings for OGRE as well as several GUI libraries and physics libraries. OGRE is a 3D graphics rendering engine that works on top of either OpenGL or DirectX which are two major 3D rendering APIs, so I figured it would be nice take advantage of that so my games would support both OpenGL and DirectX without me needing to write code to both APIs.
So first things first I’ve got two monitors so I want to be able to do full screen rendering to both monitors at the same time (and more for folks with more monitors). After a screwing around without for a while I confirmed that out OGRE doesn’t support that yet. Okay, so maybe one monitor gets a full screen window and the other gets regular window that is maximized. Nope, when the focus is switched from the full screen window to the regular window the full screen window minimizes itself. Turns out two maximized regular windows was the best I could do with OGRE at present, but that was okay for my initial plans and I found comments by the OGRE devs that the multi-monintor full screen support was being worked on.
So now that I’ve got two windows (well three actually; I’ve always found it better test with a minimum of three things if you need to support an arbitrary number of things) up capable of rendering 3D scenes, I figure it’s time for a GUI in those windows. Even if I decided to be lame and go purely keyboard driven I’d still need to be able to put up to some text on the screen and if I’m going to both with that I figure may as well have some mouse support as well, since this is common in modern games so not having it would be really lame. I looked into the 4 GUI libraries that Python-OGRE has bindings for and was able to rule out 2 in fairly short order. The next two I spent some time playing around with. One was still only of alpha quality and it just wasn’t ready for use yet. The other was fairly mature and stable after more screwing around I was able to confirm it only supported putting a GUI into 1 3D viewport (a window can have multiple viewports). More importantly the stock GUI widgets it offered didn’t supply everything I’d need for a GUI for doing unit/character design, so no only would it limit me to a single viewport (and thus single window) I’d still have go write some complex GUI widgets.
So I said screw it. I’ll use a regular a regular Windows GUI and simply host some 3D rendering windows in the regular GUI. I new there was a mature library called wxWidgets that was a cross platform (it works on Max and *nix as well as Windows) GUI/windowing library that had Python bindings in the form of wxPython.
So I got that going without much difficulty and figured it was time to get something 3D rendering in my 3D window. I’m planning to go with programmatically generated visuals as I’m not skilled as a texture artist or a 3D modeler so I wanted to get a sphere up on the screen. Before trying to generate a mesh for a geodesic sphere I wanted to display a particle at each vertex on the geodesic sphere to make sure I had the algorithm correct. A particle is a (usually) small square that is perpendicular to the direction of the camera (i.e. it always faces the camera however the camera moves) and I knew OGRE had a particle system so I tried to determine how to get one particle onto the screen and I really got a dose of how static data driven OGRE is. OGRE can load a number of different kinds of files and turn them into visuals on the screen with just a little code from you to specify where this thing will be or what animation it is currently running through. That’s great if you have a bunch of artists producing loads of content; however, if your content is produced dynamically on the fly this isn’t useful. That would be a problem in and of itself, except that the OGRE tutorials all use static content in files, and the OGRE API docs are pretty light. I ended having to download the OGRE source code in order to look through it to try to figure out the steps for just getting a damn particle on the screen. I got one up eventually but I ran into a problem where the Python bindings had an error in them so one particular method wasn’t callable. I found another method I could call that would in turn call that one; however, calling it at that time caused other problems.
On top of that while I was looking through the particle system render code I had noticed that it was fairly inefficient. Particles are supposed to be really light weight. OGRE is very and extensible so I could write my own my particle system, but I had already determined I would need to write my own scene manager as well. Since I wouldn’t be taking advantage of OGRE’s static data driven aspects (including all of the tools for creating this data), so now I have began to question if OGRE was really what I should be using. I could just use it’s lower level classes that abstract over OpenGL and DirectX but figuring out how to do that is going to mean a lot of time looking at the code so I’d probably need to get setup to build OGRE and Python-OGRE so I’d have binaries I could debug to aid in figuring out how the code all fits together.
Having support for both OpenGL and DirectX isn’t critical. Numerous games only support one or the other. Another option is to just write to OpenGL or DirectX directly. There are Python bindings for both. There are also a number of Python libraries or libraries with Python bindings that work on top of PyOpenGL. I’ve just downloaded a number of these libraries so I can spend some time evaluating them.
Josh Heitzman on Codecrafting 