PyGameZine launched. See http://pygame.org for details.
Hey ya, today we launched the first issue of PyGameZine. For more info, please see the pygame website: http://www.pygame.org/ cheers! -- http://mail.python.org/mailman/listinfo/python-list
Python 3.0 C API migration tools, or docs?
Hi, are there migration tools for C API migration to python 3? I'm sure there must be some code somewhere to help change stuff over right? I don't see any docs for migrating code from 2.x to 3.x either: http://docs.python.org/3.0/c-api/index.html Help needed with this! cheers, -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 C API migration tools, or docs?
Cool thanks Benjamin! Maybe it should be in a wiki as well? So that as people convert their modules we can add notes as well. I started a wiki with that in mind here: http://wiki.python.org/moin/cporting It'd be good if there was a link from the 2to3 docs, and in the C API docs to either/both of these resources. I thought there'd be much more help for people migrating considering the 2to3 tool exists... but I'll get over it... hehe. cheers, On Dec 5, 1:23 pm, Benjamin <[EMAIL PROTECTED]> wrote: > On Dec 4, 7:45 pm, illume <[EMAIL PROTECTED]> wrote: > > > Hi, > > > are there migration tools for C API migration to python 3? > > > I'm sure there must be some code somewhere to help change stuff over > > right? > > > I don't see any docs for migrating code from 2.x to 3.x > > either:http://docs.python.org/3.0/c-api/index.html > > At the moment all that is officially available is this rather > incomplete howto:http://docs.python.org/howto/cporting.html > > > > > Help needed with this! > > > cheers, > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Strengths and weaknesses of Pygame vs. pyglet vs. PyOpenGL?
hello, PyOpenGL also has a raw module which includes python bindings closer to the C calls... however mostly you want to use the nicer more pythonic versions of functions. Recent pyopengl 3.x versions have been optimized for speed, including optional C level optimizations. So I imagine they are faster than pyglets wrappers(profiling/testing needed). PyOpenGL is also used a lot more by non-game people, so a wider array of functions are used. It's very unfortunate that pyglet and pyopengl don't share code... however recent versions of pyopengl tried to reuse some of pyglets code... not sure how much has been shared though. Maybe at some point they will come together. For now pyglet has created a fork in the python+opengl community, where the same code can't be reused automatically between the two as the opengl wrappers are slightly different. However it's not terribly difficult to port code from one to the other, as some projects have done. pygame doesn't require opengl be supported by the video card - it can use many different video drivers to get the job done. It's nice to be able to avoid using the 3D parts of gfx cards if you can - to reduce power consumption, and make your game run on more computers. pygame is also much more portable, has more people using it, has more developers, and a stable API. Code you wrote 5 years ago will most likely still work. Code you wrote for older versions of pyglet will not work without changes. pygame is simpler to learn, since it doesn't require you to know how to create classes or functions. Whereas pyglet requires you to sub class to do anything. http://pygame.org/wiki/about * disclaimer - I'm a pygame developer, and have in the past contributed to pyopengl - so obviously I prefer pygame and pyopengl. On Dec 8, 12:53 pm, alex23 <[EMAIL PROTECTED]> wrote: > On Dec 8, 11:23 am, [EMAIL PROTECTED] wrote: > > > Does pyglet use PyOpenGL as its OpenGL wrapper? If not, any idea why? > > Seems like it would be a fairly substantial duplication of effort. > > Taken from:http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d > > > > >> IIRC pyglet tries to minimize dependencies, so PyOpenGL won't be > >> used. However, pyglet's wrapping of OpenGL isn't meant to be > >> complete; it's only what pyglet itself uses. You'll need to use > >> PyOpenGL for the rest. > > That was more or less the original plan. pyglet wraps OpenGL at the > > lowest level, so it only provides glVertex3f, glVertex2d, etc., > > whereas PyOpenGL also provides polymorphic functions such as glVertex. > [...] > > pyglet provides all of the error-checking functionalities that > > PyOpenGL does (though these can be disabled for performance). At > > last check, pyglet was significantly faster than PyOpenGL 3, but > > slower than PyOpenGL 2. > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Strengths and weaknesses of Pygame vs. pyglet vs. PyOpenGL?
On Dec 8, 7:31 pm, alex23 <[EMAIL PROTECTED]> wrote: > On Dec 8, 2:26 pm, illume <[EMAIL PROTECTED]> wrote: > > > pygame is simpler to learn, since it doesn't require you to know how > > to create classes or functions. > > I'm not sure if I'd be quick to tout that as an advantage... :) Hi, It's easier to teach only requiring *using* classes, and functions than *creating* them. This is important if it's being used to teach programming - as you don't need to teach people two fairly large concepts before you can do anything. People are motivated by seeing results. So it can be good to let people do things without requiring much learning. Anyone teaching object oriented program will tell you that it's a hard concept to present to people. So if you can avoid teaching parts of OO, and a bunch of other concepts at the same time, it's easier for people to handle. It's quite nice to be able to handle events without requiring callbacks. Everyone hates callbacks, but lots of people use them for event systems. However callbacks aren't needed at all for event programming. Instead you can get an event as an object and then process it. Callbacks for events made more sense in languages like smalltalk where events and method calls were closely aligned concepts(method calls are messages in smalltalk). However in languages where you don't have such a close conceptual alignment(such as python), making events objects instead of method calls is much easier to understand. Also python has very slow function calls, so avoiding using callbacks is also faster. Imagine using callbacks for files? So you would have to subclass file, and make a read_data method. Then your class will call your read data method when some data arrives. Kind of annoying, and not needed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Strengths and weaknesses of Pygame vs. pyglet vs. PyOpenGL?
On Dec 8, 8:59 pm, alex23 <[EMAIL PROTECTED]> wrote: > On Dec 8, 7:18 pm, illume <[EMAIL PROTECTED]> wrote: > > > It's easier to teach only requiring *using* classes, and functions > > than *creating* them. This is important if it's being used to teach > > programming - as you don't need to teach people two fairly large > > concepts before you can do anything. > > I'm just kind of aghast at the idea of "teaching" anyone how to > program games by using large, imperative chunks of code. I don't see > functions as being a "fairly large concept" at all, and utterly vital > to being able to write anything but the most basic 'hello world' > example code. > Yes, teaching hello world without requiring the creation classes is a *good thing*. Imagine having to create classes to make a hello world program? You'd have a typical java hello world program. This means you need to explain the concept of OO before they can do hello world. It's about teaching concepts separately, rather than requiring them to be taught all at once. If you don't need to use something, then why bother using it? Just for purity? Python has a long history of not making everything classes. So I see requiring the creation of classes to do 'hello world' as being un-pythonic and overly complex. I also see it getting in the way of seeing results, which is important when intially learning programming. > > Also python has very slow function calls, so avoiding using callbacks > > is also faster. > > Wouldn't it be better to teach people the basics of coding -before- > setting out to optimise their code? I was explaing the advantages of avoiding callbacks, and avoiding requiring the creation of classes. I think it's simpler, and faster to avoid callbacks. I was not saying that it's better to optimize peoples code before teaching people the basics of programming. -- http://mail.python.org/mailman/listinfo/python-list
pygame 1.8.1 released
Hello, Stick a fork in it, it's baked... nice and toasty. A new version of pygame is out. http://www.pygame.org/ Pygame is a set of Python modules designed for writing games. Pygame adds functionality on top of the excellent SDL library. This allows you to create fully featured games and multimedia programs in the python language. Pygame is highly portable and runs on nearly every platform and operating system. http://www.pygame.org/wiki/about Silliness built in. Does not require OpenGL. Multi core CPUs can be used easily. Uses optimized C, and Assembly code for core functions. Comes with many Operating systems. Truly portable. It's Simple, and easy to use. Many games have been published. You control your main loop. Does not require a GUI to use all functions. Fast response to reported bugs. Small amount of code. Modular. Over 1000 open source games have been released that use pygame, so there are lots of examples to learn from. http://pygame.org/whatsnew.shtml Many bug fixes and improvements, including: * BLEND_RGBA_* blitters and blenders to go with the BLEND_RGB_* blend modes. * documentation updates (mainly for new sprite classes released in 1.8.0) * sound fixes, and streaming some music from file like objects * image saving fixes * greatly expanded tests * Pixelarray, and surfarray updates and fixes. * Enhanced Color class, reimplemented in C for speed. * New Windows and Mac binary installers. See the what's new page for full details http://pygame.org/whatsnew.shtml Many thanks to Marcus, Lenard, Brian, Nicholas, Charlie Nolan, Nirav Patel, Forrest Voight, Charlie Nolan, Frankie Robertson, John Krukoff, Lorenz Quack, Nick Irvine, Zhang Fan and everyone else who helped out with this release. Next release will include the physics engine, Webcam support, enhanced easy and automatic multithread support amongst other goodies -- they have been in development for over 3 months full time so far. cheers, -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 and wrapping C libraries on Windows
Hi,
after a little research it appears that win9x is not supported by the
msvcr90.dll run time.
Can you confirm this Lenard?
Has anyone tested the new python binaries that link to msvcr90.dll on
win9x machines?
cheers,
On May 1, 3:05 pm, "L. Lindstrom" <[EMAIL PROTECTED]> wrote:
> L. Lindstrom wrote:
> > Christian Heimes wrote:
> >> L. Lindstrom schrieb:
> [snip]
> >>> [B]esides heap management and FILE pointers, is there any reason SDL, or
> >>> any C dependency, needs to link to the same C run-time as Python? If I
> >>> ensure SDL frees memory it allocates and does not directly access a file
> >>> opened by Python can I just use another C run-time such as msvcrt?
>
> >> Your analysis of the problem and the implication of mixing CRTs is
> >> correct. However ...
>
> >> It should be trivial to modify the build systemof SDL so that the
> >> manifest is integrated into the DLLs. Everything else is a hack. It
> >> *should* work and in reality it *does* work for most cases. But someday
> >> you'll hit a solid wall and get strange and hard to debug segfaults.
>
> [snip]
> > Linking to msvcr90.dll is possible with MinGW. The problem is with the
> > configure scripts. So I can run configure against msvcrt.dll, then
> > switch to mscvr90.dll for make. If this works I will make SDL and a test
> > program available on-line so someone can find the appropriate manifests.
>
> Here is my attempt to link SDL and a test program with msvcr90.dll. It
> can be found athttp://www3.telus.net/len_l/pygame. The md5sum is:
>
> f5b71d9934d35c35a24b668ad8023146 *VC-2008-Run-Time-test.zip
>
> Both lack a manifest. The test program and SDL work when a surrogate
> run-time is provided, a renamed msvcr71.dll . So if someone can show me
> the necessary manifest to make SDL use the C run-time installed by the
> Python 2.6 installer I would appreciate it. SDL is built with MinGW so I
> doubt I can distribute the run-time with it.
>
> --
> Lenard Lindstrom
> "[EMAIL PROTECTED]" % ('len-l', 'telus', 'net')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 and wrapping C libraries on Windows
hi again,
I should have said, the msvcr90.dll does not work on win9x machines -
as well as not being supported by ms.
cu,
On May 1, 4:02 pm, illume <[EMAIL PROTECTED]> wrote:
> Hi,
>
> after a little research it appears that win9x is not supported by the
> msvcr90.dll run time.
>
> Can you confirm this Lenard?
>
> Has anyone tested the new python binaries that link to msvcr90.dll on
> win9x machines?
>
> cheers,
>
> On May 1, 3:05 pm, "L. Lindstrom" <[EMAIL PROTECTED]> wrote:
>
> > L. Lindstrom wrote:
> > > Christian Heimes wrote:
> > >> L. Lindstrom schrieb:
> > [snip]
> > >>> [B]esides heap management and FILE pointers, is there any reason SDL, or
> > >>> any C dependency, needs to link to the same C run-time as Python? If I
> > >>> ensure SDL frees memory it allocates and does not directly access a file
> > >>> opened by Python can I just use another C run-time such as msvcrt?
>
> > >> Your analysis of the problem and the implication of mixing CRTs is
> > >> correct. However ...
>
> > >> It should be trivial to modify the build systemof SDL so that the
> > >> manifest is integrated into the DLLs. Everything else is a hack. It
> > >> *should* work and in reality it *does* work for most cases. But someday
> > >> you'll hit a solid wall and get strange and hard to debug segfaults.
>
> > [snip]
> > > Linking to msvcr90.dll is possible with MinGW. The problem is with the
> > > configure scripts. So I can run configure against msvcrt.dll, then
> > > switch to mscvr90.dll for make. If this works I will make SDL and a test
> > > program available on-line so someone can find the appropriate manifests.
>
> > Here is my attempt to link SDL and a test program with msvcr90.dll. It
> > can be found athttp://www3.telus.net/len_l/pygame. The md5sum is:
>
> > f5b71d9934d35c35a24b668ad8023146 *VC-2008-Run-Time-test.zip
>
> > Both lack a manifest. The test program and SDL work when a surrogate
> > run-time is provided, a renamed msvcr71.dll . So if someone can show me
> > the necessary manifest to make SDL use the C run-time installed by the
> > Python 2.6 installer I would appreciate it. SDL is built with MinGW so I
> > doubt I can distribute the run-time with it.
>
> > --
> > Lenard Lindstrom
> > "[EMAIL PROTECTED]" % ('len-l', 'telus', 'net')
--
http://mail.python.org/mailman/listinfo/python-list
dropping win98 support? was Re: Python 2.6 and wrapping C libraries on Windows
Ah, why is that? There's still at least 1.1% of people using win98, if you believe this source of stats: http://www.w3schools.com/browsers/browsers_os.asp I just noticed that win9x winme and win nt are all being dropped from python. I know they are old and crufty, but there's still heaps of people using them. Someone pointed me to the pep, where the un-support seems planned: http://www.python.org/dev/peps/pep-0011/ Seems like a lot of people using it, so it's still worthwhile making 2.6 work with win98. On May 1, 10:09 pm, Christian Heimes <[EMAIL PROTECTED]> wrote: > illume schrieb: > > > Hi, > > > after a little research it appears that win9x is not supported by the > > msvcr90.dll run time. > > > Can you confirm thisLenard? > > > Has anyone tested the new python binaries that link to msvcr90.dll on > > win9x machines? > > It doesn't matter to use because Python 2.6 and 3.0 require at least > Windows 2000 SP4. The 9x, ME and NT series aren't supported any more. > > Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: dropping win98 support? was Re: Python 2.6 and wrapping C libraries on Windows
On May 2, 8:37 am, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "illume" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > | Ah, why is that? > > Were any of the reasons given inhttp://www.python.org/dev/peps/pep-0011/ > unclear? > It appears you are already aware of MS's non-support of Win98 Hello, It seems the main reason is for ease of maintenance. However the Pep title is misleading with regards to win9x+winMe+win2k - which is where my confusion, questions and argument came from. "Title: Removing support for little used platforms" There are still *lots* of people who still use win95, 98, 98se, me, and win2k - as shown by the statistics I linked to in a previous post. If you want more statistics about the number of people using what OS they are fairly easy to find with a search engine. One day win9x will be finally dead, but that's not yet(and the w3c stats show it's usage actually increasing in march!). It is probably way too late in the process to put back code - and as you say no python developers have volunteered. So I won't argue any more for it to come back. We'll just have to recommend a different python implementation than 2.6 or 3.0 for people who want to support people with these old computers. cheers, -- http://mail.python.org/mailman/listinfo/python-list
