[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