[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Where to next?



On Sunday, Jul 13, 2003, at 17:00 America/New_York, Pete Shinners wrote:

first off would be a break from SDL. currently pygame isn't much more than a cleaner version of SDL. i don't think much more can be done for pygame unless it becomes its own api. SDL would be pushed back as just one of the available backends for pygame. The other obvious backend would be opengl. From there i'd also like to see some other backends that really embed into other libraries. this has huge implications, it is perhaps even too much of an undertaking?
SDL is a good cross-platform API for managing keyboard/mouse/joystick input and opening windows.
OpenGL is a good cross-platform API for doing quick graphics.
Twisted is a good cross-platform python networking framework.

This leaves out two core things: audio, and user interfaces. You can get by with SDL audio, but you're not going to do anything fun with it. Maybe something could be built on top of PortAudio? But that probably isn't going to support "3D audio" that seems to be the buzz these days.

User interfaces are always going to be a real snag though.. wxWindows is a pain in the butt, Tk is ghetto, Qt isn't cheap, and anything homebrew isn't going to use native widgets. Of course, for games specifically, you're generally writing your own UI anyways, so you could probably get away with using pyui or something of that sort.

In any case, I wouldn't try and write a backend independent of SDL.. you'd be duplicating way too much effort. Use SDL for what it's good for, use other stuff for the rest.

pygame is still a very 'lowlevel' game api. i've noticed it's impossible to make much of a game without wrapping just about every part of pygame into more specialized classes for your own game. at some levels this is good, but on many levels it requires a lot of "cut & paste" code reuse. it's also the 'laborious' part of creating games, i'd always much rather get into the 'fun stuff' than deal with image loading and resource management.
yeah.

along this line i've spent a lot of time trying to think of ways to create a highlevel game library for python. something that could still be used for any style of game, with prebuilt engine parts for popular types of game.

This is an excellent idea. You know, with the right kind of projection and camera angle, you should be able to write any 2D game with a 3D engine. The Z coordinate would just be the sprite draw order. Vector games can be done in the same way, OpenGL has enough primitives to render Macromedia Flash (and I'm very surprised someone hasn't done this yet, because Flash is a dog, especially on PPC for some reason -- probably just due to lack of effort on their part) and probably SVG. I'd have to check up on this, but I'm also pretty sure you have enough primitives in OpenGL to render PostScript -- or at least PDF. And of course, 3D games are a perfect match to a 3D engine. You get so much by using OpenGL -- virtually any reasonable coordinate system you want, a stack of transformations, and even a primitive form of object orientation using display lists. Once you have a scene graph and a good API on top of that, there isn't a whole lot you can't do.

Of course, when you're sitting on top of OpenGL, it's much harder to have a 1:1 correspondence between screen pixels and texture pixels, but I don't work in 320x200 anymore and I don't think that it's really a big deal. Pixel effects are admittedly really hard to do in OpenGL -- but with graphics cards going the way they're going I think it's in the cards that we'll be able to write pixel/fragment shaders to get that back too. Besides, pixel effects are generally too slow to do anyways unless you're writing to the machine with some sort of SIMD.

I really think this is the way things should be going. Screw the software renderer, the hardware is better than I am at blitting.

I actually had a long discussion with my friend last night who teaches artists how to code at NYU.. Right now he's using p5 ( http://www.proce55ing.net/ ) for his class. I think it's too low level and I have serious issues with Java syntax. I think there should be something like pygsear, built on top of the next generation of pygame, to facilitate this kind of learning. The discussion hinged on one thing basically, how much of the fundamentals should these people be forced to learn. I don't think people should have to write their own display loops, or blit pixels if they don't want to. And I *definitely* object to shoving Java down people's throats, whether they want to be a real programmer or not.

-bob