Paul Boddie wrote: > I can only profess familiarity with Pygame which still seems to do more > or less what it always did, although I haven't kept up with the > community, but I have recently released a simple game which seems to > work quite well. By "simple", I mean two-dimensional playing areas, > pre-recorded soundtracks, retro-style gameplay.
PyGame is great at what it does, which as you say, is usually retro-style 2D games. It also provides a reasonable way of setting up a window for input, sound mixing, etc. But its 2D technology is primitive (eg. DirectDraw 6 on Windows if I remember correctly) and much of the rest is not very advanced, such as limited support for controllers, extra mouse buttons, 3D sound, etc. This is more a limitation of SDL which got neglected in recent years. Even C++ comes with OpenGL in the standard library. I am disappointed that this hasn't become the case with Python. I don't even know if PyOpenGL is compatible with the latest incarnation of NumPy or whether you have to rebuild it all yourself. It's a bit of a mess really. > If I were to get into OpenGL, I'd look at stuff like PyQt alongside > other traditional bindings, mostly because such frameworks - certainly > Qt, as far as I've seen from various reports - usually incorporate a > lot of effort resulting from a serious amount of developer attention to > integrating such technologies and making them work reliably in a number > of environments. Does PyQT play well with PyGame? And isn't it more of a windowing environment? > > Pretty much every Python web offering revolves around you having your > > own server with the luxury of running your own long-running processes > > on it. Great for business apps, not much use for the hobbyist or > > independent site. > > Once upon a time I used to advocate my WebStack framework as a solution > to this problem situation: WebStack applications run on BaseHTTPServer > or other monolithic servers (Webware, Twisted, Zope 2, Java Servlet), > but can also be deployed as CGI or in mod_python environments. The > apparent response to this advocacy (which was backed up by an actual > implementation) was that no-one needed such flexibility: an opinion > somewhat at odds with actual practice if you consider widely-deployed > applications such as ViewCVS/ViewVC, Trac, MoinMoin, and so on, where > all of these have provided their own server abstractions at least until > very recently. Of course, if you're a developer producing your own framework - as pretty much everybody on the Web-SIG was - then you're presumably already aiming at the dedicated hosting space, so it's not surprising that such flexibility is not held in high regard by those. > I've said this a few times now, but it's worth repeating: when WSGI was > proposed as the next great thing in Python Web standardisation (a topic > in which no-one had any substantial interest until PHP/Ruby were > considered ahead of Python in certain much-discussed decisions), it was > formulated in such a way as to stay off the turf already occupied by > the significant Python frameworks of the time. This is something I wasn't incredibly happy about, as I felt it meant that personal egos were being saved at the expense of improving Python. And I always thought that WSGI was solving the wrong problem. It certainly didn't go very far towards meeting the expressed goals of the Web-SIG. Oh well. <http://mail.python.org/pipermail/web-sig/2004-August/000650.html> -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
