[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Where to next?
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