We finished up the spit-n-polish work tonight and shipped the second "beta" of our 3D game engine for Python!
Included is support for Microsoft Windows (with nice bdist graphical installer), keyboard input and an early draft of the controller-action system, text rendering thanks to Cairo, support for Joints, and other enhancements and fixes too numerous to list.
While over a dozen developers contributed to this release I'd like to especially thank Kirk McDonald for porting the engine to Windows API, Derek Rhodes for getting the Cairo support in, Eric Stein for his work from Summer of Code and since, and Piet Delport who provided countless hours of help to all of us with Pyrex-related issues.
We're far from done so please download, enjoy, give feedback, and if so inspired help us reach 1.0!
Subscribe to:
Post Comments (Atom)
2 comments:
I have a few quick questions:
Unit Tests: I noticed your project does not have any unit tests. I know many things on the graphics side are hard to test but you can still do things like the physics engine and lots of the support code. I just find it unusual to find a Python project that lacks unit testing.
Pyrex: Why the use of Pyrex instead of ctypes? I understand the need to use C/ libraries to leverage existing functionality. Was pyrex chosen because it was easier to wrap with than ctypes? The lack of compilation is what makes things like pyglet so sexy.
We recently moved our examples from tests/ to examples/ to begin writing unit testing. Unit testing is a great thing to do, and needs to be done, but getting core functionality has been a higher priority than testing said functionality :-)
As far as ctypes, PySoy is a lot more than just bindings to C libraries. There's a good deal of unique code written in C, and we're by no means a native interface to ODE/etc. Use PyOpenGL, PyODE, PyCairo, etc for low-level access to those C libraries.
We've looked at alternatives to Pyrex, such as Cython, Swig, etc. While there's some attractive features their shortcomings combined with the amount of work it'd require to port our codebase is greater than any gains we'd get by doing so.
Pyrex is pretty flexible, and given our current design, that's essential.
Post a Comment