Re: [pygame] Earliest access to state of keyboard?

[Brian Fisher]

I think the problem is that the way SDL works, since it never got the alt
down event, so it will never think alt is held :(

as a test, I tried modifying a little game script to print
pygame.key.get_mods() continuously in the game loop, and it was always 0
for the alt key being held before the script ran.

If you really want something like this, I'd turn to platform specific
function calling through ctypes. This should do it on windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646301(v=vs.85).aspx


On Wed, Jul 3, 2013 at 8:16 AM, Keith Nemitz muse...@yahoo.com wrote:


 I'd like to poll the keyboard before opening a window, in order to
 determine if the game should launch in Window or Fullscreen mode.  This
 code prints 0:

 pygame.event.pump();
 print pygame.key.get_mods();

 #then open window
 pygl2d.window.init(...)


 I suspected there had to be a window before the event system works. But
 this code also prints 0:

 pygame.init();
 pygame.display.set_mode([1024, 768], DOUBLEBUF); #fake window to allow
 access to keys
 pygame.event.pump();
 print pygame.key.get_mods();

 #now change window to reflect keypress...


 suggestions?

Re: [pygame] pygame2exe issue

[Brian Fisher]

One of the core features of py2exe is that it automatically finds the
imported dependencies off of the main script, and includes them in the
package. Just specifying the top level script should be enough. The
problem you are describing should not be an issue.

Can you share Main.py? There may be something unusual about how it
imports the rest of the game.

Also, what exactly is the error you get?

On Sun, Feb 3, 2013 at 9:34 PM, Steven Sabatino
sabatino.ste...@gmail.com wrote:
 I am using 2.7 and if you look at my script that stops the error you are
 talking about. This script works is a problem with the depend scripts not
 being loaded

 On Feb 3, 2013 11:35 PM, Syndwar possessed-by-z...@yandex.ru wrote:

 The most common problem is lack of freesansbold.ttf in the compiled files.
 For some reason py2exe and cxfreeze don't copy it to the library files.
 Find
 this file and copy it manualy to your compiled project. Also - what
 version
 of the python do you use?



 --
 View this message in context:
 http://pygame-users.25799.n6.nabble.com/pygame-pygame2exe-issue-tp472p473.html
 Sent from the pygame-users mailing list archive at Nabble.com.

Re: [pygame] Release engineer wanted

[Brian Fisher]

I'm assuming you want to sell without any kind of DRM (also not
advocating or suggesting you should want to - just being clear)


If those are your only dependencies, you've made a game worth selling,
and you have access to some kind of windows PC, you can easily do this
yourself on windows.

You make your game into an exe with this:
http://www.py2exe.org/

and you can make your installer with this:
http://www.jrsoftware.org/isinfo.php/

both require some very light and simple config scripts, just find some
examples of each and modify.


mac installers might be a bit more trouble, because you have so many
options (32 vs 64 bit, system python vs framework, blah blah) and you
may have trouble with one or the other, but the process is similar and
straightforward. You'll also need access to a mac for this.

To make your game into an app, you need py2app:
http://pypi.python.org/pypi/py2app/

To bundle it, usually people just zip the app for simplicity (after
downloading it, they just get your app on the desktop and do with it
what they want) and that's what I'd recommend. But if you want
something fancier, you could do either compressed disk image (kind of
old school, but still a good option) where you make a background image
for the image that shows that people should drag the icon to
applications or some crap like that. You could also do an installer,
but for your case it would be more complicated with no benefit.


On Fri, Aug 17, 2012 at 8:02 AM, Luke Miller dodgyvi...@gmail.com wrote:
 Greetings,

 I have a game written in pygame that I am hoping to release in a few
 months for Windows, Mac and Linux.

 I am looking for someone who is familiar with packaging up pygame
 projects into professional looking windows (exe) and mac installers
 (app) who can do it for my game. The only dependencies are pygame 1.9
 and python 2.7. There are a few directories with assets in them such
 as art, ogg sound files and some text scripts.

 I'm pretty sure it's an easy job if you know what you're doing, and I
 am willing to pay a premium to make it a low hassle. Not only would
 you be earning some quick cash, helping me out and also taking pygame
 to a new audience, but you also get release engineer in the credits.

 My gmail contact address is dodgyville.

 Regards,
 Luke

Re: [pygame] any cocos2d people on the list?

[Brian Fisher]

try the pyglet mailing list, cocos2d uses pyglet, and the cocos2d for
android and for iPhone libs were built off the original but stopped
using python.

On Wed, Mar 14, 2012 at 11:06 AM, Sean Felipe Wolfe ether@gmail.com wrote:
 I'm continuing to enjoy plugging away at my projects in pygame,
 however I couldn't help but notice the activity going on with cocos2d.
 The original library seems to be python-based although much more
 activity is happening in the iphone world with objective-c.

 I poked around the documentation a bit, and my first thought I wasn't
 too excited. I like the simplicity and SDL orientation of the pygame
 model whereas cocos2d seems to be doing a lot of pre-made work for me
 which isn't as fun to explore with.

 That said, there is a whole lot of traffic on the obj-c branch
 especially, which would make it easier I am thinking to port to iphone
 down the road.

 Anyhow, just thought I'd see if anyone is doing any cocos2d projects?

 --
 A musician must make music, an artist must paint, a poet must write,
 if he is to be ultimately at peace with himself.
 - Abraham Maslow

Re: [pygame] Help with pygame

[Brian Fisher]

How did you install pygame, Zack?

On Wed, Dec 14, 2011 at 12:47 PM, Zack Baker zbaker1...@gmail.com wrote:
 Ok i ran it and this is the error it gave me...

 2011-12-14 15:46:45.796 Python[12670:f07] Warning once: This application, or 
 a library it uses, is using NSQuickDrawView, which has been deprecated. Apps 
 should cease use of QuickDraw and move to Quartz.
 Traceback (most recent call last):
  File green-car-test.py, line 10, in module
    car=pygame.image.load('green-car.png')
 pygame.error: File is not a Windows BMP file
 On Dec 12, 2011, at 10:11 PM, Brian Fisher wrote:





 BTW i think im just going to reinstall pygame
 the get extended() thing returned 0

 green-car.zip

Re: [pygame] Help with pygame

[Brian Fisher]

I use a Mac, and while I have compiled from source, I wouldn't
recommend it because you still have to manage getting the dependencies
yourself (meaning libpng, libjpg and sdl and maybe a couple others)

I would use a prebuilt installer on this page, if you can find one that works:
http://pygame.org/download.shtml

the prebuilt installers *should* have been made to include all the
dependencies linked in a static or embedded way when possible (so as
to avoid replacing shared components for other software)

On Wed, Dec 14, 2011 at 1:51 PM, Zack Baker zbaker1...@gmail.com wrote:
 Ok, I have deleted everything pygame I could find an now I'm going to 
 reinstall it. Along with python 3.2 because I guess now they are compatible 
 on OSX which would be great. Btw in case it doesn't could you point me too a 
 link that shows how to compile from source? Thanks

 -Zack


 On Dec 14, 2011, at 4:46 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:

 Zack Baker wrote:
 With fink

 I'm on OSX, and I find it's generally less hassle in the long run
 to compile everything from source myself rather than rely on things
 like fink and macports, so I don't have much experience with them.

 But you could look into whether there is a fink version of libpng
 that you can install -- that would probably help.

 --
 Greg

Re: [pygame] Help with pygame

[Brian Fisher]

Zach, code looks fine - can you attach the image as well? The problem
may lie with it.

thanks

On Sun, Dec 11, 2011 at 2:49 PM, Zack Baker zbaker1...@gmail.com wrote:
 Ok guys heres the code. Same error, better code.
 #!/usr/bin/env python

 import pygame
 pygame.init()

 #Set height and width of the screen
 size=[400,500]
 screen=pygame.display.set_mode(size)


 #Loop until user clicks the close button
 done=False
 clock=pygame.time.Clock()

 while done==False:
     #This limits the while loop to a max of 10 times per second
     clock.tick(10)

     for event in pygame.event.get():
         if event.type==pygame.QUIT:
             done=True
     car=pygame.image.load('images.BMP')
     screen.blit(car, (50, 100))
     pygame.display.flip()


 pygame.quit()







 pygame.quit()

Re: [pygame] Help with pygame

[Brian Fisher]

Zack,
 There are a lot of problems with the script you posted, but the error
you are getting says that the first problem is with loading the image
file, so might as well start there.

 So on your next reply, please attach the image file you are trying to
load and draw. That way people can test themselves which would help a
lot in figuring out what's going on.


On Sat, Dec 10, 2011 at 4:28 AM, Zack Baker zbaker1...@gmail.com wrote:
 Sorry guys, my bad, I only changed the name when I put the code on there. It 
 was both images.png or whatever. I'm very sorry for the confusion. Also could 
 the problem be that I didn't draw the screen?

 -Zack


 On Dec 10, 2011, at 4:42 AM, Miriam English m...@miriam-english.org wrote:

 Also, you might think this is pretty obvious, but it surprises me how many 
 people I've seen make this mistake, so I'll mention it anyway, just in 
 case... renaming a file with a different extension won't make it the right 
 kind of file. For instance renaming a jpeg file from blah.jpg to blah.bmp 
 doesn't make it a bmp file. It must be loaded into a graphics program like 
 Gimp then saved out as the new format.

 Cheers,

    - Miriam

 --
 If you don't have any failures then you're not trying hard enough.
 - Dr. Charles Elachi, director of NASA's Jet Propulsion Laboratory
 -
 Website: http://miriam-english.org
 Blogs:   http://miriam-e.dreamwidth.org
         http://miriam-e.livejournal.com

Re: [pygame] Help with pygame

[Brian Fisher]

There's no way that code matches that error... the code tries to load
car.jpeg, and the error is from a line that tried to load
images.BMP.

So what's the actual name of the image? If you're not sure, what do
you get when you type ls from a command prompt in the same directory
as the python script? Or maybe you can attach the image to your reply
for others to try your code with?

My guess at the problem is you have not tried the actual filename yet.
You need to load the image file by it's actual filename, spelled
exactly correctly. And since you are having the error on a mac, it
must also have the current capitalization.

On Fri, Dec 9, 2011 at 6:26 PM, Zack Baker zbaker1...@gmail.com wrote:
 Hi, i wrote this code
 CODE: SELECT ALLimport pygame
 car=pygame.image.load('car.jpeg') #i have tried car.png car.bmp and so on
 screen.blit(car, (50, 100))
 pygame.display.flip()


 but i get this error
 CODE: SELECT ALLTraceback (most recent call last):
   File /Users/zackbaker/Desktop/Cartest.py, line 2, in module
     car=pygame.image.load('images.BMP')
 error: File is not a Windows BMP file



 HUh?? I tried BMP and bmp as extensions but i keep getting this error. Any
 help would be greatly appreciated. Thanks
 Btw I'm running Mac osx lion

 -Zack

Re: [pygame] growing out of idle ide

[Brian Fisher]

I love Eclipse+PyDev, works great as a python editor and runner, plus
you can get eclipse bindings for whatever source control you use.

On Mon, Aug 15, 2011 at 1:50 AM, David Burton ncdave4l...@gmail.com wrote:
 Is anyone here using Eclipse+PyDev, or Eclipse+DLTK?
 Opinions, please?

 Dave

 On Mon, Aug 15, 2011 at 4:31 AM, David Burton ncdave4l...@gmail.com wrote:

 Downloaded DrPython only to discover that it depends on wxPython, and thus
 doesn't support Python 3.  Rats!
 Dave

 On Thu, Aug 11, 2011 at 9:49 PM, B W stabbingfin...@gmail.com wrote:

 Tried many, keep going back to DrPython. Its Qt layout is a bit nicer in
 Windows than Linux, though.

 Gumm

Re: Pygame for the Lion(pre). Re: [pygame] static linking SDL, SDL_image, SDL_mixer etc on OS X

[Brian Fisher]

I had heard that SDL's fullscreen crashes on Lion, have you experienced that
problem with pygame on your lion machine? Did you do some kind of workaround
for that?

On Sat, Jul 30, 2011 at 10:36 AM, René Dudfield ren...@gmail.com wrote:

 Hi,

 here's a test for pygame on Lion with the apple supplied python2.7.

 http://rene.f0o.com/~rene/stuff/pygame-1.9.2pre-py2.7-macosx10.7.mpkg.zip

 I don't think it'll work on anything but Lion and Snow Leopard (10.6 and
 10.7).

 I don't have a 10.5 machine to test with at the moment, so if anyone can
 confirm that it doesn't work that'd be swell.

 cheers,


 On Sat, Jul 30, 2011 at 7:44 AM, René Dudfield ren...@gmail.com wrote:

 Instead, I could try and put the SDL*.framework into the
 site-packages/pygame folder.  That would give the same benefits of making
 the install easier I think.  It would mean, not requiring root access to
 install pygame.

 cu.

Re: [pygame] Getting pygame import to work in pydev/eclipse, shows as error.

[Brian Fisher]

Are you sure pydev is running your script with the python 2.7 interpreter
you have installed?

what python interpreters are registered under
preferences-pydev-interpreter python? if you have multiple registered,
which is the default? (highest on list)

When you run the script are you doing run as-python run? if you use the
run configurations dialog, which python interpreter is selected in that
dialog?

On Thu, Jul 28, 2011 at 1:36 PM, Jake b ninmonk...@gmail.com wrote:

 In pydev/eclipse I can run a file using pygame. So it runs, but, (even for
 new projects)

 I get the errors: ( in the UI. it still runs, but autocompletion for pygame
 doesn't load. )

 import pygame

 unresolved import pygame

 from pygame.locals import *
 from pygame import Color, Rect, Surface

 unresolved import Color
 unresolved import Rect
 unresolved import Surface

 Pygame is installed to: C:\Python27\Lib\site-packages\pygame

 What am I missing?
 --
 Jake

Re: [pygame] Re: SDL 1.3 blit speed

[Brian Fisher]

If the layering is something that is consistent from one moment to the next,
and you really have an overdraw of 3x, you can pre-combine and cache the
visible parts, which could potentially make it take 1/3rd the speed (that's
your goal, right?)

On Tue, Jul 12, 2011 at 6:26 PM, Brian Brown bro...@gmail.com wrote:

 Yes, I'm only blitting the visible parts. It's the tile layering that
 causes 3x more blitting. (floor, carpet, and a possible wall for every
 tile.)
 Blitting the whole 300x300 map will take a very long time . . .

  . . .

 Okay so, will SDL 1.3 regular blitting be 3x faster?

 On Tue, Jul 12, 2011 at 11:52 AM, DR0ID dr...@bluewin.ch wrote:

 **
 On 12.07.2011 20:12, Brian Brown wrote:

 Thanks guys,
 I'm not using Pyopengl. (I found it a little too hard to use.)
 Pygame and SDL are working perfectly for me-- except-- I need faster
 blitting. That's all, I think.
 I've designed my game's graphics to simply rely on the blitting of many
 60x60 24-bit surfaces. (Approximately 300 to 500 blits per frame on a
 scrolling screen of 640x480 resolution. The game is tile based with an
 overlapping 3D illusion. The floor is drawn first, the mat second, and the
 characters and blocks sorted by distance from bottom of screen are last.
 Should look fantastic when graphics are finished and when the fps is
 higher.)

  If SDL 1.3 will blit basic 24-bit surfaces (with a single colorkey) 3x
 faster I think my game will work quite nicely.

  * I am using convert().
 * I'm *not* using per-pixel-alpha.
 * I even blit the freshly-loaded-surfaces onto a new surface to be sure
 the surfaces haven't inherited any unnecessary data from the png file. (I
 found this to significantly increase speed.)
 * The whole screen is scrolling so I use pygame.display.flip().
 * I think I'm using 24-bit images.
 * I need a high refresh rate for high speed chases with the local wildlife
 . . . (bear, tigers, unicorns etc.)
 * I'll have to try using surface.fill() instead of blitting . . .
 * My program's code is already running at a nice speed.

  Sounds like a great idea to continue programming with pygame and then
 later speed things up, but--

  It's just a little harder to program with slow graphics --My personal
 policy for low stress programming is to reward myself after every day of
 hard work by playing the game, and it's not the most fun in slow motion.

  Is there a way to convert 24-bit pygame surfaces to 8 bit RLE just
 to temporarily speed things up for testing?
 Thanks for the great advice guys.

 On Tue, Jul 12, 2011 at 6:14 AM, René Dudfield ren...@gmail.com wrote:

 On Tue, Jul 12, 2011 at 1:59 PM, Sean Wolfe ether@gmail.com wrote:

 Dude this was a really good answer. Respect


   Indeed, good answer.

 Also, are you using fast rendering techniques?

- Using 8 bit RLE encoded surfaces for the low colour depth images
- avoiding per pixel alpha surfaces.
- using convert() appropriately (except not on those low colour
surfaces).
- using fill() to fill in colours instead of blit.
- using LayeredDirty sprite group, and DirtySprite sprites to do
dirty rectangle updates.
- updating parts of the screen at the lowest refresh rate they need.
eg, displaying fps, may only need be done once every 10 frames.
- profiled your game ( to see which parts are slow.)
http://pygame.org/wiki/Profiling



 SDL 1.3 is faster with opengl/direct3d surfaces.  But it's _still not
 finished.


 cu.




 Hi

 Just a side note: If you have a scrolling world then blit only the visible
 parts, that will give you a performance boost (not sure if you do this
 already).

 ~DR0ID

Re: [pygame] Re: SDL 1.3 blit speed

[Brian Fisher]

One particular technique for scrolling multi-layer backgrounds (that don't
have parallax or animation anyways) is to have one large surface which is
big enough to cover the screen, and to treat it as a wrapping buffer (so you
do 4 blits to the screen from the surface in order to get the parts of the
buffer as they wrap around the edges - hope that makes sense). Then as the
background scrolls, you render in the newly visible parts into the buffer
from your layers (using source clipping to get just the newly visible
portion rendering on top of the newly offscreen part)

It can have dramatic speed improvements compared to redrawing all layers
every time because when you have a lot of layers with transparency, all that
transparency gets flattened in the cache. The blit to the screen from the
buffer is just a copy, it doesn't spend time on color-key or alpha blending
(this technique is actually great for when you want alpha blended layers,
btw, which can look better than color key).  Also, you'll have fewer blit
calls as well, which means fewer native code crossings from python which are
moderately slow.

...while animation and layers on top of animating characters don't work
great with this technique, you can actually combine a dirty rect system with
the wrapping buffer to address that, so as long as the use of the animation
and the layers on top are sparsely used, you still get all the savings of
not compositing the parts of the screen not affected by animation every
frame.


On Tue, Jul 12, 2011 at 7:02 PM, Brian Brown bro...@gmail.com wrote:

 That might work . . .  : )


 On Tue, Jul 12, 2011 at 6:58 PM, Brian Fisher 
 br...@hamsterrepublic.comwrote:

 If the layering is something that is consistent from one moment to the
 next, and you really have an overdraw of 3x, you can pre-combine and cache
 the visible parts, which could potentially make it take 1/3rd the speed
 (that's your goal, right?)


 On Tue, Jul 12, 2011 at 6:26 PM, Brian Brown bro...@gmail.com wrote:

 Yes, I'm only blitting the visible parts. It's the tile layering that
 causes 3x more blitting. (floor, carpet, and a possible wall for every
 tile.)
 Blitting the whole 300x300 map will take a very long time . . .

  . . .

 Okay so, will SDL 1.3 regular blitting be 3x faster?

 On Tue, Jul 12, 2011 at 11:52 AM, DR0ID dr...@bluewin.ch wrote:

 **
 On 12.07.2011 20:12, Brian Brown wrote:

 Thanks guys,
 I'm not using Pyopengl. (I found it a little too hard to use.)
 Pygame and SDL are working perfectly for me-- except-- I need faster
 blitting. That's all, I think.
 I've designed my game's graphics to simply rely on the blitting of many
 60x60 24-bit surfaces. (Approximately 300 to 500 blits per frame on a
 scrolling screen of 640x480 resolution. The game is tile based with an
 overlapping 3D illusion. The floor is drawn first, the mat second, and 
 the
 characters and blocks sorted by distance from bottom of screen are last.
 Should look fantastic when graphics are finished and when the fps is
 higher.)

  If SDL 1.3 will blit basic 24-bit surfaces (with a single colorkey) 3x
 faster I think my game will work quite nicely.

  * I am using convert().
 * I'm *not* using per-pixel-alpha.
 * I even blit the freshly-loaded-surfaces onto a new surface to be sure
 the surfaces haven't inherited any unnecessary data from the png file. (I
 found this to significantly increase speed.)
 * The whole screen is scrolling so I use pygame.display.flip().
 * I think I'm using 24-bit images.
 * I need a high refresh rate for high speed chases with the local
 wildlife . . . (bear, tigers, unicorns etc.)
 * I'll have to try using surface.fill() instead of blitting . . .
 * My program's code is already running at a nice speed.

  Sounds like a great idea to continue programming with pygame and then
 later speed things up, but--

  It's just a little harder to program with slow graphics --My personal
 policy for low stress programming is to reward myself after every day of
 hard work by playing the game, and it's not the most fun in slow motion.

  Is there a way to convert 24-bit pygame surfaces to 8 bit RLE just
 to temporarily speed things up for testing?
 Thanks for the great advice guys.

 On Tue, Jul 12, 2011 at 6:14 AM, René Dudfield ren...@gmail.comwrote:

 On Tue, Jul 12, 2011 at 1:59 PM, Sean Wolfe ether@gmail.comwrote:

 Dude this was a really good answer. Respect


   Indeed, good answer.

 Also, are you using fast rendering techniques?

- Using 8 bit RLE encoded surfaces for the low colour depth images
- avoiding per pixel alpha surfaces.
- using convert() appropriately (except not on those low colour
surfaces).
- using fill() to fill in colours instead of blit.
- using LayeredDirty sprite group, and DirtySprite sprites to do
dirty rectangle updates.
- updating parts of the screen at the lowest refresh rate they
need.  eg, displaying fps, may only need be done once every 10 frames.
- profiled your

Re: [pygame] Re: SDL 1.3 blit speed

[Brian Fisher]

You should continue programming with whatever system allows you to continue
programming with your game. Productivity of making your game should be your
primary metric here at this time, far above all other concerns.

If pygame has some obstacle now that's preventing you from moving forward
with your game, and you know of an alternative that would be more productive
in getting you to your goals, you should go ahead and switch now. If their
is no obstacle to moving forward though, and pygame is the most efficient
way for *you* at this time, then you should not switch or worry about future
concerns now. Usually future concerns get easier to resolve as they get
closer to the present.

To explain a little more why I say this - the cost of reworking a playable
game to use some different backend for it's rendering/input/audio/etc. is
usually very very small compared to the cost of making and finishing a
game.Also, swapping out backends is boring and somewhat tedious work, which
is easy to be motivated to do for a mostly complete game you really like,
and is very hard to find the energy to do for a game that is early on in
development, or still much in flux. Finally, it's always possible to have a
pygame compatibility layer for anything you'd replace pygame with -
meaning you could make a module named pygame that looked like pygame but ran
something else underneath - so you could potentially do most of the work to
change your game off pygame that way (with some small adjustment for the
stuff where that isn't sensible), and the size of that work is largely a
function of pygame itself, not of your game, so the work to switch doesn't
get any bigger by putting a planned switch off.

so I'd turn the question on you - is pygame with it's SDL roots working for
you?

---
P.S. As far as your performance question of SDL 1.3 being 3x faster - it
depends on your situation, and the answer may not even matter to you. SDL
1.3 would have much better hardware acceleration backing, which could easily
be 3x faster for rendering/drawing, but it would most likely be different
enough in terms of behavior where you'd have to do some reworking to your
code to see that benefit. If you were using OpenGL with pygame now, or using
pygame's HW accelerated blits exclusively, you may not see that rendering
benefit. Finally, if your bottlenecks aren't the stuff that SDL 1.3 would
make faster, it's improvements wouldn't matter to your game anyways.


On Mon, Jul 11, 2011 at 4:41 PM, Brian Brown bro...@gmail.com wrote:

 I've been working solo on a large game for the past two years, and I need
 to know if I should continue programming with Pygame and SDL.


 On Mon, Jul 11, 2011 at 4:32 PM, Brian Brown bro...@gmail.com wrote:

 Hi pygame users, will SDL 1.3 graphics be at least 3x faster than the
 current SDL graphics?
 Thanks.

Re: [pygame] FULLSCREEN or ~FULLSCREEN?

[Brian Fisher]

There's no simple rule on the relative performance between windowed and
fullscreen, because it depends what you mean by fullscreen, and what the
size of the app's window is relative to the desktop.

fullscreen can be done a few different ways:
A) changing the output resolution to the desired size, and grabbing
exclusive video access
B) changing the output resolution to the desired size, and just making the
window fill the whole screen
C) leaving the desktop resolution as is, and scaling the window up to
whatever the desktop is

In terms of performance, A is usually the fastest, B is also usually fast,
but can be slightly slower if other apps are doing things, and C can be
*much* slower than a windowed app (since it can end up pushing dramatically
more pixels). A and B can also change the color depth to what the app likes
best (16 vs. 24. vs 32), which usually doesn't matter these days, but can
have a significant performance impact, if your bottleneck is fill rate on
rendering to the back buffer.

Providing you don't have any bit-depth problems, a windowed app can perform
exactly as well as B, if it is close to the same size as the screen (should
make sense, as if it's exactly the same size as the screen, and has no
frame, it *is* the same as B), but as the surrounding desktop gets bigger,
the video card has to deal with those surrounding pixels in addition to your
windowed app.


One generalization you can make is that fullscreen of type A  B (changing
the resolution) has significant performance benefits on big screens, and not
really on smaller screens - however like you said fullscreen can cause
stability problems.

On windows and mac, pygame's normal fullscreen is A, and can be susceptible
to the same debug and crash problems with a fullscreen app locking up your
system that you describe on Linux. On mac in particular, type A (exclusive
fullscreen mode) actually blocks alt-tab as well, which means a hung or
unresponsive app can hang up the system as well, which sucks.


On Mon, Jul 4, 2011 at 12:21 PM, James Mazer james.ma...@yale.edu wrote:

 I've always been under the impression pygame+GL performance was
 substantially better when running with the FULLSCREEN flag
 set. However, recently, I started playing around with NOFRAME windows
 fit to the monitor size and found no big performance hit.

 Is this generally the experience of most people?  Is it generally safe
 with modern video cards to assume that windowed  fullscreen modes
 give you similar to performance levels for pygame+GL? This is for an
 app that uses mostly GL on top of pygame and runs with
 __GL_SYNC_TO_VBLANK set.

 Under linux, fullscreen debugging can be dangerous (it's too easy for
 a bug to lock up the machine requiring a reboot/xserver-restart), so it
 would be nice to not use it -- my app has a scripting language, so
 even with a bug-free production version a user can lock up the
 screen, so just using windowed mode for testing's not sufficient..

 Thanks,
 /jamie

 --
 James Mazer
 Department of Neurobiology
 Yale School of Medicine
 phone: 203-737-5853
 fax: 203-785-5263

Re: [pygame] deiconify method?

[Brian Fisher]

You're not missing anything obvious. There is no method to de-iconify,
because the underlying SDL library had no method to de-iconify.

I think the reason for that may be that there weren't programmatic
de-iconify methods on all platforms - the operating system window managers
usually don't want apps to be able to activate themselves and steal focus,
because it's generally considered bad form and annoying to the user if apps
do that.

You might be able to get this going with ctypes calling platform specific
stuff withyour window handle from the pygame.display.get_wm_info() function

I think windows has a deiconify call (ShowWindow with the correct SW_ flag),
but I think it only works if your window is already active, otherwise it
makes your bar blink blue or something - basically it just lets you politely
ask to be un-minimized - the user must be the one to actually un-minimize
the app.


On Fri, Jul 1, 2011 at 2:20 PM, James Mazer james.ma...@yale.edu wrote:

 I think I must be missing something obvious, but years of pygame
 programming and an hour of googling and I still can't figure out
 the inverse of pygame.display.iconify()...

 Is there a way to *deiconify* the pygame window without doing
 something ugly like calling quit() and set_mode() again?

 Thanks,
 /jamie

 --
 James Mazer
 Department of Neurobiology
 Yale School of Medicine
 phone: 203-737-5853
 fax: 203-785-5263

Re: [pygame] Re: PyGame Windows Key Behaviour

[Brian Fisher]

Hey Thomas,
   Ian Mallet's guess was correct and his solution will fix it.

You are moving the paddle based on key down events coming in, It looks like
you were counting on:
pygame.key.set_repeat(1,1)
to provide you with key down events every frame, but it doesn't work out
that way. I added prints to your code to see how the objects were moving,
and both paddles move by the same amount each time they move, but sometimes
the player paddle moves only 2 out of 3 frames (i.e. the player paddle moves
slower), hence the speed difference you were seeing.

What you want is to move the paddle when the appropriate key is held down -
namely when you've had a down event without an up event yet. key_pressed()
is a shortcut way to get that info.


On Mon, Jan 31, 2011 at 11:51 PM, Thomas pummer.tho...@gmail.com wrote:

 Hi there, thanks for fast responses

 @ Julian: Equal means exakt the same function with the same
 playerspeed variable - but under other conditions:
 it compares the position of the cpuplayer and the ball and rearranges
 the cpuplayer
 def move_player_a(ball_y):
global a_y
if a_y + 31  ball_y and a_y  0:
#up
a_y += seconds * playerspeed * -1
elif a_y + 31  ball_y and a_y + 95  360:
#down
a_y += seconds * playerspeed * 1

 i will have to take a look at framerates
 thanks for that hint

 @ Ian: i will also check pygame.key.get_pressed(). thx

 @ Brian: The complete code is here http://pastebin.com/ic44uvfU
 code was growing with my pygame knowledgement, so it isn't as nice as
 i would like to have it ;)
 but as additional info, pictures where used as background and as bars

Re: [pygame] PyGame Windows Key Behaviour

[Brian Fisher]

Hi Thomas,
  can you just post all the code? in particular what's missing is seeing how
the player ball and cpu are moved and how those things relate together.
There are definitely people on the list who could easily identify the cause
of your problem in an instant with that information.

Also, there a number of techniques that could be used that would prevent the
problem you are describing from ever occuring, and it would be easier to
communicate how such techniques work if we could see where you are coming
from now.

thanks

On Mon, Jan 31, 2011 at 3:22 AM, Thomas pummer.tho...@gmail.com wrote:

 Hi there!

 I've written a small demo pong game. There are 2 players, one is cpu
 controlled. To sync there movement i use

 clock = pygame.time.Clock()

 and in the while loop:

 milli = clock.tick()
 seconds = milli/1000.

 on checking the events it's:

 if event.type == KEYDOWN:
if event.key == K_DOWN:
b_y += seconds * playerspeed

 cpu changes his position with an equal function, until it reaches the
 height of the ball

 under winXP cpu and player can move with an equal speed
 under win7 the player is significant slower than the cpu. it seems
 that a player only can move 2/3 the distance than the cpu player is
 able to

 Do you have any hint's what can be done to fix this?

 with kind regards
 Thomas

Re: [pygame] Please help!

[Brian Fisher]

So it's just the old font problem then - the new twist to this is now pygame
causes a runtime exception when the default font is not present, where it
used to raise a python exception.

It's because of this change in pygame that py2exe isn't producing happy
stack traces anymore for this problem. That sucks, because the stack trace
in the .log file was very clear about the cause, when it would get produced.

You can repro this by renaming the pygame install's freesansbold.ttf, and
then just running the short font test case, without involving py2exe at all:
---
import pygame
pygame.init()
font = pygame.font.Font(None, 80)


that should raise a pygame exception.


On Mon, Nov 1, 2010 at 3:27 PM, Christoph Gohlke cgoh...@uci.edu wrote:

 Indeed, the solution to this and Zach's problem is to include the file
 freesansbold.ttf in the pygame folder in the dist\library.zip file. For
 the record, the crash also occurred with the 32 bit msvc9 build. No
 *.exe.log is created.

 Christoph

Re: [pygame] Please help!

[Brian Fisher]

Here are some criticisms of the py2exe build script posted, for those who
care...


 shutil.copyfile('freesansbold.ttf', 'dist/freesansbold.ttf')


Aside from the fact this line doesn't actually help the default font problem
(it only helps if you explicitly construct fonts using freesansbold.ttf,
it does not help if you construct fonts from None), it's also a bad way to
do dependencies for your py2exe scripts, because it's out of band of the
rest of the build process, which means if it fails, then the rest of the
py2exe build process still succeeds, and it looks like things worked. The
right way to add assets like this is the data_files option to py2exe,
which copies stuff to the dist directory, and fails the process if the file
doesn't exist, and looks like it failed.


setup(
 windows=[start.py],


You don't need to use such a generic boring name for your main script there
- the instructions said rename netrek-client-pygame to start.py - instead
you should just name the starting file for py2exe, so:

  windows=[netrek-client-pygame]


import py2exe, pygame


importing pygame from your build script is not needed or useful. py2exe
figures out the dependencies.



 data_files = [('images',

 ['C:\\Users\\Administrator\\Desktop\\python\\netrek-client-pygame-0.6\\images\\activity-stop.png',

 You shouldn't use absolute source paths in your data files, relative paths
from your build script will do

Re: [pygame] Re: [Py2exe-users] Error with pygame

[Brian Fisher]

This has nothing to do with the pygame default font  py2exe. it's a 32-bit
vs. 64-bit problem, python-2.6.amd64.msi installed a 64-bit python, and
pygame-1.9.1.win32-py2.6.msi installed a 32-bit pygame, and you can't mix 32
and 64 bit binaries in one program.

Also, 32-bit bit binaries run on 64-bit systems, but 64-bit binaries only
runs on 64-bit windows. So if you are py2exe'ing, you probably want to go
all 32-bit anyways, cause then what you build will work on both 32 and
64-bit user systems, while If you did do a 64-bit binary, it would only work
for other 64-bit users.

Also, Py2exe is involved now, but otherwise this is the same as the problem
that was already asked by Zachary Uram and answered by Christoph Gohlke on
the pygame mailing list 2 days ago.

On Sat, Oct 30, 2010 at 2:30 AM, Thadeus Burgess thade...@thadeusb.comwrote:

 Try

 http://thadeusb.com/weblog/2009/4/15/pygame_font_and_py2exe

 --
 Thadeus




 On Thu, Oct 28, 2010 at 6:23 PM, Zachary Uram net...@gmail.com wrote:

 Trying to build a pygame app and running into an error.

 I have installed: python-2.6.amd64.msi, pygame-1.9.1.win32-py2.6.msi,
 and py2exe-0.6.9.win64-py2.6.amd64.exe
 Running Windows 7 Ultimate (x64)

 Here is my setup program name pygame2exe.py:

 ##
 from distutils.core import setup
 import py2exe, pygame
 import glob, shutil

 setup(windows=[__init__.py],
 name='Netrek Pygame',
 version='0.3.1',
 description='Netrek Pygame Client',
 author='James Cameron',
 author_email='',
 url='www.netrek.org',

 py_modules=['__init__','cache','cap','client','constants','mercenary','meta','mis','motd','options','rcd','repair','test-cairo','test-keys','util']
 )

 shutil.copytree('data', 'dist/data')
 shutil.copyfile('freesansbold.ttf', 'dist/freesansbold.ttf')
 ##

 I've never done this before so I'd like some feeback. __init__.py is
 the main program file and the other python files are cache.py, cap.py,
 etc. so I listed them all under py_modules= was that correct?

 Anyways here is what happens when I try to build:

 Microsoft Windows [Version 6.1.7600]
 Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

 C:\Users\Administratorcd
 C:\Users\Administrator\Desktop\python\netrek-client-py
 game-0.6\netrek

 C:\Users\Administrator\Desktop\python\netrek-client-pygame-0.6\netrekdir
  Volume in drive C has no label.
  Volume Serial Number is 26DD-5AA7

  Directory of
 C:\Users\Administrator\Desktop\python\netrek-client-pygame-0.6\net
 rek

 10/28/2010  06:25 PMDIR  .
 10/28/2010  06:25 PMDIR  ..
 03/27/2010  10:55 PM 6,101 cache.py
 05/17/2009  09:56 PM 3,587 cap.py
 03/27/2010  11:21 PM10,585 client.py
 10/12/2010  03:11 AM 6,691 constants.py
 06/30/2008  10:39 PM98,600 freesansbold.ttf
 03/27/2010  06:43 AM 2,777 mercenary.py
 12/15/2009  02:49 AM 4,423 meta.py
 09/19/2010  07:57 AM 1,046 mis.py
 09/20/2010  09:33 PM   692 motd.py
 02/27/2010  07:18 PM 3,414 options.py
 06/30/2008  10:39 PM 1,078 pygame.ico
 10/28/2010  06:25 PM   514 pygame2exe.py
 10/28/2010  06:21 PM 5,647 pygame2exe2.py
 03/31/2009  04:52 AM 7,690 rcd.py
 07/07/2008  03:11 AM   465 repair.py
 07/09/2008  03:34 AM   713 test-cairo.py
 03/24/2010  10:39 PM   374 test-keys.py
 02/23/2010  09:36 PM 1,229 util.py
 10/12/2010  03:16 AM   180,674 __init__.py
  19 File(s)336,300 bytes
   2 Dir(s)  10,690,691,072 bytes free


 C:\Users\Administrator\Desktop\python\netrek-client-pygame-0.6\netrekpython
 Python 2.6 (r26:66721, Oct  2 2008, 11:06:43) [MSC v.1500 64 bit (AMD64)]
 on win
 32
 Type help, copyright, credits or license for more information.
  (exit)
 Use exit() or Ctrl-Z plus Return to exit
  exit()


 C:\Users\Administrator\Desktop\python\netrek-client-pygame-0.6\netrekpython
 pygame2exe.py py2exe
 C:\Python26\lib\site-packages\py2exe\build_exe.py:16:
 DeprecationWarning: the sets module is deprecated
  import sets
 Traceback (most recent call last):
  File pygame2exe.py, line 2, in module
import py2exe, pygame
  File C:\Python26\lib\site-packages\pygame\__init__.py, line 95, in
 module
from pygame.base import *
 ImportError: DLL load failed: %1 is not a valid Win32 application.

 Any help would be greatly appreciated.

 Zach

  http://www.fidei.org 


 --
 Nokia and ATT present the 2010 Calling All Innovators-North America
 contest
 Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
 $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
 marketing
 Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
 http://p.sf.net/sfu/nokia-dev2dev
 

Re: [pygame] py2exe, MSVCR71.dll and InnoSetup

[Brian Fisher]

There is no real problem here - this old concern of illegally distributing
MSVCR71.dll with python has always been fear, uncertainty and doubt with no
real foundation for concern.

If you are distributing MSVCR71.dll along with python (which you are), the
license that allows the python developers to distribute it with python
(which they do) allows you to then redistribute python and msvcr71.dll along
with it, provided you comply with the license terms - which mostly amounts
to you distributing your stuff with a license which is compatible with the
original msvcr71.dll terms with respect to that dll, which means you're not
giving your end-users any rights to distribute it independent of your
product.

Basically, for the microsoft redistributable license to actually be useful
to developers, it had to allow developers to give their product including
the redistributable to others, and then allow those other people to
redistribute the product. This is essential for being able to sell stuff in
a store, and it's essential for being able to make a library or engine type
of product. This happens with the microsoft c-run time dlls in hundreds and
hundreds of products all over the world, and microsoft never sued any of
them. Your case is not likely to be any different.

A better question is probably what do I have to avoid to comply with the
msvcr71.dll redistributable license, and on that side, the only thing you
clearly can't do, is provide license terms that imply people can do whatever
they want with msvcr71.dll, so don't do that. If you are the worrying type
though, then dig up the original redistributable license from msvcr71.dll,
and include that in your product. If you are the worrying type and the
skeptical type, then also download the free msvc toolkit 2003 or buy visual
studio 2003, so that now microsoft is licensing the dll to you as a
redistributable, and then you can do what you want. If that's not good
enough for you, then have fun wasting your time with installer gymnastics.


On Mon, Oct 25, 2010 at 12:16 PM, Johannes Charra johannes.cha...@gmx.dewrote:


 Hi,

 How do I distribute my Python game to Windows users without illegally
 distributing the MSVCR71.dll?

 As far as my research went, one might e.g. build an InnoSetup installer
 which will include the installation of the MS Visual C++ 2005
 Redistributable package. I tried that, but my game still won't run because
 the DLL cannot be found.

 I'd be grateful for any comments on how you're solving the general
 MSVCR71.dll problem.

 Furthermore, if anyone is going the same way as I do (InnoSetup + MS
 package installation), maybe he or she can give me a hint on how to make
 InnoSetup copy the DLL to my app directory after installing the redist
 package.

 Best regards,
 Johannes

Re: [pygame] frame independant movement

[Brian Fisher]

That approach is perfectly fine with linear movement - because the linear
calculations aren't affected significantly by how large dt is (or put
another way: x += vx*2 is nearly identical to x += vx*1, x += vx*1 on your
computer)

However, with any nonlinear physics (like say, gravity's relationship to
position, or an accelerating object)  or with discrete actions that happen
once per frame (like say the artificial intelligence for an enemy that
decides what to do once every frame), then your game behavior can change
quite significantly depending on what values of dt you get.

---
For example, lets say you do gravity like this:
vy = vy + gravity*dt
y = y + vy*dt

with a dt of 2, from vy = 0, y = 0, the result is:
vy = vy + gravity*2 = gravity*2
y = y + (gravity*2)*2 = gravity*4

however if you get a dt of 1 twice, from the same starting point, the result
is:
vy = vy + gravity*1 = gravity
y = y + (gravity)*1 = gravity
...
vy = vy + gravity*1 = gravity + gravity = gravity*2
y = y + (gravity*2)*1 = gravity + gravity*2 = gravity*3
---

so you've only moved 3/4 of the distance (3 vs. 4 gravitys) down with a
frame rate that is twice as fast, even though you are parameterizing
everything on dt. Note the acceleration component (which is linear with
time) is consistent and accurate with both timestep sizes.

So you asked what else do you need? well the answer is if you want
consistent non-linear physics (like say you want the players to jump the
same all the time), then the else you need is fixed size timesteps for
your physical simulation.


On Fri, Aug 27, 2010 at 8:27 AM, Christopher Night
cosmologi...@gmail.comwrote:

 Here's what I always do:

 dt = clock.tick() * 0.001
 x += vx * dt
 y += vy * dt

 And all the sprites have a think(dt) method that updates them as if dt
 seconds have passed. What else do you need?

 -Christopher


 On Fri, Aug 27, 2010 at 11:19 AM, James Paige b...@hamsterrepublic.comwrote:

 On Fri, Aug 27, 2010 at 10:59:09AM -0400, Kris Schnee wrote:
  On 2010.8.27 10:36 AM, B W wrote:
  Howdy,
 
  Reviving this old thread. The comments by Patrick and Brian really
  intrigued me, so I pursued the topic. Found a few interesting articles
  and one great article. My study has resulted in a recipe for those of
 us
  continually nagged by the question, how can I get constant game speed
  independent of frame rate?. The demo requires Pygame, but the clock
  module only requires Python.
 
  Isn't it simply a matter of creating a Pygame Clock object and calling
  clock.tick() to delay until the appropriate time to maintain some max
  framerate?

 That only caps a max framerate. What Gumm is talking about is when your
 framerate and your game simulation rate can be adjusted independantly

 ---
 James Paige

Re: [pygame] frame independant movement

[Brian Fisher]

On Fri, Aug 27, 2010 at 9:10 AM, Christopher Night
cosmologi...@gmail.comwrote:

 Sure. But of course, it's extremely easy to do constant-acceleration motion
 as well:

 y += vy * dt + 0.5 * g * dt ** 2
 vy += g * dt

 Sure, that explicit integration technique works fine if you can write an
explicit integration function - I've used that same technique even with
fixed time-steps because it's more accurate. But now how about if you have
acceleration and friction for a car driving on a surface - can you write a
single dt based function for that? now how about something that is
accelerating away with a spring on it? or maybe something falling while
accelerating off axis with a spring attached? It very quickly gets beyond
your ability to write such functions if you try and do really interesting
stuff.

While consistent timesteps on the other hand, make it so the thing is always
consistent and repeatable, even with simple update functions. Don't you want
your game to behave the same regardless of frame rate? If you do, then fixed
timestep simulation loops is a simple elegant widely used solution.

Re: [pygame] 127.5

[Brian Fisher]

I don't see why pygame should be involved at all in your texture creation.

python's array module should let you create an array of floats, and
glTexImage2d should support GL_FLOAT for the data type argument. Does that
work?


On Fri, Jul 30, 2010 at 7:10 AM, Ian Mallett geometr...@gmail.com wrote:

 Hi,

 Intro:
 So, I'm working on computational fluid dynamics, and I need to initialize a
 velocity texture, which stores a vector field in an image.  Velocity vectors
 can have a range of values; each component could be either positive and
 negative.  The X component goes in the red channel, the Y in the green, and
 so on.  To store the values, the image maps the range [0,255] to
 [-1.0,1.0].  I need to have a surface set to precisely velocity = 0 on all
 channels.

 The problem:
 Because of this, I need a surface filled with the color 127.5.  Obviously,
 more than 8 bits per channel are required.  To update the texture, I'm using
 GL_RGBA32F_ARB, which allocates 32 bits per channel.  Unfortunately, the
 base image created by PyGame has a value of 127 ≈ -0.00196 velocity.  In
 practice, this leads to drift in the simulation.  Can something be done to
 send a 32 bit per channel surface filled with 127.5 values to the OpenGL?

 Thanks,
 Ian

Re: [pygame] 127.5

[Brian Fisher]

Another ghetto solution is to not map to 0 to 255. map to 0 to 254, and then
127 is your 0

On Fri, Jul 30, 2010 at 7:10 AM, Ian Mallett geometr...@gmail.com wrote:

 Hi,

 Intro:
 So, I'm working on computational fluid dynamics, and I need to initialize a
 velocity texture, which stores a vector field in an image.  Velocity vectors
 can have a range of values; each component could be either positive and
 negative.  The X component goes in the red channel, the Y in the green, and
 so on.  To store the values, the image maps the range [0,255] to
 [-1.0,1.0].  I need to have a surface set to precisely velocity = 0 on all
 channels.

 The problem:
 Because of this, I need a surface filled with the color 127.5.  Obviously,
 more than 8 bits per channel are required.  To update the texture, I'm using
 GL_RGBA32F_ARB, which allocates 32 bits per channel.  Unfortunately, the
 base image created by PyGame has a value of 127 ≈ -0.00196 velocity.  In
 practice, this leads to drift in the simulation.  Can something be done to
 send a 32 bit per channel surface filled with 127.5 values to the OpenGL?

 Thanks,
 Ian

Re: [pygame] The Spectacularly Adequate Build Page is stuck at revision 2814

[Brian Fisher]

Yeah, basically lost my cron in operating system updates  didn't know.

thanks for the heads up, I'll get them going again when I get a chance


On Thu, Jul 22, 2010 at 12:16 PM, Lenard Lindstrom le...@telus.net wrote:

 Hi,

 Brian Fisher, the build page hasn't updated since May 28. Is there a
 problem?

 Lenard Lindstrom

Re: [pygame] Problem with mouse going back to the center of the screen

[Brian Fisher]

The only time I know of where that maybe is supposed to happen, is when the
mouse is both grabbed by the window, and invisible. SDL takes that to mean
you want virtual input mode, where the mouse is moved back to the center
so you can keep getting relative mouse movement infinitely in all
directions, so it can behave like a trackball. This is documented here:
http://www.pygame.org/docs/ref/mouse.html

If this is your case. and relative mouse movement is fine, try using the
mouse event's .rel member instead of it's .pos member, or using
pygame.mouse.get_rel instead of .get_pos

if this is your case, but virtual input is not desireable, reconsider
whether pygame.event.set_grab(true) and pygame.mouse.set_visible(false) are
actually functions you want to call.

if this is not your case, it's a bug, and a minimal sample to reproduce
would be appreciated.

On Tue, Jul 20, 2010 at 2:32 PM, SurferIX olivier.p...@gmail.com wrote:

 Hi!

 I've got a problem with the mouse: it's going back to the center of
 the screen!
 I don't know where it could come from because it does this only in
 full screen.
 It's exactly the same problem with the game Enigma.

 It seems there's a problem either with SDL or with my computer. But if
 it's with my computer why only in full screen?
 Did you have any trouble like that?
 Thanks a lot!

Re: [pygame] are individual midi instruments sounds copyrighted

[Brian Fisher]

Well the midi version of your composition is absolutely your own and no-one
else's, and there are other ways to render it to wav/ogg/whatever besides
the line out of your keyboard, which don't restrict your ability to
distribute and sell your product, so you always have options. If you have
access to a mac, for instance, garageband instrument samples give a
royalty-free license to use to make renderings of midi music.

That being said, I would be *amazed* if rendering down your own music wasn't
an authorized use of the yamaha keyboard. That copyright notice you have
there isn't clear at all at what is and isn't authorized, it just says that
personal use is always OK, and that's basically a meaningless statement
because what they say is already given by copyright law. I think bottom line
is you are in a grey area with that keyboard unless you find something more
about what is exactly authorized or licensed. You could try emailing Yamaha
support if you really cared, but if I were you, I would assume it's totally
fine and just use my own rendered music however I like, cause it would be
ridiculous and stupid if yamaha ever tried to claim infringement in a case
like yours, bad for their business. The reality of copyright and IP law is
that the only thing that is actually in violation is what is enforced by the
copyright holder.


On Mon, Jul 19, 2010 at 1:14 PM, Brian Brown bro...@gmail.com wrote:

 I think I have an idea of what to do now.
 I think I will just keep making my music and if I find it is unusable
 for my game, I should just use it personally.
 Thanks everybody for all your help. I appreciate it.
 Matt

Re: [pygame] Referencing instances by memory address

[Brian Fisher]

You still haven't explained why referencing things by id is better for your
needs than actually just referencing the object. Python's weakref module is
perfect for this kind of thing, you can make a reference to an object that
is fine for self-references (won't create cycles) and even cooler, the
reference will become invalid when the object is deleted, so you'll never
have the problem where the id somebody has stored has become invalid (or
even worse, now points to a new object) because the original object was
deleted and the guy with the id reference didn't know.

so what I'm saying is like instead of doing stuff like this:
self.other_bullet_id = id(other_bullet)
and this:
other_bullet = global_dictionary[self.other_bullet_id]
other_bullet.do_stuff()

you'd do stuff like this:
self.other_bullet_ref = weakref.ref(other_bullet)
and this:
other_bullet = self.other_bullet_ref()
other_bullet.do_stuff()

and the cool part about that, is that other_bullet will be None, if the
bullet object was deleted, when using weakrefs, so you can catch and handle
that case just fine.

While with id's, the id may have been reused and now refer to the wrong
object, or will just simply be an invalid id when looking it up in the
dictionary. Also, you'll never be sure if you were completely diligent in
maintaining that dictionary of id's - so you won't know if the id is now
invalid cause the bullet was deleted, or if you had a bug in the code that
maintains the dict.



basically, by trying to reference things by id, you've made a system that
operates like using C/C++ pointers, with most (but not all) of the problems
of such a system. Meanwhile, python gives you a ref-counted garbage
collected system with weak references that solves all those problems, and is
most likely much more efficient than your pointer re-implementation.



so my question is the same - why are you doing this id system? What problems
does it solve for you that weak references wouldn't?


On Mon, Jul 12, 2010 at 4:09 PM, 音本四 onp...@gmail.com wrote:


 (I ask because it seems like doing what you are doing would be a big ol'
 error prone hassle and waste of your time compared to other more commonly
 used techniques in python, but I can't figure out exactly what problem that
 dictionary approach was originally conceived of as a solution for)


 Simple: I needed instances to be able to reference themselves, and I didn't
 feel like generating my own unique IDs and passing them on as a parameter.
 :)
 Why are you storing stuff by id() in a dictionary in the first place? When
 would you want to look something up by it's id() when you wouldn't want just
 to have a reference (possible a weakref) to the object itself?

Re: [pygame] Installing pygame on Mac OS X Snow Leopard: How do I tell the config.py script where libsdl is?

[Brian Fisher]

Install SDL from the source yourself? None of the instructions ever given
say that. They all say install the official prebuilt SDL using the .dmg
files provided libsdl.org. Did you build SDL yourself from source, or did
you install the official SDL disk images?


On Mon, May 17, 2010 at 5:49 PM, jergason jerga...@gmail.com wrote:

 I am trying to install pygame on Mac OS X Snow Leopard with python
 3.1. I have been loosely following the guide found here:
 http://programming.itcarlow.ie/PyGameInstall.pdf linked to from the
 pygame website. It basically tells you to install SDL from the source
 yourself, and use macports to install libjpeg, libsmpeg, and PORTMIDI.
 I get to the final steps where I call the pygame config.py script
 here:
 $ python3  config.py
 Only to notice that none of the SDL libs can be located by the config
 script.

 The output from config.py looks like this:
 Using Darwin configuration...


 Backup existing Setup file [Y/n]:n
 Hunting dependencies...
 Framework SDL not found
 Framework SDL_ttf not found
 Framework SDL_image not found
 Framework SDL_mixer not found
 Framework smpeg not found
 PNG : found
 JPEG: found
 SCRAP   : not found
 PORTMIDI: found
 Framework CoreMidi found

 libSDL, libSDL_mixer, libSDL_tff, libSDL_image are all in /usr/local/
 lib. How do I tell the config script where my SDL libraries are
 located?

Re: [pygame] Installing pygame on Mac OS X Snow Leopard: How do I tell the config.py script where libsdl is?

[Brian Fisher]

The .dmg files are installers, that put the sdl libraries in specific known
places. The ones you build yourself would be found just fine if they were in
those known places. But it's probably better to use the prebuilts anyways,
cause it's better to use whatever configuration stuff they build with so
that your SDL matches what other people use as much as practical.


On Mon, May 17, 2010 at 7:20 PM, Jamison Dance jerga...@gmail.com wrote:

 Yep, that was my problem. Thank you very much for your help. What is the
 difference between the libraries built from the source and the Mac OS X
 binaries, out of curiosity?


 On Mon, May 17, 2010 at 7:49 PM, Brian Fisher 
 br...@hamsterrepublic.comwrote:

 Install SDL from the source yourself? None of the instructions ever given
 say that. They all say install the official prebuilt SDL using the .dmg
 files provided libsdl.org. Did you build SDL yourself from source, or did
 you install the official SDL disk images?



 On Mon, May 17, 2010 at 5:49 PM, jergason jerga...@gmail.com wrote:

 I am trying to install pygame on Mac OS X Snow Leopard with python
 3.1. I have been loosely following the guide found here:
 http://programming.itcarlow.ie/PyGameInstall.pdf linked to from the
 pygame website. It basically tells you to install SDL from the source
 yourself, and use macports to install libjpeg, libsmpeg, and PORTMIDI.
 I get to the final steps where I call the pygame config.py script
 here:
 $ python3  config.py
 Only to notice that none of the SDL libs can be located by the config
 script.

 The output from config.py looks like this:
 Using Darwin configuration...


 Backup existing Setup file [Y/n]:n
 Hunting dependencies...
 Framework SDL not found
 Framework SDL_ttf not found
 Framework SDL_image not found
 Framework SDL_mixer not found
 Framework smpeg not found
 PNG : found
 JPEG: found
 SCRAP   : not found
 PORTMIDI: found
 Framework CoreMidi found

 libSDL, libSDL_mixer, libSDL_tff, libSDL_image are all in /usr/local/
 lib. How do I tell the config script where my SDL libraries are
 located?

Re: [pygame] sprite module optimizations have been uploaded

[Brian Fisher]

Thanks Casey. I was already installing the 10.4 sdk along with the rest of
xcode, the problem appears to have been that Snow Leopard defaults to gcc
4.2, which is not supported with the 10.4 sdk (gives float.h and stdarg.h
errors). I swaped the /usr/bin/gcc symlink to go to 4.0, so that error is
past.

On Sun, Apr 18, 2010 at 8:30 PM, Casey Duncan ca...@pandora.com wrote:

 The default xcode install omits the 10.4 stuff that is needed for building
 python extensions. You can fix it by doing a custom xcode install.

 -Casey

 On Apr 18, 2010, at 2:09 AM, Brian Fisher wrote:

  the PC stuff is building, but the mac building on the automated build
 machine got messed up by the latest xcode and/or snow leopard upgrade... It
 seems the 10.4 universal SDK is missing a bunch of headers or something like
 that... I haven't had time to figure it out yet.
 
  On Sat, Apr 17, 2010 at 12:35 PM, Jason M. Marshall j...@yahoo.com
 wrote:
  The revision number for the optimizations is 2793. It has not been built
 yet, but it will be built soon. You will be able to download it from the
 following webpage:
  http://thorbrian.com/pygame/builds.php
  Jason
 
  From: claudio canepa ccanep...@gmail.com
  To: pygame-users@seul.org
  Sent: Sat, April 17, 2010 1:08:10 PM
  Subject: Re: [pygame] sprite module optimizations have been uploaded
 
 
 
  On Sat, Apr 17, 2010 at 2:51 PM, Jason M. Marshall j...@yahoo.com
 wrote:
  I finished making optimizations to the sprite module. The new sprite.py
 has been uploaded to the Subversion repository. I am pleased to announce
 that on my Mac with Python 2.5, sprite_test.py now runs in 0.038 seconds
 rather than 0.076 seconds, and on my PC with Python 3.1, sprite_test.py now
 runs in 0.016 seconds rather than 0.031 seconds. If I have inadvertently
 broken your code or made it slower, let me know and I'll undo the
 optimization that doesn't work for you.
 
  Jason
 
 
  The automated build site will provide binaries for this revision?
 
  --
  claxo
 
 
 

Re: [pygame] sprite module optimizations have been uploaded

[Brian Fisher]

the PC stuff is building, but the mac building on the automated build
machine got messed up by the latest xcode and/or snow leopard upgrade... It
seems the 10.4 universal SDK is missing a bunch of headers or something like
that... I haven't had time to figure it out yet.

On Sat, Apr 17, 2010 at 12:35 PM, Jason M. Marshall j...@yahoo.com wrote:

 The revision number for the optimizations is 2793. It has not been built
 yet, but it will be built soon. You will be able to download it from the
 following webpage:
 http://thorbrian.com/pygame/builds.php
 Jason

  --
 *From:* claudio canepa ccanep...@gmail.com
 *To:* pygame-users@seul.org
 *Sent:* Sat, April 17, 2010 1:08:10 PM
 *Subject:* Re: [pygame] sprite module optimizations have been uploaded



 On Sat, Apr 17, 2010 at 2:51 PM, Jason M. Marshall j...@yahoo.com wrote:

  I finished making optimizations to the sprite module. The new sprite.pyhas 
 been uploaded to the Subversion repository. I am pleased to announce
 that on my Mac with Python 2.5, sprite_test.py now runs in 0.038 seconds
 rather than 0.076 seconds, and on my PC with Python 3.1, sprite_test.py now
 runs in 0.016 seconds rather than 0.031 seconds. If I have inadvertently
 broken your code or made it slower, let me know and I'll undo the
 optimization that doesn't work for you.

 Jason


 The automated build site will provide binaries for this revision?

 --
 claxo

Re: [pygame] Re: pygame and file object compatibility; slow.

[Brian Fisher]

What about the font loading segfaulting? Are you still getting that issue?
If so, what version of pygame are you using on what OS?


In case you are curious, the problem with reading from tar files as
file-like objects is that with tar files, seeking to a certain point in the
stream is expensive cause tar files don't have any index of the tar contents
(you have to read each files header and seek past it in the archive to
figure out what else is in there) so it has to re-read the tar file from the
start to move to a new place in the file. The pygame/SDL code that does the
loading doesn't know that, so it tries to seek around, expecting seeking to
be cheap. Note that compressed tar (gz, bzip2, etc.) makes the situation
much much worse - because once the tar stream is compressed, you can't seek
past files, now you have to read and decompress to figure out when you've
passed one archived file and found the next ones header. It's pretty much
hopeless to try and read your assets out of a compressed tar if you are
randomly accessing the asset files.

Zip files are much much better because they have a file index (zip files
compress files first, then archive those compressed files with an index),
the pygame loader may still be a bit slower on loading from compressed files
in zips, and if that becomes an issue, you could try reading the file
contents uncompressed out of the zip into a string, and then loading from a
StringIO:
http://docs.python.org/library/stringio.html

On Sun, Mar 28, 2010 at 1:50 AM, Maize vhxonl...@gmail.com wrote:

 After fussing with it for a few hours it seems to be a problem with
 either pygame or the tar file objects. The time it takes to extract
 the file into memory is around 0.003s or so. The problem occurs
 exactly when it hits the pygame.image.load. I eventually found a
 method to load them faster (8s as opposed to 9 hours for 379 images.)
 Still a bit long.  Anywho, I did move onto ZIP and whala, problems are
 gone. Now it only takes 0.07s to load all 379 images. Thanks for the
 response though. I think I'll just stick with ZIP for now.

Re: [pygame] Bundled app's About box

[Brian Fisher]

I *think* the information you are talking about is in the info.plist for an
app (right-click on the bundle, show contents, and then find the
xxx-info.plist file - you can double click it to edit it, and the editor has
helpful dropdowns to show you all the different values you can add to the
plist)

Once you know what the plist file needs to have in it to behave the way you
like, you can use the instructions on the link below to make your bundling
script set the plist settings as needed:
http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html#tweaking-your-info-plist



On Sun, Mar 14, 2010 at 9:25 AM, Dan Ross d...@rosspixelworks.com wrote:

 Greetings all-

 When I wrap up a game with py2app for Mac OS X, I would like to populate
 the About box with author, version, copyright information.

 I seem to be able to use __version__ in the main file of my game, but
 nothing else.

 Is it documented somewhere how to populate other items?

Re: [pygame] OS X 10.6 installation issues

[Brian Fisher]

The error is wrong and misleading. There is no pygame package for the system
python. The pygame prebuilts are for the framework build installs, from
python.org


On Wed, Feb 17, 2010 at 11:03 PM, bradley love bradley_c_l...@yahoo.comwrote:

 Hello, I have the factory install of Python 2.6.1 on my machine.  When I
 try to install the pygame 1.9.1release, the installer for the prebuilt
 package says, pygame requires System Python 2.6 to install.

 Am I out of luck because I am running 10.6 and not 10.5 (which the
 installer is geared for)?  If so, is there a workaround or a 10.6 installer
 on the way?

 Thanks, Brad

Re: [pygame] Squirrel Game Demo

[Brian Fisher]

On Thu, Feb 4, 2010 at 12:11 PM, Kris Schnee ksch...@xepher.net wrote:

 http://kschnee.xepher.net/code/squirrelgame/I'd appreciate thoughts on
 making the movement more satisfying.

 Animation can actually make a huge difference on the feel, but there are a
few things I think would help that are just mechanical.

You have decceleration on stopping, which is nice, but you don't have
acceleration on starting movement, which makes it very hard to make fine
adjustments on landing and such, you should probably pretty much mirror the
decceleration you have, meaning something with a fast response. Also, you
might want to consider having a little bit of acceleration that only fully
kicks in after a few seconds of movement - with that you have a higher
top-speed for longer distance runs, without sacrificing control for smaller
movements, which are good things.

Also, it would feel a lot more satisfying if the squirrel felt smarter when
it came to edges of platforms. In particular, if it was a little harder to
fall off the edge of a platform, and a little easier to jump when running
off the edge of a platform. In prince of persia (the original and sequel)
for instance, the character would go all the way to the edge when you asked
him to move, then hesitate for a moment before falling off (and if you
stopped asking for movement in the hesitation, he'd draw back on the
platform). Also, when running to the edge of a platform, if you jumped
early, he'd take an extra step to jump from the very edge instead. To feel
more squirrely, I'd suggest that the squirrel sort of grabs on to the
ledge edge and kind of rolls down around it a touch just a little bit before
he falls, and then if you jumped at that time, he'd spring off. part of that
would be a kind of aesthetic thing to match how squirrels actually move -
but also right now it's way too easy to jump too late and fall off a
platform for me.

Finally, it might be nice to do a little action on jump landing - in
particular, detect whether I am asking for movement when I land. If I am,
push right into that movement with no loss in forward movement - however if
I am not asking for movement when I land, instead have the landing kill the
motion faster, maybe even pulling me back to the landing spot a little. This
will make the squirrel feel move alive and squirrely, and will also make it
easier to land on a platform and more satisfying to hop around.

Re: [pygame] frame independant movement

[Brian Fisher]

The way Patrick describes is *by far* the most common way the main loop is
done in professional games. As he said, it provides consistent game behavior
but allows the actual frame rate to vary based on what the platform can
actually provide. The system actually works very very well, as long as
drawing takes longer than updating (which it still usually does, partially
cause of vsync to the screens refresh rate). However, if updating takes
significantly longer than drawing, then doing n updates for each draw ends
up making a less playable game versus just slowing down game play and having
one update per draw (but if that's your case, the gameplay suffers no matter
what your main loop does, so maybe it doesn't matter)

...and .02 is 50 fps, not 60 :)  GAMESPEED = 1/60.0 would be a better way to
do that.

.. and for max, I personally think 4 works really well, cause 15fps with a
60 cycle per second simulation is usually quite playable, but if your fps
drops below 15, it's usually more playable to also slow the game down.


On Wed, Feb 3, 2010 at 11:59 AM, Patrick Mullen saluk64...@gmail.comwrote:

 One method for having a smooth variable framerate, without the issues of
 variable time calculations, is to have a fixed time step. Each frame, you
 may process more than one timestep, if you need to in order to keep up. The
 timestep has a fixed amount of time it is supposed to similate, say, .02,
 which would be 60 times per second. If the user is able to run at 60 fps,
 they get very smooth animation, as only one step is occuring on each frame.
 If the user can only run at 30 fps, they will get two steps each frame, so
 it will be jerkier, but still accurate. If they can only run at 10 fps, you
 would set a limit on it (maybe the max is two timesteps in a frame), so
 things would be slower for them but maybe still playable.

 def dostuff(dt):
man.x += speed*dt

 GAMESPEED = .02

 while 1:
dt = clock.tick()
max=2
while dt0 and max:
   dt -= GAMESPEED
   max -= 1
   dostuff(GAMESPEED)

 There might be other problems with this, I've never done it this way, only
 seen it referred to. I know in some engines, like doom3, the physics of
 everything, game logic etc, happens at a fixed 30hz rate; whereas animation
 of the scene is much smoother.

 I am usually lazy and just do clock.tick(30) lol.

Re: [pygame] frame independant movement

[Brian Fisher]

On Wed, Feb 3, 2010 at 3:30 PM, R. Alan Monroe amon...@columbus.rr.comwrote:

  The nice thing about limiting the framerate versus having calculations be
  done based on time passed is that it is much more consistent. With dt
  calculations you will often get huge jumps on slower computers and extra
  slow movement in cases on fast machines, just do to inaccuracies and
 error
  in the calculation.  On a slower machine, no matter which timing method
 you
  use it will be unpleasant.

 What kind of innacuracies, specifically?

 Any time-step based integration of non-linear functions will have errors
and inaccuracies, which are larger the larger the time-step is.

...and pretty much all interesting real world physics are non-linear
functions.

So gravity for instance - if acceleration = time*gravity and position =
time*acceleration, the relationship between position and gravity over time
is nonlinear, specifically it changes with the square of time elapsed
(position = time*time*gravity). Doing that calculation as the sum of
repeated linear calculations, will have error. The magnitude of that error
will change with your time-step size.

The way that's a problem with a game, is when a level is dsigned so that gap
is exactly the right distance to be able to jump across it - but then some
slower computer uses a different larger time-step than your level designer -
so on that fast computer, you can't make the jump, cause the error on the
gravity effect is higher, so it pulls the player down sooner.

Some other examples of non-linear places with error are springs, friction,
application of the force of explosions that aren't instantaneous, etc. etc.
All those things and more will behave differently based on your time-step.

Re: [pygame] write sound to file for fast loading?

[Brian Fisher]

hey gumm,

you may or may not get better results with the process you describe - the
resulting sound file will most likely be much much larger (like orders of
magnitude larger) which increases the time it takes to load it from disk, so
if disk is the bottleneck (as opposed to cpu decoding), the trick would make
things slower.

Also, the problem you are experiencing is precisely what pygame.mixer.music
is for - it uses SDL's underlying feature for streaming a song from disk, so
the loading time is amortized over the game play time:
http://www.pygame.org/docs/ref/music.html

So what kind of sound file are you loading? mp3? ogg? wav? can you share one
of the problem files?
What does your sound loading code look like? Are you loading by filename or
file-like object?

... and to the poster who mentioned pyglet - why do you think it would help?
pyglet and pygame are very similar in music loading. Both pygame and pyglet
offer streaming music options that only help if you use them, and unless you
distribute avbin with your game, pyglet loads sounds with pure python code,
while pygame always uses mature decoding libraries.


On Mon, Feb 1, 2010 at 10:32 PM, B W stabbingfin...@gmail.com wrote:

 Howdy, folks.

 I have a problem I've been studying a while and I can't figure out a
 solution. Pygame or SDL--not sure which--is pretty slow at loading sounds.
 For large sounds, like songs, this means significant pauses in your game; or
 very long loading times at startup if you have a few of them to load.

 I tried using a thread to load a song, but as expected that only resulted
 in a very laggy game for the duration.

 So I was thinking it might be faster to pre-process a song: load it via the
 mixer, write the buffer to a data file, then later load it into an array and
 feed the array to the mixer. I can see that part of that idea is implemented
 in _sndarray.py, but I didn't really want to require numpy and I couldn't
 see how to convert that module's code to my purpose anyhow.

 I'm strikin' out. Is this even feasible, or is it a hair-brained scheme
 doomed to failure? Has anyone solved this problem, and would s/he be willing
 to share? :)

 Gumm

Re: [pygame] unsubscribe

[Brian Fisher]

Proprietary, yes, but Unity is cross-platform, not a windows product. To
Wii, iPhone and the web browser plugin as well - although the platforms are
all so different you'd need to change lots about a game to target all those
effectively, it's not a major win. And since Unity is built on Mono, once
mono supports the Dynamic Language Runtime extensions of .NET, IronPython
could be used for unity. Then it will taste like snakes. Which taste like
chicken.

... but it does not run on OLPC...

On Sun, Jan 31, 2010 at 12:14 AM, Bryce Schroeder bryce.schroe...@gmail.com
 wrote:

 Unity3D? Eeew. Windows. Proprietary. And I bet it tastes like gophers, too.

Re: [pygame] Working on Improving Font Support for GSOC

[Brian Fisher]

Hey Keith,
  what were the aspects of pyglet's font rendering that impressed you that
you'd like to see in pygame? Appearance? Speed? Ease of Use?


On Sat, Jan 30, 2010 at 11:14 AM, Keith Nemitz muse...@yahoo.com wrote:


 Take a look at pyglet. (pyglet.org) I was impressed by their font
 rendering, but I eventually went back to pygame to make product.

 It would be great if you could find what made their fonts better and
 incorporate it into pygame.


 good luck,

 Keith



 --- On Sat, 1/30/10, nikwin murthyn...@gmail.com wrote:

  From: nikwin murthyn...@gmail.com
  Subject: [pygame] Working on Improving Font Support for GSOC
  To: pygame-users@seul.org
  Date: Saturday, January 30, 2010, 11:08 AM
  Hello,
 
  I would like to work on improving the font support of
  pygame for GSOC.
  Could someone tell me what are the steps I should take to
  achieve
  this, and what I can do to start work? Unfortunately, my
  college has a
  very restrictive firewall, and so the amount of work I can
  do before
  summer is limited, and I cannot join IRC, but I would like
  to know
  what is doable.
 
  Thank you,
  Nikhil Murthy
 

Re: [pygame] OpenGL textures flipped

[Brian Fisher]

OpenGL doesn't actually have a set coordinate system like you describe - you
can always use the coordinate system however you want in OpenGL. For the
geometry coordinate system (or more specifically the mapping of coordinates
to your screen), the openGL user can set that themself, so you can make
OpenGL operate in pretty much whatever way you like. For texture coordinate
systems, top and bottom have no meaning in terms of the coordinate
system - top and bottom are simply a function of the content placed in the
textures. You can load your graphics in any way you like, you can even
change it up from one texture to the other, the only thing that matters is
that the texture coordinates in the vertices are correct for the content in
the texture. In the end, the whole system really functions on conventions,
and anything that is self-consistent is, in fact, correct. This is very
different from pygame and SDL, where those coordinate systems are hardcoded.
OpenGL is flexible, but there are common conventions.

...So what are the conventions for openGL then? It's pretty well understood
that +y is up (increase y, you go higher), for both geometry and textures.
Note that this convention is exactly opposite of the fixed coordinate
systems of pygame, SDL and many others, where +y is down (increase y, go
down). And openGL uses this convention for a very good reason - mathematics
uses that same convention, so you'll have an easier time working with math
funcs and stuff if you get into rotations and such.

... So what coordinate mappings is that code you referenced using?

It appears that it is using textures in a way that +y is up (like the openGL
convention). I can tell that because of the line that gets the pygame
surface as a string:
  textureData = pygame.image.tostring(textureSurface, RGBA, 1)
The 1 argument, is the flip argument. It's telling pygame to use the
opposite y direction of normal pygame use. Since +y is down in surfaces,
flipping means +y becomes up, so hence that's the meaning of the data that
is then loaded into a texture.

It also appears that it is using geometry in a way that +y is down (so like
pygame usage, opposite the openGL convention, and opposite the way the code
is using textures). I can tell this because of the call that's being used to
create the perspective:
gluOrtho2D(0, w, h, 0)
The arguments to gluOrtho2D are left, right, bottom, top, since it passed
0 as top and h as bottom, and h is positive, it means increasing y goes
down.

So that code is explictly making the texture stuff different than the
geometry stuff, which doesn't match pygame or conventional openGL use. If
you wanted to modify that code to use PyOpenGL conventions, you'd change the
gluOrtho2D call. If you want it to be like pygame, you'd change the flip
argument to image.tostring to False



... and as an aside, one way in which texture and geometry coordinate
systems are different in conventional openGL use, is NOT the direction +y is
(both are normally up), but in where the origin is - textures don't have
negative coordinates, so (0,0) is the bottom left. However in geometry,
negative coordinates are common, so (0,0) is actually the center of the
screen by default. There are some very good reasons to use that openGL
convention of the origin being the center (camera zoom and rotation foremost
among them), but with 2D usage, people often just make (0,0) the bottom left
instead, probably because it's what they are used to.


On Sat, Jan 23, 2010 at 3:11 PM, B W stabbingfin...@gmail.com wrote:

 Hey, all.

 An OpenGL noob problem. Loading a texture from an image, let's say
 some.png, is oriented upside-down and backwards when displayed. I've noticed
 this in two cases, I'll present the simplest.

 I was looking at this nice module
 http://www.pygame.org/wiki/SimpleOpenGL2dClasses?parent=CookBook. I made a
 32x32 image in GIMP according to the module's instructions and put an
 alphabetic character (L in the upper left corner) on it so I could see the
 orientation. When I run the module's __main__ demo the image is displayed
 upside-down and backwards. The image is attached to this post for those who
 care to try this.

 I experimentally modified the code in function createTexDL based on a
 recollection of something I read once: the coordinate system for geometric
 objects (lines, triangels, etc.) is not the same as that for textures.
 Geometry has origin 0,0 at the bottom left corner, whereas textures have
 origin 0,0 at the upper left corner.

 So the original code which displays upside-down/backwards...

 # Bottom Left Of The Texture and Quad
 glTexCoord2f(0, 0); glVertex2f(0, 0)
 # Top Left Of The Texture and Quad
 glTexCoord2f(0, 1); glVertex2f(0, height)
 # Top Right Of The Texture and Quad
 glTexCoord2f(1, 1); glVertex2f( width,  height)
 # Bottom Right Of The Texture and Quad
 glTexCoord2f(1, 0); glVertex2f(width, 0)

 Became this, the right orientation facing forward and upright...

Re: [pygame] Paths

[Brian Fisher]

In python, aggdraw (a wrapper of the very very awesome Anti-grain geometry)
can do that path stuff:
http://effbot.org/zone/aggdraw-index.htm
and aggdraw can be used to make pygame surfaces.

...such apis can be very cool tools to have, but are usually too slow to use
for drawing your whole scene on a frame-by-frame basis (they are best used
for drawing stuff onto surfaces or textures, and then using the faster
routines to work with the surfaces/textures). With software rendering
systems (like pygame), you can actually get away with limited use of such
apis, but on hardware-accelerated apis, such things usually demolish your
frame rate quite quickly.

... speaking of which, using CoreGraphics specifically on iPhone often
results in much less than satisfactory performance results. The best results
are either programming with OpenGL ES,  or using CoreAnimation Layers or
UIViews. CoreGraphics can be used to create CoreAnimation layers to work
with, but is a dog for drawing stuff to the screen directly.

... and it doesn't take a month to get stuff on the screen with OpenGL ES,
you could get functional in a week, I'd say.

On Sat, Jan 23, 2010 at 4:16 PM, Bill Coderre b...@mac.com wrote:

 So I've been hacking Mac OS X's Core Graphics as a way of learning iPhone
 coding (gotta sharpen those job skills), and I was wondering if there's an
 extension to pygame or python somewhere that implements path based
 graphics.

 In this model, you do stuff roughly like this:
 1) Open a path in the current context (graphics device, in pygame, I guess
 that would be a surface)
 2) Move to a starting point
 3) repeatedly add lines, rectangles, arcs, and bezier curves to the path
 4) Close the path (which implicitly adds a line back to the starting point)
 5) Fill or stroke (or both) the path, to get graphics to appear.

 If I wanted to write python and use Mac OS X's core graphics, there's a
 bridge already built. What I want is to use my code on other platforms,
 specifically the OLPC. (I realize this might be an unreasonable expectation,
 since the OLPC has very little graphics horsepower.)

 I am currently totally staying away from OpenGL, since it seems like it'll
 take me a month to make headway into that. Maybe, however, OpenGL already
 has path-based stuff.

 Anyway, I figured I'd toss this out there, see what people think.

Re: [pygame] Rotation Performance

[Brian Fisher]

.2 seconds to rotate an image sounds ridiculously long - that sounds broken.
Are you sure it can take that long just to do the rotation?

How big is this image?

Can you share a minimal sample (like 1 file + the image) that does the
rotations and prints out the timings, which goes really slow for you? If you
do that, then others can run it as well to see if they get the same slowness
you do.


On Wed, Jan 20, 2010 at 5:08 PM, Bram Cymet bcy...@cbnco.com wrote:

 Hi All,

 I did some profiling of my pygame application and I found that it was
 spending a lot of time doing rotation operations. Basically I have some
 balls on the screen that are represented by gifs with transparent
 backgrounds and I want to make them spin.

 I use the following code:


 These first two lines are only run in init for the object
 self.image = pygame.image.load('image.gif')
 self.image = self.image.convert()

  self.image = pygame.transform.rotate(self.image, degrees)
  self.rect = self.image.get_rect()

 Then I return the rect and blit and update that part of the screen. A
 lot of time is spent on that pygame.transform.rotate command. On my
 laptop with a dual core 2.2 ghz processor if works fine. However on the
 target hardware which is:

 Atom 330 (dual core 1.6 ghz) with an ION chipset and graphics

 it runs very slow and can take up to 0.2 seconds to execute just that
 one line of code.

 Is there something I am doing wrong? Is there some way I can make this
 faster.

 I am not sure if it matters but just for the sake of completeness: the
 application is multi-threaded but only one thread is running during this
 part of the application.

 Any help would be great.

 Thanks,

 --
 Bram Cymet
 Software Developer
 Canadian Bank Note Co. Ltd.
 Cell: 613-608-9752

Re: [pygame] Pygame and Enthought

[Brian Fisher]

On Thu, Jan 7, 2010 at 11:11 AM, David Arnold dwarnol...@suddenlink.netwrote:

 If I can build up the nerve to:

 sudo rm /usr/local/lib/libpng.dylib
 sudo rm /usr/local/lib/libjpeg.dylib


 It's not what you think at all - Did you read the instructions just above
those lines?

Those 2 files are not system files - snow leopard installs don't normally
have libpng and libjpeg dylibs in that path. The package that the
instructions refer to which the previous line tells you to install is what
creates those files. It's basically suggesting you remove those files
immediately after asking you to add them.

The reason for deleting them has to do with the idea of building a pygame
installer on the mac, or with using py2app. If those dylib files exist, the
build process may choose to link the built pygame to the dylibs (instead of
using the static libs). If you then try and take that built pygame to
another system (through a pygame installer or py2app) that built pygame will
be dependent on those 2 dylibs being in that location, which means it will
error on that other machine unless it runs the libjpeg and libpng installer
as well.

Now in your case, if you don't care if your built pygame has those
dependencies, by all means skip the rm step. However, if you were thinking
of making a pygame installer for other enthought users to save them the
trouble you went through, then you should definitely go ahead and remove
those files - knowing that they are just kruft you installed yourself.

Re: [pygame] Pygame and Enthought

[Brian Fisher]

On Thu, Jan 7, 2010 at 11:11 AM, David Arnold dwarnol...@suddenlink.netwrote:

 The prebuilt binaries for the Mac don't work as they look for the python2.6
 that comes with the mac. I'm not using that version, so the binaries don't
 install.

 David, what makes you think that the prebuilts use the system python that
comes with the mac?

The reason I ask, is that the claim is untrue - their are no prebuilts
provided that use the system python, all the prebuilts provided use the
framework builds of python, like what you get from python.org.

Have you actually tried the prebuilts, or are you just assuming the system
python thing?

As James said, the prebuilts on pygame.org should work for you, if enthought
python installs into /Library/Frameworks - so what version of python does
enthought use? if it's 2.4, 2.5, or 2.6, there's a package for you to try
here:
http://pygame.org/download.shtml

Re: [pygame] Pygame and Enthought

[Brian Fisher]

I've never heard of python 6.0... there are no prebuilts for that...

It seems if enthought has no pygame, building it yourself is probably your
best bet. If you get an error or problem running setup.py, post back here.


On Thu, Jan 7, 2010 at 7:48 PM, David Arnold dwarnol...@suddenlink.netwrote:

 Bill,

 EPD is installed in /Library/Frameworks/Python.framework/Versions/6.0/

 David

 On Jan 7, 2010, at 6:03 PM, Bill Coderre wrote:

 On Jan 7, 2010, at 10:13 AM, David Arnold wrote:

 Hi,

 I've installed the latest EPD 6.0 on a Macbook Pro running Snow Leopard
 from www.enthought.com. I'd like to give pygame a try, but I am unsure as
 to how it should be installed on my environment.

 On www.pygame.org, I did see some installation instructions for Snow
 Leopard, but these depended on Macpython, a different distribution.

 Has anyone installed pygame in the Enthought distribution that could lend
 some advice?


 I can't, since I need a login. Since one is supposed to pay for this
 service, I suspect you can contact their customer support and find out how
 to use PyGame with their distro.

 1) Contact Enthought. If they're going to be creating a huge pile of
 Python, PyGame should be one of the things they install.
 *
 *
 *Is PyGame already part of EPD? If not, what the heck is wrong with them?
 *

 *PyGame is an awesome SDK -- takes like 30 lines of code to make a simple
 game!*




 2) PyGame installs into /Library/Frameworks/Python... which is where
 MacPython installs stuff. MacPython installs there, as opposed to Mac OS X's
 system copy of Python, because
 a) It doesn't take THAT much disk space, and
 b) It (sort of) prevents (some) badness from screwing up Mac OS X's system
 software.

 *Does EPD install into /Library/Frameworks/Python.framework?* I bet it
 does.

 I can't get to their distro, so I can't tell, but you can tell easily by
 using a shareware called *Pacifist*. You literally drop the EPD installer
 on the Pacifist icon, and it will show you where everything is installing.
 (If you'd rather do the same thing without downloading stuff, type *man
 lsbom *into a terminal window. (*lsbom -f
 /path/to/Foo.pkg/Contents/Archive.bom* is usually what you want.)

 Also, and this is top secret, so don't tell anyone, most installer packages
 are bundles which means they're really folders in disguise. You can
 CMD-CLICK on a bundle and use the contextual menu to Show Contents -- and
 then double-click the Archive.pax.gz file to expand everything and look at
 what gets installed where.

 Mac installer packages that are not bundles are called flat file
 installers and *pkgutil --expand *can open them up.


 3) Worst case, you can install MacPython and Pygame and various other
 python libraries yet again, and have THREE copies on your Mac -- but it's
 only wasting MAYBE 200 MB at the most. (OK, so that's not so great, but hey,
 at least you can use PyGame.)

Re: [pygame] Speed up image.tostring with OpenGL ?

[Brian Fisher]

I know nothing of toonloop, so I'm guessing here, but I think your problem
is not what you think it is, and from your problem description, it's likely
you are not using openGL in the way it is meant to be used.

pygame.image.tostring is plenty fast, as fast as a pygame blit it's
extremely unlikely it represents any kind of bottleneck whatsoever. If you
want to test this yourself, temporarily hack your app to just keep sending
the same string up to the card over and over again (i.e. eliminate the
tostring call), and check your frame rate. I expect you'll see no difference
at all.

Your slowness is probably caused by either uploading textures to opengl
being a relatively slow operation (this is true no matter how you got the
bytes to send to it) and/or your program being blocked by the OpenGL queue
processing when you try to change a texture which there are pending
operations on. (you aren't reusing the same single texture over and over
again, are you?)

The speed of hardware acceleration really comes from 2 specific things -
first is that you do complex operations on a set of textures which have
already been uploaded to the card (meaning you make a lot of pixels draw
with a relatively small set of vertex data being sent each frame), second is
that you are taking advantage of parallelism by making the graphics card do
work independently of your CPU (meaning you send commands that the graphics
card can do on it's own time and won't block the rest of what your program
does).

If you upload a new image every frame, you are not able to take advantage of
the first way in which hardware acceleration speeds things up (you are
basically sending all the pixels over to the card). If you are changing the
content of textures as the graphics card is trying to draw them, you are not
able to take advantage of the second way (the cpu ends up having to wait on
the card being done with the texture before it can change it)

you are probably right to think the whole thing should be done in pygame,
but there are probably ways you could speed stuff up if there is a good
reason to stick with opengl.

The best way to do this in opengl, would be to load all the distinct frames
into textures ahead of time, and then draw through them.

Barring that, you could probably make the routine at least twice as fast by
rotating through a pool of textures (so that you are never waiting to change
a texture as it's being drawn)

Also, you should probably use RGB instead of RGBX (should take 3/4ths the
bandwidth to the card), there's no point in sending a dummy byte to the
graphics card, when it comes to uploading textures, total bytes sent is
generally much much more important than alignment issues.


On Sun, Jan 3, 2010 at 8:06 PM, Alexandre Quessy alexan...@quessy.netwrote:

 Hello Pygame users and developers !

 Is there a way I can speed up the transfert from a surface to an
 OpenGL texture ? Right now, I use the pygame.image.tostring function,
 but it seems like converting the pixels to a Python str creates a
 serious bottle neck in my stop motion application...

 I think that it should either be implemented directly in Pygame, (best
 option) or done using something like ctypes in my application. If none
 of these option is not easy enough, I am thinking about switching to
 Gstreamer+GTK with the GdkPixBuf, instead of Pygame surfaces. An other
 option would be to rewrite the whole application in C++...

 Any suggestion to fix this in a way that is not too long ?
 My frame rate drops to 4 FPS when there are more than a few surfaces in my
 list.
 Please try Toonloop to test this out. It works well on Linux. If
 someone get it to work on Mac or Windows, I would need hints for
 packaging it for those OS too. I convert the surfaces to OpenGL
 texture in texture_from_image from the file
 http://bitbucket.org/aalex/toonloop1/src/tip/toon/draw.py on what is
 currently the line 42.
 --
 Alexandre Quessy
 http://alexandre.quessy.net/

Re: [pygame] Re: Erratic behavior with pygame.font.SysFont

[Brian Fisher]

On Thu, Dec 31, 2009 at 3:12 AM, Rolf Sievers rolf.siev...@lg-bs.de wrote:

 I doubt I'm capable of writing such a script.


Believe in yourself, Rolf! I know you can do it.

Re: [pygame] Text has zero width Exception in font_render

[Brian Fisher]

running pygame in a thread and then killing it and restarting it multiple
times is not a well tested path. I would expect that is why you you are
running into weird and unusual problems. Also note, the various platforms
(PC, Mac, Linux) often have their own odd problems with running window
management code in multiple threads - just a note if cross-platformness is
important to you.

Practically speaking, what you probably want to do is:
a) find another way to do what you want without shutting down and restarting
pygame and possibly without a separate thread even.
b) treat this as a pygame bug - i.e. try to make a minimal sample that
demonstrates the problem for somebody (possibly even you) to use for
debugging.


On Tue, Dec 22, 2009 at 4:20 PM, Mark Reed markree...@gmail.com wrote:

 Should I not be running pygame in a thread then killing it and
 restarting it multiple times in the same process? I assume if this was
 bad I'd see more random problems than this.

 Mark

Re: [pygame] 3d surface

[Brian Fisher]

I don't have an example or tutorial - but so you know, pygame does not help
make 3d easier, aside from the fact it can help create an OpenGL window for
you. To do 3d with python people either use OpenGL with the PyOpenGL module
and/or the pyglet library, or they use some game engine thing that manages
3d, like Panda3d or something.

On Thu, Dec 10, 2009 at 12:42 PM, Eduardo Luttner elutt...@gmail.comwrote:

 Hi,

 I am evaluating PyGame to create a 3d surface navigator (something like
 google earth)

 I have the raster pictures and the surface lines. We have achieved doing
 that using vlib, which is a c++ lib.

 I am trying to convince the stakeholders to use python, since the
 development will be faster.

 Anyone has an example / tutorial or start point for me?

 thanks

 eduardo

Re: [pygame] making game distribution easier, part 1.

[Brian Fisher]

It would be wonderful to have something like this, but you have difficulties
with getting the right version and platform for your game's dependencies
that I don't see how to get around so simply.

what py2exe and py2app did was to go find all your game's python
dependencies in your site-packages dir, and put them into the binary game
package. The great thing about that, is that it would take the smallest part
of the (working and tested) system configuration you have, and put that into
the package.

So for instance, lets say your game uses wxPython, and in particular you
developed and tested it with 2.3.0.111 (or whatever).  So you've got your
system, and it works great, then py2exe/py2app makes a zip that includes all
your game's code, plus wxPython 2.3.0.111.

So then if wxPython 2.3.1.200 comes out, and breaks your game (lets say a
bug they fixed in the scroll bar modules makes your level picking screen
that counted on the bug stop working, so users can't pick levels). With the
py2exe/py2app thing, the great part is 2.3.0.111 is embedded, so your
package keeps working.

Also, wxPython 2.3.1.111 has different binary files on Mac OS X and Windows
and Linux (and for flavors of linux and for unicode vs single-byte strings
as well). When you installed wxPython, you only got that subset relevant for
your platform. So to cross build for another platform, you need a different
install package.

So how would such a simple system as the one you describe get around that
kind of stuff?


On Tue, Dec 8, 2009 at 10:54 AM, René Dudfield ren...@gmail.com wrote:

 Hi,

 I've been working on plans to make distributing games easier.  So
 people can more easily let their friends and families play games they
 have made.

 Part of this plan is to make binary creation easier(zip files
 containing your game for each platform specifically).

 The current situation is that people need to get py2exe py2app,
 cx_freeze and other modules setup, and working in their setup.py file.
  Then they have to adjust things for how their game works, and then
 get access to every platform.  Unfortunately each of these things
 changes occasionally, so old setup.py files do not work for other
 people.  This results in people not making binaries for every
 platform, and makes it hard to share games with your friends and
 family.

 So the plan is to make our lives easier creating distibutables for
 every release of some game we make.



 Basic idea:
 ===

 To be able to copy your game into a directory for each platform and
 your job be done.
 `cp -r YOUR_BITCHIN_GAME game_launcher_macosx/games/`
 `cp -r YOUR_BITCHIN_GAME game_launcher_win_x86/games/`
 etc...

 Then you can zip up that directory and send it to a friend.  There
 will be a python module available to automate this stuff.



 Make a game_launcher package for each platform.
 ===

 Where this bundle would be something like:
   - game_launcher_macosx
   - game_launcher_linux_x64
   - game_launcher_linux_x86
   - game_launcher_linux_arm
   - game_launcher_win_x86
   - game_launcher_win_x64
   - game_launcher_win_symbian

 That is have a directory with binaries for each platform.

 Then you can easily make your game work for that platform by copying
 your game files into a directory like this:
 `cp -r YOUR_BITCHIN_GAME game_launcher_macosx/games/`

 Your game would have to have a run_game.py script which calls your
 games main function and starts up.



 Libs.
 =

 Most commonly used python game libs would be included (numpy,
 pyopengl, pyaudio, PIL etc).

 These generic bundles would have many of the common modules used for
 making games included.  You can just copy in any other libs you need.
 If the module requires platform specific code, then that can either be
 made independantly or otherwise.


 It would allow people to create 'game_launchers' for various platforms.



 Automating distributable generation.
 
 This would just involve some scripts to copy your game files to the
 game_launcher directory

 This would be a library, like:
 pygame_distribute.make(my_game_path, output_path)

 Or it could be a distutils command part of peoples setup.py scripts...
 python setup.py pygame_distribute

 (which would copy the distributables into dist/)


 I don't think it should come with pygame, since it would be quite
 large... like easily 200MB for many platforms.

 With extra config it should be possible to upload releases as well.



 What about debian, rpm, macports, archlinux, other distros?
 

 We should be able to make this easier somehow.  For example, arch
 linux, and macports just require a text file with a link to the
 source, and a few dependencies listed.

 Although creating packages for these systems is not the initial aim,
 it would be good to consider them.

 How can this work with symbian?  Any ideas Jussi?  I'm not sure it

Re: [pygame] Re: loss of rapidly repeated keypresses (from a barcode gun keyboard)

[Brian Fisher]

On Wed, Dec 2, 2009 at 1:51 PM, James Paige b...@hamsterrepublic.com wrote:

 I did a quick test with Pyglet, and it suffers from the same problem. I
 take that to mean that using sdl event callbacks does not work around
 this problem.


What that suggests to me is that the problem lies with the way the USB
barcode scanner interacts with system components, well below the application
layer. So like maybe with the HID driver or windowing system of your
computer.

I'd try it on a different platform, to confirm.

... and as far as workarounds go, maybe you can build this into the game
design? Like make gameplay be about how digits change? or the number of
distinct digits found? something like that...

Re: [pygame] Font-Related Segfault

[Brian Fisher]

Pygame should be supporting a file-like object no problem, so this seems
like it could be a bug.

Can you be more specific on when in the past it worked, and what happened
between then and when it segfaults now?

Also, it's not clear from your problem description whether the problem is
that pygame crashes when loading from a file-like object, or if pygame
crashes on a specific set of font data.

So I would suggest doing a sanity check here by writing the
self.parts['font'] string to a temp file, and trying to load from that, as a
way of being able to determine if the crash is caused by the file-like
object reading, or by some problem with the contents of the file-like
object.

So something like:

class Font(Resource):
 
  def pygame_font(self,size):
  file(temp_file_name, w).write(self.parts['font'])
  return pygame.font.Font(temp_file_name, size)
  os.unlink(temp_file_name)

If that still crashes, then pygame has trouble with that font content, and
then the question would be to figure out what about that font content is
causing problems. If that doesn't crash, then the problem would be with
accessing the content as a file-like object.


... finally, as general advice to all people posting problems - if you can
send a completely self-contained reproducible case, then you are much more
likely to get good help and results faster. As an example in this case,
providing the contents of the self.parts['font'] string in an attached file
with a simple script that tries to load from a StringIO using that file's
contents, would make this easily reproducible and testable by fellow mailing
listers - but without knowing what the contents of the string in question
are, it may actually be practically impossible for anyone else to test
themselves.


On Mon, Nov 23, 2009 at 12:38 PM, Bryce Schroeder bryce.schroe...@gmail.com
 wrote:

 (My apologies if this is a double-post. I didn't get a copy of the
 message or see it in the archive, so I'm trying again.)

  I have a pygame program that worked in the past on both Linux and
 Windows, but now results in a segfault, at least on Linux.  (I can't
 test it on Windows.)
 The segfault occurs in this code:

 class Font(Resource):
  
   def pygame_font(self,size):
   return pygame.font.Font(StringIO.StringIO(self.parts['font']),
 size) # Segfaults here


 self.parts['font'] is a string containing a truetype font loaded from
 a file. I have checked that the string contains the file like it is
 supposed too. Any suggestions?

Re: [pygame] BUG: Different events when I enable OpenGL

[Brian Fisher]

On Fri, Nov 20, 2009 at 9:27 PM, Thomas Hansen thomas.han...@gmail.comwrote:

 pygame.display.set_caption('pymt')
 hwnd = ctypes.windll.user32.FindWindowA(None, pymt)
 ctypes.windll.user32.RegisterTouchWindow(hwnd, 0)

 Hey Thomas,
  you may want to double check that the hwnd you are getting is the right
one - those windows funcs would execute without an exception if they had
some kind of error or problem.

Also, the normal way to get an hwnd in pygame is this:

hwnd = pygame.display.get_wm_info()['window']

So you might want to do a quick check to see if the value from the
FindWindowA func matched what get_wm_info gives you.

Re: [pygame] Strangest thing..

[Brian Fisher]

Your script is not creating a window - various things may not work right
without a window on windows.

On Sat, Oct 24, 2009 at 4:00 PM, Olof Bjarnason olof.bjarna...@gmail.comwrote:

 Hi pygame-users!

 I'm new to the list, but not to Python/PyGame.

 Tonight I tried playing some music, and noticed that my program only
 would play sound if I doulble-clicked the .py file in an explorer
 window, not if I ran the script from a command prompt. I'm on Vista,
 Python 2.6.1 and Pygame downloaded today, the python 2.6-series.

 I stripped down the script to a bare minimun to debug it, and the
 behaviour still there in this tiny script which only uses the
 enter.wav sound, built into windows.

 ### START tmp.py
 import pygame
 import os
 import sys

 pygame.init()
 pygame.mixer.init()

 print(pygame.mixer.get_init())
 print(sys.version)
 print(os.getcwd())

 pygame.mixer.music.load(enter.wav)
 pygame.mixer.music.play()

 while True: pass
 ### END

 I'm kind of lost as to what to do now to try to solve the problem, I'd
 really like to know what I'm doing wrong, since I think this program
 might be related to a show-stopping issue for me (DLL problems after
 doing a py2exe build).

 If any one would try and see if the error is still there on their
 machines, I would be grateful. The enter.wav file should be located
 beside the tmp.py script, and could be found using ordinary F3 search
 on Windows.

 Cya,

 /Olof

Re: [pygame] MIDI output on OS X???

[Brian Fisher]

On Mon, Oct 12, 2009 at 12:54 PM, Chris Phoenix cphoe...@gmail.com wrote:

 BTW, the install of pygame somehow didn't set the python path
 correctly, so I had to cd to

 Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages
 to run this command, and in my programs I do:

 import sys

 sys.path.append('/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages')

 Hmmm.. that doesn't sound right. Python extension libraries are not
supposed to be changing your python path when they install. Your python
install should already be using the right site-packages directories for
whichever version of python you are running.

It sounds like the python you are running is not the python 2.5 framework
version you installed, which is the one pygame installs in. You are probably
running the system python instead (on OS X 10.5, it's a python 2.5.1 install
using /Library/Python/2.5/site-packages), which most extensions avoid
installing in because it belongs to the system.

What does which python at the shell tell you?
What python version is printed when you just run python from a command
shell to get at the python shell?
How do things work out if you run python using
/Library/Frameworks/Python.framework/Versions/2.5/bin/python instead?

Re: [pygame] Depth Screenshot

[Brian Fisher]

On Tue, Oct 6, 2009 at 7:43 PM, Ian Mallett geometr...@gmail.com wrote:

 The issue is that in the case of depth, data is of length x*y.  In the case
 of RGB color, it is 3*rect[2]*rect[3].  In the case of RGBA, it is
 4*rect[2]*rect[3].  PyGame doesn't know how to convert it (there's no
 pygame.image.fromstring(data,size,'R',1), for instance).  What's a decent
 way to save the depth as an image?

 have you tried a paletted image? they are one byte per pixel.

so:
pygame.image.fromsring(data, size, P, 1)

another option would be to try python's array module - can you
array,fromstring(data, B)? if so, that will let you index the bytes
yourself to do whatever you want with them.

Re: [pygame] 10 bits per color

[Brian Fisher]

On Thu, Oct 1, 2009 at 8:50 AM, James Paige b...@hamsterrepublic.com wrote:

 Regarding the limitations on the human eye: I am no expert on this, but
 from what I have read, the average human eye can distinguish somewhere
 from 7 to 10 million different colors.

 RGB888 is 24 bit color, which is enough for over 16 million colors.

 So by that measure, average human eyes should not be able to tell the
 difference between RGB888 and RGB101010

 Your facts are all basically correct, but some things you are missing is
the fact that human vision is both dynamic in terms of it's ability to
perceive ranges of intensity and color and able to support a very wide
contrast ratio (around 1,000,000 to 1) compared to what contrast ratio
monitors are currently pumping out (somewhere between 350:1 to 1000:1) (btw,
our perception is basically decibel based, so it's more like the best
monitors are 1/4th of what we can do rather than 1/1000th)

What that means is our monitors are pretty much crap when it comes to maxing
out our eyes contrast-wise, and that even though our eyes have limited color
perception, the limits and use of that limited color perception depend on
what we are looking at - or to put another way, which 7-10 million colors
the average person is distinguishing depends largely on what colors and
intensities there are to look at. (btw, this is why contrast ratio doesn't
matter so much for home or movie theatres with paltry contrast ratios of
1:500 but the environment is blacked out - our vision readjusts very well to
just using the range provided)

The big thing about all this new monitor stuff is the new high-contrast
displays, as Pierre said new TV with
retro light using LEDs has higher contrast (up to 200:1 wich is about
126 DB dynamic range). People who have seen those new monitors have told me
the pictures looked like real life, that it was like looking out a window,
not at a monitor.

With those new high contrasts though, if you aren't using the full contrast
range for a particular scene, RGB888 can be way too small. So more range is
needed if you wanna do something like go from a cave to the out of doors -
if the cave is half as bright with RGB888, you dropped half your range, to
RGB777, and your eyes can start seeing bands and such better.


Of course, I am no expert on this, and I know that the way the rods and
 cones in an eye encode color is very different from the way digital
 color is encoded in pixels, so there may possibly be other reasons why
 RGB888 might be less that mathematically perfect for human color vision.

 RGB is designed to be close to our rods and cones, which for most people
see an R with very good color range, a G with good color range, and a B with
mostly OK color range (relatively speaking). That's why many restricted bit
color schemes with uneven bit allocation put the extra bits in the R or G
but never the B. But there are actually some people (I've heard they are
mostly if not all women) with an extra cone (I think) that is pretty close
to the B, and those people have amazing color perception much much better
than RGB888, and usually work in color and print related fields cause they
can do things like match paint samples and colors at a level beyond what us
normal people can.

Re: [pygame] 10 bits per color

[Brian Fisher]

On Thu, Oct 1, 2009 at 9:53 AM, pierrelafran...@sympatico.ca 
pierrelafran...@sympatico.ca wrote:

 René, you put the fingers exactly in the center of our question: Why
 camera gave 12, or even 14 bits per color, if Windows, Display, Grahic
 cards are limited to 8 bits per color ?

 I'm not saying RGB888 is perfect for human color perception, but to answer
your question about why cameras can go higher than 8 bits per channel (like
with .RAW files) while the display can only go to 8 bits per channel - the
basic reason is because people will take the things their cameras record and
put them through transforms and scalings and stuff like that. Like with
James' example about his pictures in the cavern - if you take a shot where
you want to take the data your camera recorded and remap it to a different
output range, you are losing precision, and your output data is aliased. So
if you want to be able to do levels or color remappings or other photo
manipulation effects, you need the extra bits in your source, cause you are
going to lose bits when you do those effects/transforms.

So, assuming your display technology is optimized to be able to present
things to the full range of possibilities humans can perceive, it should be
*expected* that an optimal recording technology would have higher precision
in it's recording than the output device the final product is intended for.

To think that the output technology precision should match the source
precision so you get to see all that data is a flawed way of looking at
it. The right way to think about it is your output technology should be able
to express the full range of human perception, and your source tech should
be able to have enough precision to express the full range of your output
technology after applying the filters and effects and transforms.

Re: [pygame] event getting corrupted

[Brian Fisher]

I'm a little confused - you said you get a segmentation error, and you
mentioned running a debugger, but you are showing a python error. So do you
get a real segmentation fault? Like bad memory access that drops out of
python and all that? If so, you haven't captured that error in the right
kind of debugger for seg faults (gdb) yet.

Assuming you are getting a seg fault, then that sucks.  If it were me in
that case, I'd probably see if I can set up some system to force the error
to happen. Like say make the game run through the conditions that you see
the error in now, and make it run over night - or maybe set up some kind of
automation to record and playback some play, and again, run it all night.

The reason getting a stable reproducing case is so important, is then you
can binary search this. Like disable all blitting, or turn off the music,
etc.

As far as the python stack trace goes, if you are getting a seg fault, then
the weirdness of the python stack makes it seem likely that memory
corruption happened between the event.pos and event.button lines, as you
pointed out. Is this python stack reproducible? Have you seen it multiple
times? If so, then it seems like it could be code that executes
synchronously between those 2 lines, in which case tossing a ton of asserts
or temp = event.button lines in the mouse_button_up would help you narrow
down the lines that trigger things next time this in-python exception
triggers? If on the other hand you haven't seen it before/can't reporoduce
it, it may just be a red herring, and the corruption could be happening
asynchronously in some other thread - maybe it could be the music?

So what OS and versions of stuff you using when you get the error? Have you
been able to try the code on other platforms? Any other libraries besides
pygame used with this program? Any idea when exactly it started occurring in
relation to your code? Any code of yours that seems like something that
could be causing the problem (like your own c compiled extensions)? I don't
suppose you are blitting a surface to itself anywhere and using Linux?


On Wed, Sep 16, 2009 at 11:36 AM, Bo Jangeborg b...@softwave.se wrote:

 I have seen a troubling error for some time now.
 Occasionally I get a segmentation error with no indication of what
 went wrong. The error is not repeatable in a reliable way and I get
 no error trace. Repeating the error can take hours.

 After seeing this I have tried to pin down, with the debugger running,
 what's going wrong but the nearest I can get is that the event object
 gets turned into a long at different times.

 Running with a debugger I got this trace. I have included the calling
 line were you can see that the event seem to be correct, but at some
 point the event object seem to become corrupted.
 Included is also the code between the call and the eventual point
 of error. I am at loss at what may be going wrong.

 Bo)

 Traceback (most recent call last):
  File C:\Program
 Files\eclipse\plugins\org.python.pydev.debug_1.4.7.2843\pysrc\pydevd.py,
 line 881, in module
   debugger.run(setup['file'], None, None)
  File C:\Program
 Files\eclipse\plugins\org.python.pydev.debug_1.4.7.2843\pysrc\pydevd.py,
 line 710, in run
   execfile(file, globals, locals) #execute the script
  File C:\Projekt\eclipse\Pyos\Program\Solitaire\solitaire.py, line 761,
 in module
   main()
  File C:\Projekt\eclipse\Pyos\Program\Solitaire\solitaire.py, line 80, in
 main
   if screen.main_loop(app):
  File C:\Projekt\eclipse\Pyos\System\widgets\gui.py, line 328, in
 main_loop
   = self.mouse_button_up(event, mob_pos, mousemove)
  File C:\Projekt\eclipse\Pyos\System\widgets\gui.py, line 573, in
 mouse_button_up
   if event.button == 1:
 AttributeError: 'long' object has no attribute 'button'


 elif event.type is MOUSEBUTTONUP:
mob_pos, mousemove, mouse_pos, hit_pos \
= self.mouse_button_up(event, mob_pos, mousemove)



   def mouse_button_up(self, event, mob_pos, mousemove):
   ''' handle mouse button up events'''
   mousebtn_event = False
   mouse_pos = event.pos
   widget, hit_pos = self.mouse_hit_widget(mouse_pos[0],
   mouse_pos[1])
   if widget is None or not widget.enabled:
   self.moving_object = None
   self.repeating_object = None
   self.last_over_drop_widget = None
   else:
   event_data = {'hit_pos':hit_pos, 'over_widget':widget}
   event_data['gui'] = self
   if widget and widget.exists('event_click_release_data'):
   event_data.update(widget.event_click_release_data)
   #InsideButton  (Left)
   if event.button == 1:



   def mouse_hit_widget(self, hit_pos_x, hit_pos_y, draged_widget=None,
   dropreciever=False, mouse_down=False,
 mouse_over=False):
   ''' Return the first valid widget under the mouse pointer'''
   widget_hit, hit_pos = _mouse_hit_widget(self, hit_pos_x, hit_pos_y,
 

Re: [pygame] Re: Hexagonal collision detection?

[Brian Fisher]

On Wed, Sep 16, 2009 at 1:45 AM, rygoody rygo...@gmail.com wrote:

 But this right here
 test = (y - y0)*(x1 - x0) - (x - x0)*(y1 - y0)

 That's just the cross product of 2 vectors (which is the same as the dot
product of the 2 vectors where one is rotated 90 degrees)

the first vector is the path from the start of the line segment to the text
point ((x-x0), (y-y0)) and the second vector is the path from the start of
the line segment to the end ((x1-x0), (y1 - y0))

the cross product of two 2d vectors (a,b) and (c,d) is a*d - b*c. You get
that cause to rotate (c,d) 90 degrees results in (d, -c), and to dot product
(a,b) with (d, -c) results in a*d + b*-c which is the same as a*d - b*c.

the cross product is interesting because it's sign tells you which side of
one vector the other one is on, when they have the same origin (so basically
would you make a left turn or a right turn from one vector to go in the
direction of the other). you can see this in terms of the dot product of one
vector rotated 90 degrees, cause the sign of the dot product tells you if 2
vectors go more in the same direction or more away from each other (or 0 for
perpendicular), it's hard to explain why that's so, but if you draw pictures
you'll get it



 How is that working to produce per pixel collison detection when the
 for loop is only going through the Lines list which only has 5 entries
 of 2 lists (for a pentagon)
 I would expect you would have to go through each pixel line and use a
 linear equation to interpolate between the points, but you appear not
 to be doing that.

 How is that working?


the reason that loop works, is because all the line segments of the polygon
go in the same direction (i.e. clockwise or counter-clockwise) and because
your polygon is convex (it doesn't have any pits in it's outside). Because
of those 2 properties, it means that all inside points in your polygon are
on the same side (left or right) of all of the line segments (so say the
line segments go around clockwise, then the inside of the polygon is always
on the right side of every polygon line segment - if your line segments went
counter-clockwise, then the inside of the polygon is always on the left side
of every polygon line segment)

So the loop is using the cross-product of the point relative to the edge
against the direction of the edge to find out which side of the edge the
point is on. If the point is on the inside-side of each edge, it must be
inside the poly. If it's on the outside-side of any edge, it cannot be
inside the poly.

Note if you wound your poly in the other direction, you'd have to check for
the other sign  (i.e you'd check for test  0 inside of test  0)

also note that if your poly was not convex, the test would fail for some
points.

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Brian Fisher]

Well that looks like a very complicated way to clear the screen, which also
involves blitting a surface to itself (you are blitting the
pygame.display.get_surface() to the pygame.display.get_surface() after
clearing the surface)

The symptoms of your original bug report seem remarkably similar to a bug
that existed in SDL with blitting a surface to itself due to a change in gcc
4.0 (it stopped restoring the direction flag). The exact problem in that
case was that the SDL code to blit a surface to itself was special cased,
and that special case assumed the direction flag was cleared when it did a
rep movsb. But since it wasn't with the new gcc, if the direction flag had
been set elsewhere, then the copy went in the other way and either corrupted
memory, resulting in that string state error message, or crashed

I don't recall how that old bug was (or was not) resolved for pygame, but
there is history on that bug on the list archive.

Lenard probably remembers it much better than me.

... but you could also fix this by replacing thatvery  convoluted
clearScreen body with a simple self.screen.fill((0,0,0))


On Wed, Sep 16, 2009 at 11:15 AM, Peter Chant p...@petezilla.co.uk wrote:

 D'oh so obvious.  What I regularly do whilst developing things, but not
 when
 bugs suddenly appear.

 FOUND IT!
 self.screen.blit(clear,(0,0))


  - look for the exclamation marks

def clearScreen(self):
print In clearScreen
print About to call pygame.display_get_surface()
clear = pygame.display.get_surface()
print About to fill surface to clear it
clear.fill((0,0,0))
print About to self.screen.blit -  this crashes
self.screen.blit(clear,(0,0))
print just blitted - ! does not get to here


 self.screen is initialised by the output of another class.
  self.screen = h.screen

 in class h

  self.screen=pygame.display.get_surface()

Re: [pygame] Why does ALT+F4 not get recognized here?

[Brian Fisher]

The mod flag comes in on the mod attribute of the event, it isn't part of
the key.

so like this:
 alt_f4 = (event.key == K_F4 and event.mod == KMOD_ALT)

there is a list of events and their attributes here:
http://www.pygame.org/docs/ref/event.html


On Sun, Sep 13, 2009 at 10:34 AM, Fawkes fawkesga...@gmail.com wrote:

 Hello,

 I am having trouble with getting Pygame to recognize ALT+F4. I'm using
 this combination of keys to invoke an exit from the program.

 The code I am using works as follows:

for event in pygame.event.get():
if event.type == QUIT or (event.type == KEYDOWN and
 event.key == KMOD_ALT|K_F4):
exit()
# Other event commands follow

 Every other event is recognized on this computer and exiting with ALT
 +F4 seems to work on several other computers but I do not know why it
 does not work with this one. It neither recognizes Left Alt + F4 nor
 Right Alt + F4. What would be the best way to diagnose the cause of
 this problem? I would greatly appreciate any help you may be able to
 give me.

 I am running Windows Vista SP1 - 64 Bit.

 Thank you in advance
 -Fawkes

Re: [pygame] Numeric wireless keyboard

[Brian Fisher]

I think you probably can't get those messages without creating a window, so
try creating a window before getting events.

 Also, you don't want to have a separate poll and wait func, which are both
called and both check for different messages. Both those functions remove
messages from the queue, so if a your poll function gets a SDL_KEYDOWN
message, it would end up throwing out the message and then your wait
function would never receive it. Just do the Poll thing, and make it's
switch statement do the prints for SDL_KEYDOWN as well.

Anyways, once your test program works for your normal keyboard, then you can
try it out with the wireless in order to learn how SDL is or is not reading
that things key data, which will help you understand where the problem lies
and how to solve it.

On Thu, Sep 3, 2009 at 2:05 PM, pierrelafran...@sympatico.ca 
pierrelafran...@sympatico.ca wrote:

 #include stdio.h
 #include stdlib.h
 #include /usr/include/SDL/SDL.h

 int MySDL_WaitEvent()
 {
printf(About to call SDL_WaitEvent(event)\n);
SDL_Event event;
SDL_WaitEvent(event);

switch (event.type)
{
printf(In switch/case of SDL_WaitEvent(event)\n);
case SDL_KEYDOWN:
printf(The %s key was pressed!\n,
SDL_GetKeyName(event.key.keysym.sym));
break;
case SDL_QUIT:
exit(0);
}
 }


 int MySDL_PollEvent()
 {
printf(About to call SDL_PollEvent(event)\n);
SDL_Event event;
while ( SDL_PollEvent(event) )
{
switch (event.type)
{
printf(In switch/case of SDL_PollEvent(event)\n);
case SDL_MOUSEMOTION:
printf(Mouse moved by %d,%d to (%d,%d)\n,
event.motion.xrel, event.motion.yrel,
event.motion.x, event.motion.y);
break;
case SDL_MOUSEBUTTONDOWN:
printf(Mouse button %d pressed at (%d,%d)\n,
event.button.button, event.button.x, event.button.y);
break;
case SDL_QUIT:
exit(0);
}
}
 }

 int main(int argc, char *argv[])
 {
printf(About to call SDL_Init()\n);
if ( SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO)  0 )
{
//fprintf(stderr, Unable to init SDL: %s\n, SDL_GetError());
printf(Unable to init SDL: %s\n, SDL_GetError());
exit(1);
}
while(1)
{
printf(About to call MySDL_PollEvent()\n);
MySDL_PollEvent();
printf(About to call MySDL_WaitEvent()\n);
MySDL_WaitEvent();
}   //  while

printf(About to call atexit()\n);
atexit(SDL_Quit);
 }

 --
 Pierre Lafrance
 --

Re: [pygame] Picking monitor...

[Brian Fisher]

On Fri, Aug 28, 2009 at 10:08 AM, Gene Buckle ge...@deltasoft.com wrote:

 The main issue is that the avionics computer will have more than a couple
 of these USB video adapters.  Is it possible to discover the current window
 position from within pygame?  That would allow me to manually position the
 window and then save the current position as the start position.

 Hey Gene,
   stuff like that is always possible - and ctypes is usually the best way
to do little hack stuff like this in python.

For getting the window pos, the function pygame.display_get_info gives you
a dictionary with window set the HWND of your window, and the OS function
GetWindowRect can be called on that HWND to get the window position/size

The code below is getting the pygame window's position just fine for me on
windows:
-
import pygame

from ctypes import POINTER, WINFUNCTYPE, windll, WinError
from ctypes.wintypes import BOOL, HWND, RECT
_prototype = WINFUNCTYPE(BOOL, HWND, POINTER(RECT))
_params = (1, hwnd), (2, lprect)
GetWindowRect = _prototype((GetWindowRect, windll.user32), _params)
def _errcheck(result, func, args):
if not result:
raise WinError()
return args
GetWindowRect.errcheck = _errcheck

def GetPygameWindowPos():
info = pygame.display.get_wm_info()
window_id = info[window]
r = GetWindowRect(window_id)
return (r.left, r.top, r.right, r.bottom)

pygame.display.set_mode((400,400))
print GetPygameWindowPos()

Re: [pygame] Picking monitor...

[Brian Fisher]

On Sun, Aug 30, 2009 at 7:11 PM, Gene Buckle ge...@deltasoft.com wrote:


  DirectX actually works ok.  At least the windowed test apps I've dug up
 appear to work ok.

DirectX actually provides software rendering backends for most things it
does, so it's still entirely possible the USB has no 3D acceleration and the
samples are software rendering using the directX api... but you may not care
about 3d acceleration in the end, depending on what you are doing anyways.

With the OpenGL stuff, it sounds like your window is being created on the
main display, is that right? If so, I'd guess that what's happening is you
are getting hardware acceleration on your main adapter, which means that
when you move the window from one monitor to the other, you just switched it
over to be displayed by another device which doesn't have your openGL
context or your textures or display lists or vertex buffers or whatever.
It's still possible that you can get an OpenGL context on those auxillary
adapters (Windows XP should be providing a software rendering opengl 1.1
implementation for devices without opengl drivers), but you probably need to
make sure the window starts on the auxillary device to begin with, so the
opengl context gets created correctly - which you *might* be able to do with
that SDL_WINDOW_POS environment var thing



 The 7 LCD is a TV set being fed through a VGA-composite device.  I was
 planning on no higher than 800x600.  Since there are really no true 3D
 elements to the PFD or Nav displays, it shouldn't be a problem to be
 software-only rendered.

 Is there any rotation, scaling or coloring? Any shader effects? cause if
you are just blitting images, it would probably be a piece of cake to adapt
what you have to use pygame/sdl's software rendering, and then the opengl
context thing is no problem.

Re: [pygame] Picking monitor...

[Brian Fisher]

On Fri, Aug 28, 2009 at 8:43 AM, Gene Buckle ge...@deltasoft.com wrote:


 Thanks James.  Not exactly the news I was hoping for. :(  I'm working on a
 glass cockpit display called RJGlass that's written in Python and uses both
 pygame and PyOpenGL.  I'm going to use it in a cockpit project I'm working
 on, but I need to make it run on a 7 LCD panel I've got connected to a USB
 VGA adapter.

 Is there a bleeding-edge version of pygame that is available and uses the
 SDL 1.3 libraries?  I don't know if it matters, but I'm using Windows for
 this.

 There is no bleeding edge version of pygame I'm aware of, but since you are
doing a specialised app for a single platform, you might be able to hack
something together using the environment variable:
SDL_VIDEO_WINDOW_POS

you set it to a string of the form x,y before calling pygame.display.init
or pygame.init in order to say where you want the window created, and
depending on how your second monitor is configured, you may be able to
position the window to start on the second monitor, which *may* cause
fullscreen mode to keep to that monitor (but probably not)

another option would be to make your small monitor primary in windows

another is to not use windows fullscreen at all (note that pyglet which was
suggested doesn't use windows fullscreen for it's fullscreen, it instead
makes a window covering the whole screen). You can probably do that same
thing in pygame with a combination of the SDL_VIDEO_WINDOW_POS
environment variable, your window's size, and some init flags to  make your
screen frame-less.

good-luck.

Re: [pygame] freetype merge and the Spectacularly Adequate Automated Pygame Build Page Re: [pygame] Documentation changes in trunk

[Brian Fisher]

In terms of getting the build bots building,

For windows, all dependencies the build bot uses need to be included in
pygame's prebuilt dependencies package for both visual c runtimes, and when
there is an updated prebuilt dependencies package, I'll copy it over so the
windows buildbots will use it.

For Mac OS X, dependencies need to be hand installed on the build bot, so I
need to know what packages those are (if there are no packages, it's fine
just to know what place the python build script will look for them)

---
For some background and pygame Mac OS X and windows packages...

good software deployment on OS X and windows is not like good software
deployment on ubuntu or any other linux flavor.

On windows there is no package management whatsover, and on Mac OS X there
is no package management which is practical for anything but a minority of
users. So when it comes to pygame's binary (i.e. not python) dependencies,
those things need to be either statically linked (as portmidi, jpeglib and
some others are on mac) or need to be bundled with the distribution package
(as SDL is on both platforms and most other dll's are on windows)

Also, it can be very difficult and error prone to try and find or build the
windows dependencies with pygame, and traditionally getting together the
prebuilts was a major obstacle for windows users to build pygame themselves
(building the dependencies is way way more complicated than building
pygame), which is why there has almost always been official packages of the
prebuilt dependencies for windows. I personally consider having such a
package put together for the new pygame version to be something that has to
happen before a new version can be released.

Finally, when it comes to developing the build scripts, pygame developers
should take special care to make sure neither the os x nor the windows
setup.py scripts ever put together an install package that requires any
runtime dependencies that aren't a standard part of the OS distribution to
be separately installed.


On Tue, Aug 18, 2009 at 10:22 AM, Vicent Marti tan...@gmail.com wrote:

 Hey René,

 I've just fixed the first issue (the config script was choking because
 I had split the source files in Setup.in amongst different lines). The
 FreeType module now won't compile if the required libraries cannot be
 found.

 Now, how would we go about installing FreeType on the buildbot? It's
 as easy as issuing 'apt-get install freetype2-dev', assuming it's
 running on Debian or Ubuntu, but I obviously don't have root access.

 Cheers,

 Vicent Martí
 http://www.bellverde.org



 On Tue, Aug 18, 2009 at 11:12 AM, René Dudfieldren...@gmail.com wrote:
  On Mon, Aug 17, 2009 at 9:41 AM, René Dudfieldren...@gmail.com wrote:
  nice one :)
 
  Have a look here:
  http://thorbrian.com/pygame/builds.php
 
  You'll notice that there's some errors building on windows, and osx.
 
 
 
  Hi,
 
  I think the freetype merge requires freetype to be installed.  However
  it doesn't check to see if it's installed before trying to build it.
 
  This is what is causing the build bot to fail to build, because it
  only has the minimum dependencies required to build pygame.  Currently
  freetype isn't a dependency - only SDL_ttf is.
 
  1. pygame trunk needs to see if freetype-dev is installed before
  trying to build the freetype package.
  2. build bots need to have the freetype packages installed.
 
  I just tried to disable the freetype module until those two things are
  sorted out.  So the build bot can build again without errors.  I just
  commented it out in Setup.in ... hopefully that will be enough to
  disable it.
 
 
 
  cheers,
 

Re: [pygame] how to remove spam comments in pygame wiki

[Brian Fisher]

It makes me sad to hear a web designer say that :(

I do respect how difficult and limiting designing for full horizontal
scaling can be, but quite frankly the web is simply better full width. Also,
I think to imply that usability suffers for all non-fixed width designs is
an obviously wrong statement, and in my opinion, just a cop out. In my
experience, google  amazon made the right choice letting the content grow
horizontally. Do you find their pages to have poor readability and
usability? Cause if you do, the objective formalized testing with real
customers those companies have done disagrees with your opinion.

 also, I think you are mistaken in believing that a website could
possibly set how many characters per line a browser shows.

All that being said, I'm terribly sympathetic with how hard the web design
stuff can be as your testing matrix of browsers and window widths explode,
and I'd never judge somebody for sticking with fixed width restrictions for
that reason. Just please don't claim it's better for the user. :)


On Fri, Jul 31, 2009 at 2:10 PM, Devon Scott-Tunkin
djvonfun...@yahoo.comwrote:


 As the designer of the new site I'm against that idea on principle.

 I really hate using pages with no max width on widescreen monitors as it
 forces me to resize my window to read the pages.  Readability and usability
 suffer with expanding width pages after a certain width, which is why I like
 having max widths.  I don't think any readability is gained by having more
 than 80-100 characters per line, and that readability and usability is
 actually hindered.  I could probably increase the max width slightly, but I
 do not want it over 100 characters for the main page column, it is at 80
 something now I believe.

 Devon

 --- On Thu, 7/30/09, Greg Ewing greg.ew...@canterbury.ac.nz wrote:

  From: Greg Ewing greg.ew...@canterbury.ac.nz
  Subject: Re: [pygame] how to remove spam comments in pygame wiki
  To: pygame-users@seul.org
  Date: Thursday, July 30, 2009, 8:01 PM
  Ian Mallett wrote:
 
   It's harder to read because the page is narrower.
 
  I would say don't try to control the page width at
  all. Let it flow to whatever size the browser window
  is.
 
  -- Greg
 
 
 

Re: [pygame] how to remove spam comments in pygame wiki

[Brian Fisher]

Hey Jug (and Devon),
Open Source has never been something that implies anyone can contribute
to anyone else's work. It doesn't mean that people will work together. It
doesn't mean that decisions are made democratically or by consensus - it
doesn't mean that people will compromise with each other. The fact is most
successful open source projects are run by dedicated individuals who pretty
much do what they want and think is best (Linux and Python come to mind).
The history of all such projects is filled with numerous examples of both
well meaning and talented individuals doing good work that is rejected by
maintainers for various reasons. Help is frequently refused.

When comes to people actually collaborating on open source stuff, really
it's just a bunch of individuals doing exactly what they feel like doing and
what they think is best (cause their work is on their spare time). Sometimes
interests align so people work together. Sometimes somebody just has solved
a particular problem before and is willing to share. Patches are usually
accepted. All the normal things of people not getting along and having
trouble working together, and splitting off and going different directions
happens. Open Source isn't some magic thing that changes any of that.
Believing that it is, is setting yourself up for disappointment.

...In fact, the truly great thing about Open Source is that it is set up to
embrace the parts of human behavior and nature to do what they want and go
in their own direction. The source belongs to everybody, and nobody can put
restriction on it. Everybody is free to fork, redistribute, cannibalize and
transform the product in any way they want, as long as it stays free for
others to do so as well. Also, with the pygame name, presumably in the
spirit of open source, there are no trademark declarations (registered or
not), so there's no licensing issues or restrictions with using the pygame
name. So anybody can promote or advertise the name however they want.

My point is, nobody is trying to stop you from building exactly what website
or sites you want, regardless of how it relates to pygame or advertises
itself. And even if anyone was trying to, legally they could not stop you.
If you want to provide value for the pygame community with a kick-ass site,
I say please do. And do exactly what you think is best. I do appreciate you
polling the user list for feedback, and I'd be happy to give some when I
have it and I'll do my best to be constructive. If the site offers
significant and real value above the current one, I'd visit it and use it.
If it doesn't, then I'd use what already exists, cause it's got inertia
behind it and it's already tested and established. I'm sure many other
mailing list people and many other pygame users feel the same.

As far as the pygame.org name, and running code on the current
pygame.orgweb servers, the people who control them don't see value in
opening those
things up to the project you are working on now. Maybe if you have something
awesome and/or make it easy enough to switch over they'll feel different,
then again maybe they won't. But either way, nobody's stopping you from
making a good pygame website, if that's what you want to do.


On Fri, Jul 31, 2009 at 2:43 AM, jug j...@fantasymail.de wrote:

 René Dudfield wrote:

 Hello Jug,

 I'm not interested in working with you or your website.  This is the last
 reply I'll make to you.

 bye.

 PYGAME - An Open Source Community Project

 haha, good joke!

Re: [pygame] Improving pygame web docs

[Brian Fisher]

I really didn't notice the background myself, so I don't think it's a
problem.

What does actually bug me though, is the project list down the right side. I
appreciate wanting to make the project listings a focus of the site, but
it's taking up space and distracting from the focus of a page where I told
you by clicking on things that what I want to do right now is read
documentation. Plus it makes stuff weirdly off center as I scroll down.


On Fri, Jul 31, 2009 at 2:20 PM, Devon Scott-Tunkin
djvonfun...@yahoo.comwrote:


 The background is too busy, IMHO

 I thought it looked good, but I can see how it is busy with such a large
 texture repetition, although it doesn't seem to negatively effect me when
 using the site. The plain gradient was too boring for me, at least when it
 was the extreme colors it used to be. Perhaps I am too attached to the
 effect of layering two backgrounds over each other. Yay css :).

 Do you think larger or smaller circles would look better, or perhaps even
 more transparency? Or can you suggest a different texture, I thought circles
 were fun and reminded me of snake skin. Both perfect for pygame.

 Devon


 --- On Thu, 7/30/09, RB[0] roeb...@gmail.com wrote:

  From: RB[0] roeb...@gmail.com
  Subject: Re: [pygame] Improving pygame web docs
  To: pygame-users@seul.org
  Date: Thursday, July 30, 2009, 9:19 PM
  The background is too busy, IMHO
  And I agree with what greg wrote...
  Otherwise, looking good :)
 
  On Thu, Jul 30, 2009 at 7:55 PM,
  Greg Ewing greg.ew...@canterbury.ac.nz
  wrote:
 
  jug wrote:
 
 
 
 
  http://pygameweb.no-ip.org/docs/surface.html
  ist not really easy to read, but I don't know exactly
  why.
 
 
 
 
  It looks all right to me, except for one thing: Every
 
  link to the docs for a method embedded in the text
 
  seems to be followed by a comment in small print, e.g.
 
  in the paragraph about Surface.convert,
 
 
 
...arguments can be used, similar to the
 
pygame.Surface - [pygame object for representing
 
images] call...
 
 
 
  IMO these embedded comments are pointless and
 
  distracting and make the text hard to read. Just
 
  make the method name into a link and leave it at
 
  that.
 
 
 
  Also a minor suggestion would be to leave some
 
  space between the heading for a method and its
 
  call prototypes, and between the prototypes and the
 
  following text, e.g. instead of
 
 
 
Surface.convert - change the pixel format of an image
 
  Surface.convert(Surface): return Surface
 
  Surface.convert(depth, flags=0): return Surface
 
  Surface.convert(masks, flags=0): return Surface
 
  Surface.convert(): return Surface
 
  Creates a new copy of the Surface with the pixel
  format
 
  changed. The new pixel format can...
 
 
 
  space it out slightly:
 
 
 
Surface.convert - change the pixel format of an image
 
 
 
  Surface.convert(Surface): return Surface
 
  Surface.convert(depth, flags=0): return Surface
 
  Surface.convert(masks, flags=0): return Surface
 
  Surface.convert(): return Surface
 
 
 
  Creates a new copy of the Surface with the pixel
  format
 
  changed. The new pixel format can...
 
 
 
  Also generally leave space between paragraphs if
  you're
 
  not going to indent the first line of each paragraph.
 
  Otherwise the text tends to look like one huge paragraph,
 
  which is not good for reading.
 
 
 
  --
 
  Greg
 
 
 
 

Re: [pygame] how to remove spam comments in pygame wiki

[Brian Fisher]

On Wed, Jul 29, 2009 at 11:55 AM, jug j...@fantasymail.de wrote:

 Yeah, sorry. It uses simple text files with an own simple structure and
 markup. So, it's not as bad as I thought. But still bad. IMHO, bad enough to
 be replaced.
 It *is* something self-made, the html and css is *hardcoded* into the
 generator script and therefore it *is* impossible to change easily. Finally,
 the output *is* ugly and *invalid* (
 http://validator.w3.org/check?uri=http%3A%2F%2Fwww.pygame.org%2Fdocs%2Fref%2Fsurface.html
 ).

 However, after some trial and error and some changes on the generator code,
 I got the docs integrated into the website (used code from svn, so docs are
 for pygame 1.9.0):
 http://pygameweb.no-ip.org/docs/

 So, if no one is interested in a more professional documentation system, we
 should at least update the generator script to produce some more valid code,
 use a simple template for html and css and become a bit more configurable.

Julian,
   good job on working with current documentation content to get a page
working. However I have to say that I do not find this page:
http://pygameweb.no-ip.org/docs/

to be any improvement at all over this page:
http://www.pygame.org/docs/

I don't think the aesthetics or usability have been improved. But my real
critique of it is that you dropped what I considered to be a highly
effective and useful format for documentation - to have single page docs for
a module, where the top half of the page is functions for the module that
links down to the dull description later on the same page.

The problem is that with your main page being a list of all modules and
their functions together, it's hard to get a good overview of the modules
compared to a list of each module with short descriptions. Likewise, once
I've decided a module is for me, and choose to go to it's page to drill into
it, I don't get a clear and simple overview of that module.

I hope the doc pages are something you continue to improve from the
perspective of easily getting overviews of things and getting a high level
picture of what the library has to offer.

And lest you think I'm biased, I didn't do a single thing to work on the
current pygame website or doc system, and have no particular love of the
current website. I just happen to have had a really great experience working
with pygame's website doc pages over the years - it's always been a lovely
experience to browse them for me because it's so easy to get a high level
picture and find what I want. I find them to be far more usable and
effective than python's own doc web pages, which are at times overwhelming
and impossible to get a good high level view from (like say the urllib 
firends docs for instance - where you don't even know what classes or
modules you want to use, and once you do have a guess at that, it's hard to
find a useful function).

Re: [pygame] strange compile error with cocoa

[Brian Fisher]

Hey Grtz,
   The problem is easy enough to find from the output you posted, it's the
line:

   #import Cocoa/Cocoa.h

Which you appear to have added in your branch here:
http://github.com/ab3/pygame-mirror/blob/859415df2392bb35d31df13b8d1c4ccc4a278ed5/src/camera.h

You are mixing objective-c code with c code, as Rene pointed out. That's bad
because objective-c is a strict super-set of c, and those super bits look
like errors to c compilers.

Whatever the problem was that you were trying to solve by adding that line,
you need to solve a different way.


On Sun, Jul 12, 2009 at 9:08 AM, el lauwer el.lau...@gmail.com wrote:

 In file included from
 /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreData.framework/Headers/CoreData.h:23,
 from
 /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:14,
 from src/camera.h:49,
 from src/_camera.c:36:

 you can find the source on http://github.com/ab3/pygame-mirror/tree/master

 I have been looking at this error for a long time, so if someone wants to
 give it a try, you are welcome...

 Grtz

Re: [pygame] [BUG] midi unit test for Pygame rev 2500, Python 2.6.2, Windows XP

[Brian Fisher]

The svn builds get what I think is the same error but only on python 2.4:
http://thorbrian.com/pygame/builds.php

Note they've had the bug for a long time - but the portmidi debug prints
were a red herring that obscured it.


On Thu, Jul 9, 2009 at 3:21 PM, Lenard Lindstrom le...@telus.net wrote:

 Hi,

 The Python 1.9.0 rc 3 unit tests fail with the following midi related bug:

 ==
 ERROR: MidiTest.test_get_device_info
 --
 Traceback (most recent call last):
  File C:\python26\lib\site-packages\pygame\tests\midi_test.py, line 400,
 in t
 est_get_device_info
   raise Exception(repr(r))
 Exception: None

 --

 Lenard

Re: [pygame] physics engine?

[Brian Fisher]

The quality of chipmunk and box2d is so incredibly good and is built off of
such a depth of experience by the authors that if you want really actually
do want a 2d physics engine (i.e. you're not just looking for stuff moving
and hitting each other, you want stacking, joints, friction, etc) you would
be utterly and completely silly in every way to even consider anything else

Between pymunk and pybox2d, personally I greatly perfer pybox2d because
box2d is more feature rich, is more stable with bouncy objects and it's
continuous collision detection (actually continuous collision response using
binary search time of collision) makes it much more stable and predictible
particularly with fast moving objects.

chipmunk was branched from box2d to add a performance feature, and you can
sum up it's difference from box2d as faster and easier to use provided you
are doing just what it does well.

seriously, in the picture of 2d physics engines, they are both super
wonderful. you want stacking, friction, joints, etc, in 2d they are the only
real options. You want motors and gears and fast moving objects, you
probably want pybox2d.

If you just want stuff moving and hitting each other though, and you want to
control exactly how things move or behave, or you know you want unphysics-y
stuff to happen a lot, you would probably end up struggling a lot with any
physics engine to get things to work out the way you want them to.

On Thu, Jun 18, 2009 at 6:25 PM, machinim...@gmail.com 
machinim...@gmail.com wrote:

 hi,

 what 2d physics engine would you recommend for using with pygame?

 what happened to the SOC physics project? is it finished? will it be
 included in pygame?

Re: [pygame] Color, unpacking to r,g,b and r,g,b,a - ValueError: too many values to unpack

[Brian Fisher]

You could also just let those 2 functions return exactly what they did
before, no color obj for them...

On Wed, Jun 17, 2009 at 2:02 PM, Lenard Lindstrom le...@telus.net wrote:

 Hi Tyler (and Ian),

 In most cases colors are length 4. But in Pygame 1.8.1 and earlier the
 Surface palette methods get_palette and get_palette_at return 3-tuples.
 Pygame 1.9 will return color instances instead. For compatibility the se
 color instances must also be length 3. As for a default alpha, that is 255,
 which is now consistent throughout Pygame.

 Lenard


 Tyler Laing wrote:

 Hi Lenard,

 But are there any situations where one MUST have 3 elements colors only?
 If not, then just fill in a reasonable default value for times when there
 isn't an alpha value for the picture.

 -Tyler

 On Wed, Jun 17, 2009 at 9:31 AM, Lenard Lindstrom le...@telus.netmailto:
 le...@telus.net wrote:

Hi Tyler,

Well, one wants 4 element colors when working with per-pixel-alpha
surfaces.

Lenard


Tyler Laing wrote:

Why don't we just fill in a full value of 255 for all the
cases where it returns 3 values? If we make every call return
four values, and warn about this in the documentation, it
becomes very consistent.

-Tyler

On Tue, Jun 16, 2009 at 11:52 PM, Lenard Lindstrom
le...@telus.net mailto:le...@telus.net
mailto:le...@telus.net mailto:le...@telus.net wrote:

   René Dudfield wrote:

   On Wed, Jun 17, 2009 at 4:29 PM, Lenard
   Lindstromle...@telus.net mailto:le...@telus.net
mailto:le...@telus.net mailto:le...@telus.net wrote:
 René Dudfield wrote:
   Hi,

   one issue with the new Color type is unpacking to
   r,g,b or r,g,b,a.

   In some places Color is assumed to return
(r,g,b) and
   others
   (r,g,b,a), and now many things return a Color
rather
   than a tuple.

   So I want to change Color to unpack to r,g,b,a
or r,g,b.

   r,g,b = pygame.Color(1,2,3,4)
   r,g,b,a = pygame.Color(1,2,3,4)

   Anyone have an idea how this can work?  Either
in C or
   python?

   This is to keep backwards compatibility.


   cheers,

 Hi René,

   Are there cases where this is breaking code? For
the most
   part I believe
   Pygame functions returned 4-tuples. So Color is just
   pretty much a drop-in
   replacement. If a program is using tuples to
declare color
   values then the
   size is already known and unpacking is not a
problem. It is
   Surface.get_palette and get_palette_at, which
originally
   returned 3-tuples,
   where we run into problems. So here are the choices
I see.
   One, just accept
   that the new get_palette and get_palette_at will break
   things, just as any
   program that tries to use a color return value as a
   dictionary key will now
   break. How many programs actually use color palettes
   anyway? Two, give Color
   a size property. If alpha is set None it becomes
length 3.
   But then how does
   one represent this internally without adding
another field
   to the Color C
   structure? Declare the color component values as C
ints?
   Three, create a new
   Color subtype of length 3 having a fixed alpha of
255. I'm
   not happy with
   any of the choices but prefer three. Any other ideas?

   Lenard



   hi,

   yeah for example in solarwolf:
File solarwolf-1.5/code/gamemenu.py, line 70, in
   load_game_resources
  pal = [(g,g,b) for (r,g,b) in origpal]

File solarwolf-1.5/code/objshot.py, line 28, in
   load_game_resources
  for (r,g,b) in origpal]


   hrmm.  I think a 3 element Color subtype might be the
way to go.
   Maybe we don't even need a subtype, but just a length
property
   that
   can be 1,2,3, or 4?  As you say get_palette(_at) could
return
   len 3
   Colors.

   If it could unpack to 3, or 4 depending on the number of
   elements on
   

Re: [pygame] Color, unpacking to r,g,b and r,g,b,a - ValueError: too many values to unpack

[Brian Fisher]

On Wed, Jun 17, 2009 at 6:12 PM, René Dudfield ren...@gmail.com wrote:

 Yeah, that's another option to consider.  Except returning Color is so
 much nicer to use than a tuple for colors (and slightly quicker... but
 that's not a big point).  Also it should be more consistent to have
 all the methods returning Colors for colors.

 My response on the consistency front would be:
1. that I would rather a color object be consistent in how it unpacks than
be inconsistent based on some length option for the sake of old code
2. the new version of pygame would not be adding any new inconsistency by
making the palette stuff return 3-tuples instead of color object - clearly
the palette functions were already inconsistent with the rest of
color-getting functions, otherwise we wouldn't have this problem to deal
with.

... so I assume a palette can not take alpha, which is why the functions
didn't return one, right? it seems like to have those functions return an
object which even has an alpha member would be an opportunity to allow for
confusion about what should work.

Re: [pygame] Alpha channels and per pixel alpha

[Brian Fisher]

It would help to see your code and have an example image attached, cause
loading .png's with alpha and blitting with transparency works fine for me
without any trouble or special stuff.

On Wed, Jun 10, 2009 at 2:11 PM, Bjorn Samuelsson bjorn_...@hotmail.comwrote:

  Hey all,

 I'm trying to make a small 2d game and I'm wondering how you would go about
 to load a png-image with an alpha channel and keep it's alpha values?
 I have confirmed the images alpha channel but when i load it in pygame it's
 alpha values are always 255.
 I've tried Surface.convert_alpha but that doesn't make a difference.
 At the moment I've resorted to saving my alpha channels separate and
 loading both image and alpha channel so that i can call Surface.set_at to
 change the image's per pixel alpha value.
 But that solution seems less than optimal so i figured i would ask you
 guys.

 regards
 Björn

 ps. I apologize if this topic has been discussed at length already but i've
 been looking around and i just can't seem to find a simple solution. ds.

 --
 Invite your mail contacts to join your friends list with Windows Live
 Spaces. It's easy! Try 
 it!http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us

Re: [pygame] Problem with display.update(rectangle_list)

[Brian Fisher]

You are not processing events in the example script here - when you aren't
processing events, then various platform specific window manager things that
need to happen for your window to draw correctly don't get to happen.

If you don't need any of pygame's events, then you should just be calling
pygame.event.pump() in each pass of your main loop, but most likely you'll
ultimately want to be calling pygame.event.get() and iterating through the
returned event list to respond to various things that can happen (like your
window losing focus for instance)


On Wed, Jun 10, 2009 at 5:01 PM, Michael Leach easily.remembered.name@
gmail.com wrote:

 Hi, I'm fairly new to pygame, and I tried posting this before, but I
 don't think it went through (sorry if this is the fourth posting... I'm
 having a fail-day).

 The issue I'm having is with pygame.display.update(rectangle_list). It
 doesn't seem to update correctly when I pass a rectangle list with
 some surface.get_rect()'s (specifically, the surfaces are rendered
 fonts), but it works just fine with a drawn rectangle list passed in
 or when I leave out the argument entirely.

 The weirdest thing to me is that even the surface rectangles will work
 if I move the window outside of the screen (as in I drag the pygame
 window outside of my monitor space) and then bring it back to the
 visible desktop. However, if I only drag it out partially, only the
 part that left the screen will come back in updated correctly.

 Here's some code that is a simplified version of mine:

 while True:
print 'running loop'
rects = []
w,h = pygame.display.get_surface().get_size()
font = pygame.font.Font(None,92)
white = (255, 255, 255)

surface = font.render(WORDS HERE!,0, white)
rects.append(surface.get_rect())

X = w/2
Y = h*.5


pygame.display.get_surface().blit(surface, (X,Y))
#print rects
pygame.display.update(rects)

pygame.time.delay(100)




 I must be doing this wrong because I've searched everywhere and come
 up with nothing. I'm using pygame 1.8 with Vista x64 and some of the
 best hardware on the market (i7, 4850x2, etc). Help is very much
 appreciated!!

Re: [pygame] BUG: mac OSX can only install into python.org python.

[Brian Fisher]

The rationale for not installing into the system python that I recall was
because apple had been using the system python as a required OS component
for correct system functionality (some os scripts use python), and messing
with the system python could potentially mess up people's systems. I don't
think there is any known case of where installing pygame specifically into
the system python actually does result in such a situation, cause pygame
doesn't touch anything outside of the pygame package, but it was one of
those better safe than sorry things.

As far as having installers that work with the system python, the only way I
know of that bdist_mpkg easily lets you do that, is by running setup.py from
the system python itself, and then what you get is an installer that
installs to system python, but won't install anywhere else. Basically
bdist_mpkg seems to be set up to install to the same config you ran it with.
I'm not sure the original intent of that behavior, but it seems to make some
sense from a testing perspective.

If there's a setup,py option to make an installer that can go to either the
system python or the framework one, I'm not sure what it is, but if a numpy
installer is doing what we want, we should take a look at it's setup,py

As far as multiple versions of a system python existing, I hadn't heard of
apple adding a 2.6 or 3.0 to the mix of system pythons- the machines I have
access to just have the leopard 2.5 (and the tiger 2.3 if they were
upgraded), what situation adds those newer pythons to the
/System/Library/Frameworks/Python.framework/Versions dirs?

Finally, as far as detecting other pythons we might be compatible, when it
comes to OS X installs, I'm not aware of any other install locations other
than /System/Library/Frameworks and /Library/Frameworks or any other python
source trees other than apple's fork or the official python.org one. Did you
have an example in mind of another python install on Mac OS X that pygame
doesn't target now that we'd want to add detection for?

On Mon, Jun 1, 2009 at 5:20 AM, René Dudfield ren...@gmail.com wrote:

 Hi,

 the mac OSX installer should be able to install into the apple python
 site-packages directory.

 Currently it won't let you.  Since we won't be overwriting anything of
 apples, and also Apple have proved that they don't touch their system
 python very much at all, I think this is ok to do.  The original
 rational for it was that apple could possible remove older pythons.
 However over a number of releases they have shown that they keep the
 old version of python around (eg 2.5), and install a new version (2.6
 and 3.0 I believe).

 This will also fix one of the longest running issues people have on
 OSX installing pygame... since most people assume they already have
 python, so why should they install another copy from python.org.

 So... how do we make allow the user to select which python they
 install into?   I know numpy does it somehow... but not sure how
 exactly.

 Our use of bdist_mpkg is what we need to change to allow it... I think.
looks like bdist_mpkg has had some new releases recently too...
 http://pypi.python.org/pypi/bdist_mpkg/

 Looks like it has fixed the bug where it was calling the python.org
 python System python... which people assumed was the Apple python.


 Anyone have any ideas how this can be done?

 Is it ok to do, do you think?  What do you reckon Brian?


 Would be nice if we could detect other mac pythons that we are
 compatible with too.


 cheers,

Re: [pygame] pygame.midi using portmidi?

[Brian Fisher]

since you mentioned the build page - power company turned off power to my
neighborhood for a day, and the mac didn't auto power back on (anybody know
if you can set a mac to do that?), while my PC seems to have had some part
of it fried.


On Sat, May 30, 2009 at 12:25 AM, René Dudfield ren...@gmail.com wrote:


 Hopefully that should pass those tests on the build page, when it comes
 back up.

Re: [pygame] pygame.midi using portmidi?

[Brian Fisher]

On Sun, May 24, 2009 at 9:29 PM, René Dudfield ren...@gmail.com wrote:

  I believe Brian doesn't have portmidi.dll installed.
 

 I definitely don't have any separately installed portmidi shared library on
any machine of mine, but I don't think that one is required on OS X or
Windows for proper operation. I think both build bots are getting at the
portmidi library just fine.

Also, as a rule, I think ever requiring a separately installed and managed
library that's not a standard OS component on Win and Mac is the wrong way
to do things. Those platforms don't have package managers and Kernel
components are quite stable, so therefore is both no good way to manage dll
dependencies and there is no benefit to calling out to a shared separately
managed version of portmidi vs. statically linking/including the version we
tested into pygame, respectively.


I think he does have it installed on at least the windows installs.

 My windows build box has portmidi.dll in the prebuilts dir, so if the setup
for making the installer for pygame picks that dll up properly, then it
should be getting that dll just fine.

from the build output, it looks like the problem is
pygame.midi.get_device_info is returning None - I can tell you my build
machines definitely don't have midi devices (neither physical nor virtual)
configured, and None seems an appropriate return value in such cases. Maybe
it's just the tests are bad for a machine with no midi devices?



 Brian, can you confirm if it's installed on the OSX build bots?

 My OS X machine definitely has the static portmidi library (libportmidi.a)
and header file (portmidi.h) in the right places (/usr/local/lib and
/usr/local/include) because they are getting picked up and built in by
config.py. I built libportmidi.a myself, and I know it's the static lib, not
a linking lib for a dylib or .so or anything like that.



 Also, do you know how to compile portmidi on OSX?  I couldn't get it
 to compile on OSX (if you can't remember I'll try and work it out :).

 Yeah, I just used the xcode project under pm_mac and built the static lib
without any problem - note the makefiles don't work on mac, and I didn't try
a .dylib version (cause I don't see any point to doing so) so it may have
problems building. Once I copied the build products to the right place, they
got picked up fine.

Re: [pygame] Array2d fails with movie_renderframe

[Brian Fisher]

What happens if you use movie.set_display to render to a surface instead of
the screen, and get what you need from the surface?

On Tue, May 26, 2009 at 1:08 PM, Vero E. Arriola
blackzafiro@gmail.comwrote:

 Hello,

 I have been trying to use pygame to access a video frame by frame and
 extract the pixel values.  The frame is correctly rendered.  However,
 numeric and numpy get an array of zeros when I try to get the info from the
 display.  Is this a bug or am I missing something?  The code I use is as
 follows:

 import pygame, sys
 from pygame.locals import *

 filepath = esponja.mpg
 pygame.init()
 pygame.mixer.quit()
 pygame.surfarray.use_arraytype(numpy)

 movie = pygame.movie.Movie(filepath)
 size = w, h = movie.get_size()
 screen = pygame.display.set_mode(size)
 movie.set_display(screen, Rect((0, 0), size))

 def play():
   i = 0
   frame_number = 0
   while(1):
 frame_number = movie.render_frame(i)
 frame = pygame.surfarray.array2d(screen) #copies
 print frame
 if frame_number  i:
   break
 i = i + 1
   movie.rewind()

 I am using ubuntu 8.10.
 Thanks

 --
 Todavía vivimos vuestros abuelos, aún es poderoso nuestro lanzadardos;
 conquistadores y sabios de tiempos antiguos: ¡Volved a vivir!
   Canto de los mexicas a Tlacaélel y Axayácatl, en su única derrota.

Re: [pygame] Array2d fails with movie_renderframe

[Brian Fisher]

normally people just blit one surface to another with the blit method of
the dest surface:
http://www.pygame.org/docs/ref/surface.html#Surface.blit

so instead of this:
frame = pygame.surfarray.array2d(screen2) #copies
pygame.surfarray.blit_array(screen, frame)

you could do this:
screen.blit(screen2, (0,0))

...but if you are getting the frame array anyways for another purpose,
then the blit_array call is a perfectly fine way to go - it shouldn't
perform any different in your case (i.e. not using hardware display
suraces), and it means you are actually rendering what you are working with,
which can be a good thing.


On Tue, May 26, 2009 at 4:02 PM, Vero E. Arriola
blackzafiro@gmail.comwrote:

 Hey! I got a way to make it work.  Is this the way surfaces are supposed to
 be used??? Thanks ;)

 import pygame, sys
 from pygame.locals import *

 filepath = esponja.mpg
 pygame.init()
 pygame.mixer.quit()
 pygame.surfarray.use_arraytype(numpy)

 movie = pygame.movie.Movie(filepath)
 size = w, h = movie.get_size()
 screen = pygame.display.set_mode(size)
 screen2 = pygame.Surface(size)
 movie.set_display(screen2, Rect((0, 0), size))

 def play():
   i = 0
   frame_number = 0
   while(1):
 frame_number = movie.render_frame(i)
 frame = pygame.surfarray.array2d(screen2) #copies
 print frame
 pygame.surfarray.blit_array(screen, frame)
 pygame.display.flip()

 if frame_number  i:
   break
 i = i + 1
   movie.rewind()

Re: [pygame] Better Python music playback?

[Brian Fisher]

If you just give up on the streaming part of things, mixer does all that
easy.
http://www.pygame.org/docs/ref/mixer.html

So why do you think you need streaming? I think on any OS X, Windows or
Linux box having your 2+ tracks loaded in memory should not be a problem.


On Sun, May 24, 2009 at 4:39 PM, Zack Schilling zack.schill...@gmail.comwrote:

 I'm looking for something a little more complex than the pygame-wrapped SDL
 music mixer to use with my pygame project. I need something that's
 cross-platform (Mac OS X, Windows, Linux), easy-to-use, and supports the
 following features:

 2+ tracks simultaneously
 Streaming ogg playback
 Seamless looping
 Gapless playback
 Fade in/out
 Precise timing info (like the way the SDL reports playback time in
 milliseconds )

 Any suggestions for what I could use? How does Frets on Fire work? Whatever
 they use seems ideal in terms of features.

 Thanks,

 -Zack

Re: [pygame] BUG, Userevents disapears in pygame 1.9

[Brian Fisher]

FYI, those builds are generally from a very recent svn revision. You can see
what revision by printing the:
pygame.version.ver string

On Tue, May 12, 2009 at 8:43 AM, Bo Jangeborg b...@softwave.se wrote:

 I am not using SVN, I am using the latest build from
 http://thorbrian.com/pygame/builds.php

Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[Brian Fisher]

My automated build machine is having the same problem on OS X, so I'd say
it's nothing wrong with your setup:
http://thorbrian.com/pygame/builds.php

On Sun, May 3, 2009 at 12:14 AM, el lauwer el.lau...@gmail.com wrote:

 Oi,

 Ok, I will use git as for my daily work, and submit my code to svn if
 I need a global feedback.

 I have solved the problem with architecture, but now I get the following
 syntax error in the pygame code:

 rc/transform.c:57: error: syntax error before ‘_state’
 src/transform.c:58: warning: initialization makes integer from pointer
 without a cast
 src/transform.c:59: error: ‘filter_shrink_X_ONLYC’ undeclared here (not in
 a function)
 src/transform.c:59: warning: excess elements in scalar initializer
 src/transform.c:59: warning: (near initialization for ‘_state’)
 src/transform.c:60: error: ‘filter_shrink_Y_ONLYC’ undeclared here (not in
 a function)
 src/transform.c:60: warning: excess elements in scalar initializer
 src/transform.c:60: warning: (near initialization for ‘_state’)
 src/transform.c:61: error: ‘filter_expand_X_ONLYC’ undeclared here (not in
 a function)
 src/transform.c:61: warning: excess elements in scalar initializer
 src/transform.c:61: warning: (near initialization for ‘_state’)
 src/transform.c:62: error: ‘filter_expand_Y_ONLYC’ undeclared here (not in
 a function)
 src/transform.c:62: warning: excess elements in scalar initializer
 src/transform.c:62: warning: (near initialization for ‘_state’)
 src/transform.c:62: warning: data definition has no type or storage class
 src/transform.c: In function ‘surf_scalesmooth’:
 src/transform.c:1416: warning: passing argument 3 of ‘scalesmooth’ from
 incompatible pointer type
 src/transform.c: In function ‘surf_get_smoothscale_backend’:
 src/transform.c:1437: error: request for member ‘filter_type’ in something
 not a structure or union
 src/transform.c: In function ‘surf_set_smoothscale_backend’:
 src/transform.c:1443: warning: initialization from incompatible pointer
 type
 src/transform.c:1497: error: ‘filter_type’ undeclared (first use in this
 function)
 src/transform.c:1497: error: (Each undeclared identifier is reported only
 once
 src/transform.c:1497: error: for each function it appears in.)
 src/transform.c: In function ‘inittransform’:
 src/transform.c:2739: warning: assignment from incompatible pointer type
 lipo: can't figure out the architecture type of: /var/tmp//cc47AiT3.out
 error: command 'gcc' failed with exit status 1

 Slu




 On 3-mei-09, at 07:48, Nirav Patel wrote:

  I personally found/find it useful to use a personal git repo, and use
 git-svn to stay up to date with the Pygame SVN.  You can use git svn
 rebase to keep your repo up to date with upstream and then commit
 with git svn dcommit when you have code that others can
 use/test/hack.

 There is a decent guide for using git-svn with github here:
 http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/

 That is also useful so you have a repo to work in until 1.9 is
 released and you can start committing to Pygame SVN.

 Nirav

 On Sun, May 3, 2009 at 1:10 AM, René Dudfield ren...@gmail.com wrote:

 Hi,

 more below...

 On Sun, May 3, 2009 at 2:50 PM, el lauwer el.lau...@gmail.com wrote:


 Oi,

 I am installing the latest version of pygame on svn,
 so I can start coding on my camera module. I am
 installing it under virtualenv so I can keep using
 the stable pygame release for my current games.

 1)
 I recently reseaved a svn account for the pygame
 svn repository. How do you sugest I use this account
 during the development prossess, should I use it to
 commit all my changes to the main brange, or should
 I make a personal brange just for my work on the
 camera module. Can I use my github account instead,
 if so, what must I do with the changes and bug
 fixel to the main pygame development brange.



 You might want to work on the main trunk, or not... depending on a number
 of
 things.

 Either a separate branch or in your git hub is probably a good way to go.
 If you put things in svn, then it's easier for some of the pygame
 developers
 to watch your work, and maybe even make changes.  However it's up to you.

 Best to merge your work in occasionally into a svn branch at least.   Or
 send the mailing list a link to your work when you've committed something
 you'd like people to look at or merge in.

 Then when your work is getting along, talk about merging it into the
 trunk
 with the mailing list and other developers.  If no one has changed any of
 the files you have changed, then it's probably ok.

 Working in the trunk lets you take advantage of some other things... like
 the build bots which build on mac/win python2.4 python2.5 python2.6 and
 run
 the tests for you.  So it can save you a lot of testing work.

 Say you wanted to make some changes to surface.c and a bunch of others
 that
 aren't part of the camera module directly, and didn't commit to trunk for
 a
 few weeks... there's a good chance someone else 

Re: [pygame] Cairo + SDL

[Brian Fisher]

I'm pretty sure pycairo and pygame are already interoperable:
http://www.pjblog.net/index.php?post/2006/06/23/144-using-pycairo-with-pygame-surface

I think you may also be able to do something like this to do pretty much
exactly what that page you linked to does:
--
width = 100
height = 100
pygame_surf = pygame.Surface((width, height), 0, 32, (0xff, 0x00ff00,
0xff, 0))

data = pygame_surf.get_buffer()
stride = pygame_surf.get_pitch()
cairo_surf = cairo.ImageSurface.create_for_data(data, cairo.FORMAT_RGB24,
width, height, stride)

-

... but I haven't tested it


On Sat, May 2, 2009 at 10:16 AM, Chris McCormick ch...@mccormick.cx wrote:

 Hi all,

 Recently there was some talk of doing vector graphics in Pygame. Since this
 is
 a subject that is dear to me, I thought I'd ask how hard it would be to
 incorporate something like this into Pygame:

 http://cairographics.org/SDL/

 I realise this probably implies a large amount of work, but I just thought
 I'd
 throw it on to the collective heads-up-display. Would be pretty wonderful
 to be
 able to use Cairo's rendering capabilities from inside Pygame! :)

 Best,

 Chris.

 ---
 http://mccormick.cx

Re: [pygame] vector type: mutable or immutable

[Brian Fisher]

I guess making both would be the most pythonic - python gives you both lists
and tuples...

On Fri, May 1, 2009 at 11:04 AM, Jake b ninmonk...@gmail.com wrote:

 Could you make both? Default to mutable, and use VectorConst ( insert
 better name ) where needed.

.offset = Vector3Const(1,2,3)
.vel = Vector3( offset )

 (throw exception when you try to modify a const vector?)
 --
 Jake

Re: [pygame] vector type: mutable or immutable

[Brian Fisher]

On Fri, May 1, 2009 at 9:56 AM, Casey Duncan ca...@pandora.com wrote:

 I think that less memory management overhead and batch operations are
 strong arguments for mutable vectors.

 The less memory management is a performance vs. correctness thing, and
having used both extensively, and flip-flopped between the two multiple
times on what I regularly use, I find that I end up not using the
in-placeness of operations on mutable vectors very much anyways, because
they keep resulting in subtle and annoying bugs. Also, I find that the
in-place stuff makes much harder to read code vs. having and using lots of
canned functions for all kinds of common useful ops (i.e. doing a change of
basis on a vector for instance). My point being, that in my experience, I'm
not actually getting less memory management in practice from mutable
vectors, cause in the end I'm making copies lots and using higher level
functions as opposed to twiddling vectors manually.

Re: Batch operations, seem to me to be something where you'd really want to
allocate the block of vectors all at once anyways, so they already should be
a different beast than a single vector.



 The predicability of immutable vectors is nice, but IMO the convenience and
 flexibility of mutable vectors, along with the consistency with existing
 type like Rect makes them win.

 I agree the convenience and flexibility can be useful (the only case this
matters to me in practice, btw, is wanting to change just one element of the
vector, which is rare, but annoying when you can't do it)

I think consistency with the Rect type is a non-argument for mutability or
not. Practical should win over the notion that all pygame classes should
behave the same. If two things are different in use and results, their
behavior should be adapted to accommodate those differences - in fact having
consistent behavior can drive inconsistency in use.

In my experience, I've never wanted to take the rect property of something,
do some operations on it and introduce a bug that way, and I've never wanted
to use a rect as a key to a dict. However I've written some very confusing
bugs taking a vector property of something and changing it accidentally, and
I've been disappointed I couldn't use a vector as a key to a dict.



 I would argue that it should be possible to treat vectors as immutable if
 you preferred that, which I think is covered by the features proposed so
 far.

 There's no good way to get dict-key-ability from a mutable vector. Using
identity (like what surfaces does) would be bad, cause then two vectors that
are equal wouldn't be the same key, and people wouldn't get that.

Using a hash of the value has the problems of being prone to errors - it's
just too easy to write code that iterates over the keys and accidentally
changes the value of one, magically messing up your dict

Re: [pygame] API draft for vector type

[Brian Fisher]

One aspect of vector class design that I've become more and more a fan of
over time is vector immutability.

So you can't say stuff like:
   vector.x += 2
   vector.x = 5

but instead would have to say stuff like:
   vector += (2, 0)
   vector = vector2d(5, vector.y)

their are a couple reasons to design them that way - first is no one can
ever change your attributes underneath you - which is a bug I've run into
every now and then with mutable vectors, and have had to work around by
having stuff contruct and return new vectors instead of returning the
internal one.

what I mean is code like this is pretty bad (but moderately easy to write)
---
  class Angel(object)
def __init__(self, offset):
  self.offset = offset

  t = new Angel()
  halo_pos = t.offset
  halo_pos.y -= 5
  DrawHalo(halo_pos)
-
and immutability of vectors makes that bug impossible.

the second reason for immutability of vectors is that they can because keys
in dicts (something I've found useful, but have had to use 2 element tuples
instead to make it work)


On Mon, Apr 27, 2009 at 2:59 PM, Lorenz Quack d...@amberfisharts.com wrote:

 Hello,

 I am interested in the inclusion of a vector and matrix types into pygame
 as suggested here [4]. In this email I want to propose a API for a vector
 module.

 I will for brevity only present the API for the types in three dimensions.
 The APIs for two or four dimensions should look analog.

 Also I enumerated every API for easier reference in discussions.
 Alternatives are denoted by lexical items (e.g. a) or b))
 At the end I put together a small comparison to existing implementations.

 This is only a suggestion to spark discussion and provoke feedback. So
 throw
 in your 2 cents.

 sincerely yours
 //Lorenz


 PS: If this turns out to be of any value I will put something similar
 together for matrix types and quaternions.




 **
 * API draft v1.0 *
 **

 In the following I will use the notation:
   v, v1, v2, ... are vectors
   s, s1, s2, ... are objects implementing the sequences
  protocol (list, tuple, the proposed vector)
   a, a1, a2, ... are scalars (int, float)


 § 1 Vector type
 

 1.1 Class name and constructor
 ==
 1.1.1  a) Vector3
   b) Vector3d
 1.1.2  V(a1, a2, a3)# initialize x, y and z with a1, a2 and a3 respectivly
 1.1.3  V(s) # initialize x, y and z with s[0], s[1] and s[2]
 respectivly
 1.1.4  V()  # initialize x, y and z with zeros


 1.2 numerical behavior
 ==
 1.2.1.1  v1 + s - v3
 1.2.1.2  s + v1 - v3
 1.2.1.3  v += s
 1.2.2.1  v1 - s - v3
 1.2.2.2  s - v1 - v3
 1.2.2.3  v -= s
 1.2.3.1  v1 * a - v3
 1.2.3.2  a * v1 - v3
 1.2.3.3  v *= a
 1.2.4.1  v1 / a - v3
 1.2.4.2  v /= a
 1.2.5.1  v1 // a - v3
 1.2.5.2  v //= a
 1.2.6.1  v1 % a - v3
 1.2.6.2  v %= a

 1.2.7.1  v * s - a  # dot/scalar/inner product
 1.2.7.2  s * v - a  # dot/scalar/inner product

 1.2.8.1  +v1 - v2   # returns a new vector
 1.2.8.2  -v1 - v2


 1.3 sequence behavior
 =
 1.3.1len(v) - 3   # fixed length
 1.3.2.1  v[0] - a # 0-based indexing
 1.3.2.2  v[0] = a


 1.4 attributes
 ==
 1.4.0x, y, z (and w for 4th dimension)
 _epsilon for comparison operations
 1.4.1.1  v.x - a
 1.4.1.2  v.x = a


 1.5 methods
 ===
 1.5.1v.dot(s) - a # dot/scalar/inner product
 1.5.2v.cross(s) - v   # cross/vector product
 # in 2 dimensions this returns v.x * s[1] - v.y * s[0]
 # this is not defined in 4 dimensions
 1.5.3v.outer(s) - m   # outer product yielding a matrix
 1.5.4.1  v.isNormalized() - bool
 1.5.4.2  v.normalize() - None# normalizes inplace
 1.5.4.3  v1.normalized() - v2# returns normalized vector
 1.5.5.1  v1.rotate(s1[, a]) - None
 # rotates around s1 by angle a. if a isn't given it
 # rotates around s1 by the magnitude of s1
 # this is an inplace operation
 1.5.5.2  v1.rotated(s1[, a]) - v2
 # same as 1.5.6 but returns a new vector and leaves v1 untouched
 1.5.6.1  v1.rotateX(a) - None
 # rotates v1 around the x-axis by the angle a
 1.5.6.2  v1.rotatedX(a) - v2
 # same as 1.5.6.1 but returns a new vector and leaves v1 untouched
 1.5.6.3  # implement 1.5.6.1 and 2 also for Y and Z
 1.5.7v1.reflect(s) - v2
 # reflects the vector of a surface with surface normal s
 1.5.8a) v1.interpolate(s, a) - generator of vectors
 b) v1.slerp(s, a) - generator of vectors
 # the distance between v1 and s divided in a steps
 1.5.9v.getAngleTo(s) - a
 # returns the angle between v and s
 1.5.10.1 v.getDistanceTo(s) - a
 # returns the distance between v and s
 1.5.10.2 v.getDistance2To(s) - a
 # returns the squared distance between v and s


 1.6 properties
 ==
 1.6.1.1  v.length - a # gets the magnitude/length of the vector
 1.6.1.2  

Re: [pygame] PGReloaded installation problems

[Brian Fisher]

This looks like your problem:

In file included from src/sdlmixer/mixermod.c:22:
src/sdlmixer/mixermod.h:24:23: error: SDL_mixer.h: No such file or directory

It seems it can't find the mixer dependency.

On Mon, Apr 13, 2009 at 3:32 PM, Evan Kroske e.kro...@gmail.com wrote:

 Today, I finally installed all of PGReloaded's dependencies, but when I try
 to run the python install script (python setup.py install), I get an
 incredibly large lists of warnings and the error:

 error: command 'gcc' failed with exit status 1

 If I try to use the make install method, I get this message:

 error: command 'gcc' failed with exit status 1
 make: *** [install] Error 1

 I have checked all the necessary installations with dpkg -l, and I can't
 find any missing pieces. I just updated my installation through SVN; that
 can't be the problem. If you have an idea of why it doesn't work, please
 help me out. I have attached the output from where the error starts.

 Regards,
 Evan Kroske
 Future GSoCer (hopefully)

Re: [pygame] Python - Pygame - PyOpenGL performance

[Brian Fisher]

That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made with
SWIG)

I actually still use PyOpenGL 2.0 for reasons other than performance (py2exe
packaging) - I had to build it myself on windows for Python 2.5, you can get
at an installer for it here:
http://thorbrian.com/pyopengl/builds.php

I've never performance tested the difference between it and 3.0 though - is
somebody else could do that, I'd love to see the results

On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
zack.schill...@gmail.comwrote:

 If someone did this and I could drop it in to my code, that would be very
 nice. But for right now, PyOpenGL is serving my needs just fine. I can use
 about 600 independently textured and animated sprites onscreen, scaled and
 rotated, without stressing a low-end system more than 40%.

 On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:

  Would writing a replacement for PyOpenGL in C instead of in Python
 with ctypes help? I think it really would ... PyOpenGL is internally
 pretty complex, sometimes when I get tracebacks the error is 5 or 6
 levels into PyOpenGL. Even a C library that only implemented the
 common functions and relied on PyOpenGL for the constants and
 functions that do complex things like handling strings would probably
 help a lot.


 Another way to increase speed is to write an opengl rendering engine
 in C and call and make it available as a Python extension. This is
 a major speed boost, in particular for a large number of iterations.
 Iirc PyOpenGL bindings are generated, many times this is suboptimal
 code for what you're trying to do, writing the Python extension in C
 manually have been faster for me many times. This is indeed true
 if you put your iterations inside a C loop instead of calling the
 C function from Python many times.

Re: [pygame] Fade to black question...

[Brian Fisher]

That's a bug. I think all the BLEND_ stuff was broken like that (where green
is messed up). It should be fixed now, though - can you try a pre-release
build? If you are on windows or Mac, you can get a pre-release build here:
http://thorbrian.com/pygame/builds.php

on linux though, I think you'd need to build from source.


On Tue, Mar 10, 2009 at 7:32 AM, Ty ... ty.sql...@gmail.com wrote:

 I'm trying to get a fade to black working, to that end I've written a
 simple program just to try it out... the (partial) code looks like
 this:

 self.screen.fill(white)
 self.screen.blit(self.image, self.size, self.size)
 print self.screen.get_at((4,4));
 self.screen.fill((2,2,2), None, BLEND_SUB)
 print self.screen.get_at((4,4));
 self.screen.fill((2,2,2), None, BLEND_SUB)
 print self.screen.get_at((4,4));
 self.screen.fill((2,2,2), None, BLEND_SUB)
 print self.screen.get_at((4,4));
 sys.exit()

 And the output...

 (46, 46, 44, 255)
 (44, 255, 42, 255)
 (42, 255, 40, 255)
 (40, 255, 38, 255)

 To me, it looks like it's working for the R and B components, but for
 some reason G immediately goes to 255 and never changes.  Is there
 something I'm doing wrong here?

 Also, one other question... how would I get it to stop at (0,0,0)
 rather than wrap around?  If I continue the loop for a long time, I
 get output that looks like this...

 (8, 255, 6, 255)
 (6, 255, 4, 255)
 (4, 255, 2, 255)
 (2, 255, 0, 255)
 (0, 255, 254, 255)
 (254, 255, 252, 255)
 (252, 255, 250, 255)
 (250, 255, 248, 255)

 Which means I've going to have to check that each time and make sure
 no wrap around has occured?  I might as well loop through every pixel
 in the image and do this kind of operation myself :P.

 Thanks!

 ~Ty

Re: [pygame] Pygame trouble on the Mac

[Brian Fisher]

Hi James,
 that code listing you posted works just fine for me on OS X 10.5. I think I
can help you if we can figure out what is different about your setup than
mine that is causing the program not to work.

I had to use different images than you cause I don't know where I'm supposed
to get the two used in the program - Is there some place I can get the
images you are using?

In terms of my system config, I'm on an Intel mac mini running Mac OS X
10.5.6, with framework builds of python installed (I tested with 2.5 and
2.6) with development builds (pre-release 1.9.1) of pygame. The version of
pygame I'm using uses SDL 1.2.13. The script works fine for me from both
from the terminal and running from pydev in the eclipse editor.

So how did you install pygame?  How are you running the script?

..also, If you could post to the list what is output if you run a script
with the lines below, it will let people know what versions of things you
are running, and what kind of mac machine you have:
---

#!/usr/bin/env python
import sys
import platform
import pygame

print pygame.__version__
print pygame.base.get_sdl_version()
print sys.version
print sys.path
print platform.platform()


On Sun, Mar 8, 2009 at 12:22 PM, James Morris 
james.morris1...@googlemail.com wrote:

 It's this one:

 Listing3-1. Hello World Redux (helloworld.py)  (page 45)

 #!/usr/bin/env python
 background_image_filename = 'sushiplate.jpg'
 mouse_image_filename = 'fugu.png'
 import pygame
 from pygame.locals import *
 from sys import exit
 pygame.init()
 screen = pygame.display.set_mode((640, 480), 0, 32)
 pygame.display.set_caption(Hello, World!)
 background = pygame.image.load(background_image_filename).convert()
 mouse_cursor = pygame.image.load(mouse_image_filename).convert_alpha()
 while True:
for event in pygame.event.get():
if event.type == QUIT:
exit()
screen.blit(background, (0,0))
x, y = pygame.mouse.get_pos()
x-= mouse_cursor.get_width() / 2
y-= mouse_cursor.get_height() / 2
screen.blit(mouse_cursor, (x, y))
pygame.display.update()



 --- THING IS, i just dont understand why some examples work in Pygame
 and others doesn't. I've spoke to the author of the book too, and he
 directed me to this mailing group. So I hope someone can help! ...
 It's annoying that I have the book, but can't run the examples. I have
 Python 2.5 on my Mac OSX 10.5 machine. ? The error that was generated
 in the Python console didn't have a line number. Just exactly what I
 posted... Maybe its just a warning? Either way the program doesn't run
 correctly.

 Cheers!!




 2009/3/8 Ian Mallett geometr...@gmail.com:
 - Show quoted text -
  I have the book too.  Which example are you running?  It should also give
 a
  line number.
 

[pygame] Revising Scrap API?

[Brian Fisher]

So I'm doing the scrap implementation for mac without pyobjc now, and it's
passing unit tests and working fine as far as I can tell, but I am having
trouble seeing how the scrap API for images would be useful to me in
practice, and I'm wondering if I get it at all... meaning the whole
SCRAP_PBM/SCRAP_PPM/SCRAP_BMP/tiff stuff. Also, having the small list of
additional types that windows  X11 specific things feels very not
cross-platform of pygame, so I want to make mac support them, but I can't
see how to make that support useful either. To summarize, some parts of the
api for scrap are feeling rather hacky, very not pythonic, and not like
something I'd even try to utilize. So can the list help me understand how
it's not, or help me make it useful?

...So I think the purpose of this scrap stuff is to communicate stuff
between pygame and other apps, right? like say copying a screenshot from
pygame so it can be pasted into photoshop, right? or making it so you can
copy/paste strings from your python windowing toolkits to other apps, right?

Well my big confusion is that as the API user, is that I'd be specifying
what I want with mime-types, and I don't know what that is supposed to mean.
If I'm trying to get stuff from the scrap module, then I want to work with
python/pygame objects, right? When I say image/bmp, am I saying give me
the image as an image/bmp, or am I saying only give me images if they are
image/bmp? Also, why would it be an advantage to me as a pygame user to say
I want SCRAP_PBM vs. SCRAP_BMP? do I really care at all? Isn't it true that
I really just want a surface, and any PBM/tiff/BMP string intermediate step
is just extra work I have to do? Likewise for putting stuff into the scrap -
I would think that as a pygame user I just want to put my surface on the
clipboard in whatever way is best for the platform, right? meaning paste it
so it can go into ms paint/photoshop on windows, and paste it so it can go
into gimp/icon composer/photoshop on the mac, and it can go into gimp on
linux, right? Does a pygame user really want to specify the precise
clipboard type, here? Isn't this just an opportunity to get the clipboard
format wrong (meaning it can't be pasted into common apps) for a
particular platform?

For strings/text, I have minor but similar confusions -  I'm a bit confused
by some minor string stuff as well - what is it supposed to mean in I
specify text/plain vs. text/plain;charset=utf-8? Am I specifying the
format that I'd like things returned or am I saying I only want this text if
it adheres to utf-8? Also, what encoding is text/plain supposed to mean? Why
not instead just have pygame have a defined encoding for text copy/pasted
and make it the pygame lib's responsibility to adhere to it? (for instance,
why not just say it's always utf-8 in and out, until python 3.0 where we say
it's always unicode?)


some other little questions:
* the selection thing - what's it actually used for? what does it mean to
copy and paste a selection? is there anybody anywhere who copies and pastes
selections in/out of a pygame app? does it make sense for selections to
be portable between pygame apps and other apps? If this is not something
useful to pygame apps, but instead is an idiosyncrosy of X11 that just has
to be handled, can we just make it handled automatically instead of being
part of the API?
* so what does pygame.scrap.lost mean? in what cases will the scrap be lost?
when it is lost, what is the action a pygame script would take to fix it?
why not just have each specific platform check for lostness if the
platform requires it, and automatically fix the problem if it occurs? When
and why would I care if it's lost in a pygame app?
* the unit test for scrap puts image.tostring into the scrap as a SCRAP_BMP
and gets it out as the same - however the windows code for scrap put appears
to strip off a BMP image header for SCRAP_BMP, and adds a BMP header back in
when getting things. So in that case, the unit test and windows source
appear to be rather at odds - so which is right?