Re: [pygame] Where to next?

["campbell barton" <ideasman@linuxmail.org>]

All these ideas are really interesting-

2 Libraries not talked about are OpenAL for audio and GLUT for input.
Mabe somebody can tell me why this is not a good idea to use these.

I thing a gui would be better as a seperate module WXWINDOWS? and kept that way.
For a more intergrated system a new intergrated ui could be written or just use pyUI? I have never used pyUI.

Is it true that you can skip pygame and sdl by using PyOpenGL, OpenAL, Glut and Twisted?


> 
> 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
> 

-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze