Goals of the Pygext Rewrite

The rewrite of pygext will change enough things, that I thought renaming might be appropriate to lessen confusion (especially since the original Python-pygext will stay around and updated for a good while still). The new working title for the framework is Opioid2D (or the Opioid2D Game Engine), abbreviated O2D.

1. Speed. As I wrote in my last post, performance is one of the most essential things in a game framework. The general guideline in O2D is that all the code that gets called at every screen update should be on the C++ side. Using C++ also allows the rendering pipeline to contain more logic without adding overhead, so O2D will have better texture packing, and sprites will be rendered in batches using OpenGL arrays.
   
2. Maintainability. On the other hand, everything that is NOT speed critical should be written in Python instead of C++, for easier debugging, fixing and extending. The O2D implementation will have three tiers: The core written in C++, a SWIG wrapper exposing the core API to Python and a very-high-level Python API that calls the wrapper.
   
3. Minimalistic High Level API. The pygext API was huge and cluttered with things you rarely need. The O2D high level API will concentrate on the bare essentials, which leads to the next point.
4. Better Documentation. When I started developing pygext, it was supposed to be for my own use only. While it's slowly starting to have an adequate level of documents, the messy and large API makes writing documentation a pain. The O2D API is being documented constantly as I write it, and being much leaner, having good documentation coverage takes a lot less work.
5. Smaller Footprint. O2D aims to have all calls to SDL and OpenGL inside the C++ core, so I can drop all dependencies to Pygame, PyOpenGL and Numeric. This is done mainly to reduce the size of standalone executable distributions of games made with O2D.