Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
The msi installer actually uses the version number to decide if a file should be replaced. Of course Microsoft uses a specific numbering scheme. So the msi installer builder in Python 2.5 distutils must translate the version number in setup.py. It can handle a's and b's but has no clue what to do with rc's so raises an exception. I have been changing setup.py by hand, so the msi versions I release differ from the formal releases. Also, if I forget I have changed setup.py and commit some change to SVN the version number I use will be accidentally committed as well. But then if we are close to the last release candidate then it is not a big issue. I have made the new changes available under sv4, but will change to whatever is decided. Lenard René Dudfield wrote: Why can't it use the other naming scheme again? On Thu, Mar 6, 2008 at 10:16 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: I suggest calling the release 1.8.0a1 or 1.8.0b1 or something so it works nicely with the msi installer on Windows. Lenard
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
Why can't it use the other naming scheme again? On Thu, Mar 6, 2008 at 10:16 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > I suggest calling the release 1.8.0a1 or 1.8.0b1 or something so it > works nicely with the msi installer on Windows. > > Lenard > > > > > René Dudfield wrote: > > hi all, > > > > I think we'll need to do another rc release... > > > > I've fixed a few things in subversion. Enough that would require > > testing again I think. > > > > btw, the compile farm that Brian made is coool! It speeds up testing > > a lot when you don't have that platform available :) > > > > cu, > > > > On Wed, Mar 5, 2008 at 8:07 AM, René Dudfield <[EMAIL PROTECTED]> wrote: > > > >
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
I suggest calling the release 1.8.0a1 or 1.8.0b1 or something so it works nicely with the msi installer on Windows. Lenard René Dudfield wrote: hi all, I think we'll need to do another rc release... I've fixed a few things in subversion. Enough that would require testing again I think. btw, the compile farm that Brian made is coool! It speeds up testing a lot when you don't have that platform available :) cu, On Wed, Mar 5, 2008 at 8:07 AM, René Dudfield <[EMAIL PROTECTED]> wrote:
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
hi all, I think we'll need to do another rc release... I've fixed a few things in subversion. Enough that would require testing again I think. btw, the compile farm that Brian made is coool! It speeds up testing a lot when you don't have that platform available :) cu, On Wed, Mar 5, 2008 at 8:07 AM, René Dudfield <[EMAIL PROTECTED]> wrote: > hi, > > yeah, we changed clock.tick to use the non cpu chewing one. Just > because by default we should try to save energy. > > > To get the old behaviour on different pygame versions, you could use > something like: > > if hasattr(clock , "tick_busy_loop"): > tick = clock.tick_busy_loop > else: > tick = clock.tick > > > However, I think it's best to use less power in general :) Or to make > it an option for game players. > > > > cu, > > > > > On Wed, Mar 5, 2008 at 4:54 AM, PyMike <[EMAIL PROTECTED]> wrote: > > Hmm... I played one of my more recent games, and sometimes moving stuff > will > > jerk around a little bit. I used clock.tick_busy_loop and it seemed to go > > away... > > > > > > > > On Tue, Mar 4, 2008 at 11:51 AM, PyMike <[EMAIL PROTECTED]> wrote: > > > > > Aye. I always use clock.tick. Well this is awesome that games can now run > > fast and not chew up CPU! Thank you pygame! :D > > > > > > > > > > > > > > > > > > On Tue, Mar 4, 2008 at 11:45 AM, Brian Fisher <[EMAIL PROTECTED]> > > wrote: > > > > > > > I assume that's with games using Clock.tick? > > > > > > > > I think vs. 1.7 pygame 1.8 changed Clock.tick to be more cpu friendly: > > > > http://www.pygame.org/docs/ref/time.html#Clock.tick > > > > > > > > Clock.tick_busy_loop would be a CPU unfriendly alternative. > > > > > > > > > > > > > > > > > > > > On Tue, Mar 4, 2008 at 7:00 AM, PyMike <[EMAIL PROTECTED]> wrote: > > > > > Has anyone noticed that now games running at 60 fps are only using > > 10-16% of > > > > > the CPU? > > > > > > > > > > > > > > > > > > > > > -- > > > - PyMike > > > > > > > > -- > > - PyMike >
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
hi, yeah, we changed clock.tick to use the non cpu chewing one. Just because by default we should try to save energy. To get the old behaviour on different pygame versions, you could use something like: if hasattr(clock , "tick_busy_loop"): tick = clock.tick_busy_loop else: tick = clock.tick However, I think it's best to use less power in general :) Or to make it an option for game players. cu, On Wed, Mar 5, 2008 at 4:54 AM, PyMike <[EMAIL PROTECTED]> wrote: > Hmm... I played one of my more recent games, and sometimes moving stuff will > jerk around a little bit. I used clock.tick_busy_loop and it seemed to go > away... > > > > On Tue, Mar 4, 2008 at 11:51 AM, PyMike <[EMAIL PROTECTED]> wrote: > > > Aye. I always use clock.tick. Well this is awesome that games can now run > fast and not chew up CPU! Thank you pygame! :D > > > > > > > > > > > > On Tue, Mar 4, 2008 at 11:45 AM, Brian Fisher <[EMAIL PROTECTED]> > wrote: > > > > > I assume that's with games using Clock.tick? > > > > > > I think vs. 1.7 pygame 1.8 changed Clock.tick to be more cpu friendly: > > > http://www.pygame.org/docs/ref/time.html#Clock.tick > > > > > > Clock.tick_busy_loop would be a CPU unfriendly alternative. > > > > > > > > > > > > > > > On Tue, Mar 4, 2008 at 7:00 AM, PyMike <[EMAIL PROTECTED]> wrote: > > > > Has anyone noticed that now games running at 60 fps are only using > 10-16% of > > > > the CPU? > > > > > > > > > > > > > > > -- > > - PyMike > > > > -- > - PyMike
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
Hmm... I played one of my more recent games, and sometimes moving stuff will jerk around a little bit. I used clock.tick_busy_loop and it *seemed* to go away... On Tue, Mar 4, 2008 at 11:51 AM, PyMike <[EMAIL PROTECTED]> wrote: > Aye. I always use clock.tick. Well this is awesome that games can now run > fast and not chew up CPU! Thank you pygame! :D > > > On Tue, Mar 4, 2008 at 11:45 AM, Brian Fisher <[EMAIL PROTECTED]> > wrote: > > > I assume that's with games using Clock.tick? > > > > I think vs. 1.7 pygame 1.8 changed Clock.tick to be more cpu friendly: > > http://www.pygame.org/docs/ref/time.html#Clock.tick > > > > Clock.tick_busy_loop would be a CPU unfriendly alternative. > > > > On Tue, Mar 4, 2008 at 7:00 AM, PyMike <[EMAIL PROTECTED]> wrote: > > > Has anyone noticed that now games running at 60 fps are only using > > 10-16% of > > > the CPU? > > > > > > > > > -- > - PyMike -- - PyMike
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
Aye. I always use clock.tick. Well this is awesome that games can now run fast and not chew up CPU! Thank you pygame! :D On Tue, Mar 4, 2008 at 11:45 AM, Brian Fisher <[EMAIL PROTECTED]> wrote: > I assume that's with games using Clock.tick? > > I think vs. 1.7 pygame 1.8 changed Clock.tick to be more cpu friendly: > http://www.pygame.org/docs/ref/time.html#Clock.tick > > Clock.tick_busy_loop would be a CPU unfriendly alternative. > > On Tue, Mar 4, 2008 at 7:00 AM, PyMike <[EMAIL PROTECTED]> wrote: > > Has anyone noticed that now games running at 60 fps are only using > 10-16% of > > the CPU? > > > -- - PyMike
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
I assume that's with games using Clock.tick? I think vs. 1.7 pygame 1.8 changed Clock.tick to be more cpu friendly: http://www.pygame.org/docs/ref/time.html#Clock.tick Clock.tick_busy_loop would be a CPU unfriendly alternative. On Tue, Mar 4, 2008 at 7:00 AM, PyMike <[EMAIL PROTECTED]> wrote: > Has anyone noticed that now games running at 60 fps are only using 10-16% of > the CPU? >
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
Has anyone noticed that now games running at 60 fps are only using 10-16% of the CPU? On Mon, Mar 3, 2008 at 1:16 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > I have updated all installers and document bundles on my site* to rc4. > So the msi installer is ready for a Vista trial. > > Slightly off topic, but one thing I remembered is that the MMX scaling > code Richard Goedeken so generously donated in not used in Visual C > builds. The MMX code is in AT&T form, not used by masm. So the options > are to add an masm translation of the code to transform.c or just use > the MinGW compiled transform.pyd. Of course VC may be clever enough to > do its own MMX optimization. > > > Lenard > > * http://www3.telus.net/len_l/pygame.htm > > md5sums: > > 9d703bc98c8c9072111409fb08208338 *pygame-1.8.0rc4.win32-py2.5.exe > 38bc762790f190c13e4ef9431240007b *pygame-1.8.0a0.win32-py2.4.msi > fb402e329d1e4e18071ee96e7cdda7fe *pygame-1.8.0rc4.win32-py2.4.exe > 38bc762790f190c13e4ef9431240007b *pygame-1.8.0a0.win32-py2.4.msi > c0efabf383c42652b384085a3311ef6b *pygame-1.8-docs-setup.exe > > > René Dudfield wrote: > > Hi, > > > > I've tagged pygame1.8.0rc4. > > > [snip] > > > > Mac OSX, and windows binary installers are coming soon. > > > > It's also tagged in subversion as 1.8.0rc4. > > > > The todo so far is: > > - test builds with vista mods, so they install nicely without > > administrator privs. > > - need to test with added manifest. > > - update the credits file... we need to go through the WHATSNEW file > > and add credits for all the contributions to pygame since the last > > release. > > > > > [snip] > > I'll hopefully be able to test the manifest > > stuff on a vista laptop tomorrow night. > > > > > -- - PyMike
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
I have updated all installers and document bundles on my site* to rc4. So the msi installer is ready for a Vista trial. Slightly off topic, but one thing I remembered is that the MMX scaling code Richard Goedeken so generously donated in not used in Visual C builds. The MMX code is in AT&T form, not used by masm. So the options are to add an masm translation of the code to transform.c or just use the MinGW compiled transform.pyd. Of course VC may be clever enough to do its own MMX optimization. Lenard * http://www3.telus.net/len_l/pygame.htm md5sums: 9d703bc98c8c9072111409fb08208338 *pygame-1.8.0rc4.win32-py2.5.exe 38bc762790f190c13e4ef9431240007b *pygame-1.8.0a0.win32-py2.4.msi fb402e329d1e4e18071ee96e7cdda7fe *pygame-1.8.0rc4.win32-py2.4.exe 38bc762790f190c13e4ef9431240007b *pygame-1.8.0a0.win32-py2.4.msi c0efabf383c42652b384085a3311ef6b *pygame-1.8-docs-setup.exe René Dudfield wrote: Hi, I've tagged pygame1.8.0rc4. [snip] Mac OSX, and windows binary installers are coming soon. It's also tagged in subversion as 1.8.0rc4. The todo so far is: - test builds with vista mods, so they install nicely without administrator privs. - need to test with added manifest. - update the credits file... we need to go through the WHATSNEW file and add credits for all the contributions to pygame since the last release. [snip] I'll hopefully be able to test the manifest stuff on a vista laptop tomorrow night.
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
ya! Thanks. On Mon, Mar 3, 2008 at 11:21 PM, Marcus von Appen <[EMAIL PROTECTED]> wrote: > On, Mon Mar 03, 2008, Rene Dudfield wrote: > > > Hi, > > > > I've tagged pygame1.8.0rc4. > > > > Here's the tar ball for testing: > > http://rene.f0o.com/~rene/stuff/pygame-1.8.0rc4.tar.gz > > Great! I just put a note on the news site. > > Regards > Marcus >
Re: [pygame] Announce: pygame 1.8.0rc4 tar ball.
On, Mon Mar 03, 2008, Rene Dudfield wrote: > Hi, > > I've tagged pygame1.8.0rc4. > > Here's the tar ball for testing: > http://rene.f0o.com/~rene/stuff/pygame-1.8.0rc4.tar.gz Great! I just put a note on the news site. Regards Marcus pgpN653iyLXBx.pgp Description: PGP signature
[pygame] Announce: pygame 1.8.0rc4 tar ball.
Hi, I've tagged pygame1.8.0rc4. Here's the tar ball for testing: http://rene.f0o.com/~rene/stuff/pygame-1.8.0rc4.tar.gz md5sum 4e07b4a68ebc1773f7a2ad557b6adc6c pygame-1.8.0rc4.tar.gz Mac OSX, and windows binary installers are coming soon. It's also tagged in subversion as 1.8.0rc4. The todo so far is: - test builds with vista mods, so they install nicely without administrator privs. - need to test with added manifest. - update the credits file... we need to go through the WHATSNEW file and add credits for all the contributions to pygame since the last release. and I think that is it. I'll hopefully be able to test the manifest stuff on a vista laptop tomorrow night. Now we can test the tar ball, get the binaries out, test them a bit more, and then release 1.8.0release in a week or so. Assuming there are no big issues :) cu,
