Re: [pygame] Where to next?

[sylvain dufour <sylvain.dufour@hotpop.com>]

On Lundi 14 Juillet 2003 02:29, campbell barton wrote:
> 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.

Well as far as I know OpenAL is not that much different from SDL_mixer 
(please correct me if I'm wrong). Last time I checked there was spatial 
sound positioning though...
You can find python bindings here: http://oomadness.tuxfamily.org
Concerning sound you might also investigate http://www.fmod.org

I haven't played around with GLUT yet, but I guess there are some 
reasons why all those commercial FPS on linux stick to SDL_input...


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

IMHO pyUI, while a nice toolkit is just too slow for many uses. Maybe 
some python wrappers around paragui would be better ?


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

I guess you could, but you'd miss some important points:
-easier coding: you just have to learn the subtleties of only one lib, 
like coding conventions, what values are returned etc... Using SDL you 
init() everything in just 2 calls. by learning only one lib you keep it 
simple, learn more quickly and can concentrate more on the game logic 
itself
-easier distribution: besides python (installed by default on any recent 
linux distrib), you just have to ship one lib with your game, whereas a 
game like slune (also http://oomadness.tuxfamily.org), with its custom 
3D engine, network code etc.. is a nightmare to install
-learning curve: pygame keeps things simple. Python is quite easy to 
learn, pygame is one step up the ladder but OpenGL is a different 
game... just reading the red book, understanding it and applying 
examples to python might take years and discourage a novice...

As a conclusion I'll add my own wishlist for pygame 2.0:

-a C implementation with python bindings of common pathfinding 
algorithms, like A* or Djikstra (sp?)
-maybe a thin object-oriented layer on top of the main libs, with 
classes like GameState, Map etc...
- some basic networking code

(I could help for the second one at least...)

Apologies for the broken english

cheers,
sylvain