Re: [pygame] OSX sprite flickering

[Charlie Nolan]

> I couldn't find a good way to efficiently combine the reclists and have it
> update them at the same time as i cant guarantee they will both exists that
> iteration so you cant do List + None.

   #Update the moving sprites.
   if not tick % npc.UPDATERATE:
   people.update()
   bullets.update()

   people.clear(screen, clear_cb)
   bullets.clear(screen, clear_cb)

   people_recs = people.draw(screen) or []
   bullet_recs = bullets.draw(screen) or []

   pygame.display.update(people_recs + bullet_recs)

If the return from draw is a non-empty list, that will be used.  If
it's empty or None, the fallback list (or []) will be used.

Might need to toy with the ordering a bit.  I think clear-before-draw
is correct, but I haven't played with it myself.
-FM

Re: [pygame] GMArcade Contest, PyGame Users Invited

[Charlie Nolan]

> Umm, people always post announcements here for game competitions/activities
> that invite PyGame (PyWeek, LudumDare, etc.) What's the big problem here?

Those directly involve PyGame.  This is more like Microsoft coming on
here and inviting us to a Games For Windows competition.  Sure,
something made with PyGame can be entered, but the contest doesn't
really concern PyGame, so why is it on our mailing list?

-FM

Re: [pygame] Movies in .exe

[Charlie Nolan]

You can use py2exe's "bundle my files" parameter.  That adds the zip
file to the exe.  Browse around in the py2exe docs and examples, it'll
tell you how to do it and how to get a file pointer back out.

-FM

On Fri, Jan 2, 2009 at 4:45 PM, Noah Kantrowitz  wrote:
>
> On Jan 2, 2009, at 5:39 PM, Ian Mallett wrote:
>
>> Yes, I've gotten it to work that way, but I want the file to be inside the
>> .exe itself, not just in the same folder ;)
>
> http://code.google.com/p/pefile/ can access the resource fields of an
> executable. You will either need to buffer the data in a temp file or a
> stringio buffer though. You could also use the same library to add the movie
> into the executable. This does seem a good bit harder that just putting it
> in the zip though.
>
> --Noah
>

Re: [pygame] euclid.Vector2 to pygame coordinate tuple shortcut?

[Charlie Nolan]

I don't have that package, but from what I see, it looks like this should work:
pygame.draw.circle(self.game.screen, self.color, tuple(self.loc), self.radius )

-FM

On Wed, Dec 24, 2008 at 11:36 PM, Jake b  wrote:
> I lost this shortcut, and can't find it googling. example: you have
> function that gets called like so:
>
>f2(1, (2,3), 3)
>
> ( like pygame.draw.circle() has a tuple for coordinates ). you can either do:
>
> pygame.draw.circle(self.game.screen, self.color, (self.loc.x,
> self.loc.y), self.radius )
>
> Or, what is the syntax to expand as tuple? it was something like: (
> where self.loc is a euclid.Vector2 )
>
>pygame.draw.circle(self.game.screen, self.color, *self.loc, self.radius )
>
> Messing with IDLE, trying to figure it out, I'm able to get it to work
> if there is *only* one argument, the tuple:
>
>f(*v) maps to f(v.x, v.y)
>
> thanks,
> --
> Jake
>

Re: [pygame] The future of Numeric

[Charlie Nolan]

If we're phasing out Numeric, wouldn't it be a good idea to make NumPy
the default when both are available?
-FM

On Tue, Dec 16, 2008 at 8:39 PM, Lenard Lindstrom  wrote:
> Yes, NumPy is nicer. Numeric is showing its age. NumPy makes better use of
> the Python features introduced with Python 2.2, unified types and classes.
> As I mentioned though, Numeric support won't disappear from Pygame just yet.
> Rather any future efforts will be concentrated on NumPy.
>
> Lenard
>
> René Dudfield wrote:
>>
>> hi,
>>
>> yeah Numpy is the much newer version of Numeric, and is compatible in
>> many ways.  There's also a document around somewhere that tells you
>> what methods to use for Numeric ones where they are not compatible.
>>
>> It's nicer in many regards, and Numeric has been marked obsolete a few
>> years ago.
>>
>> So definitely update any code you can to numpy :)
>>
>>
>> cheers,
>>
>> On Wed, Dec 17, 2008 at 10:08 AM, Ian Mallett 
>> wrote:
>>
>>>
>>> I'm not really familiar with either.  When I ported the .obj file loader
>>> to
>>> use vertex arrays (and in the future VBOs), I needed to add a vertex
>>> attribute array, which wanted a pointer (in C).  In Python, the function
>>> was
>>> placated with array.tostring().  That was using Numeric--does NumPy have
>>> the
>>> same thing?
>>> Ian
>>>
>
>
> --
> Lenard Lindstrom
> 
>
>

Re: [pygame] pygame.mixer.music broken in py2app games?

[Charlie Nolan]

What I'm saying is that you should try explicitly importing
pygame.mixer.music *as a module*.  It may be that, for whatever
reason, py2app is assuming it's a simple attribute of pygame.mixer and
not bundling the module.

Mind you, that's not how it's *supposed* to work, but so far it's the
only reason I can think of why pygame might work, but
pygame.mixer.music not.

-FM

On Fri, Dec 12, 2008 at 3:15 PM, James Paige  wrote:
> well, I just said "from pygame.mixer import music" because that is the
> shortest line I could find to show the problem, but in my actual code I
> do something more like this:
>
>  import pygame
>  pygame.init()
>  pygame.mixer.init()
>  pygame.mixer.music.load("song.ogg")
>
> And it crashes something like this when run from a py2app bundle
>
> Traceback (most recent call last):
>  File
> "/Users/james/src/hamster/stegavorto/musictest/dist/musictest.app/Contents/Resources/__boot__.py",
> line 31, in 
>_run('test.py')
>  File
> "/Users/james/src/hamster/stegavorto/musictest/dist/musictest.app/Contents/Resources/__boot__.py",
> line 28, in _run
>execfile(path, globals(), globals())
>  File
> "/Users/james/src/hamster/stegavorto/musictest/dist/musictest.app/Contents/Resources/test.py",
> line 4, in 
>pygame.mixer.music.load("song.ogg")
> AttributeError: 'module' object has no attribute 'music'
>
> ---
> James Paige
>
> On Fri, Dec 12, 2008 at 01:31:46PM -0600, Charlie Nolan wrote:
>> I haven't had any problems with it.  Maybe the from/import construct
>> is confusing py2app?  Try this:
>> import pygame.mixer.music as music
>> -FM
>>
>> On Fri, Dec 12, 2008 at 12:26 PM, James Paige  
>> wrote:
>> > Hey, I was just working on bundling up a game for Mac with py2app, and
>> > the app always crashes on any use of pygame.mixer.music. I can reproduce
>> > it with code this simple:
>> >
>> >  from pygame.mixer import music
>> >
>> > This works perfectly when I run it normally, but in a py2app bundle that
>> > line (or any line that accesses pygame.mixer.music) will crash with an
>> > AttributeError
>> >
>> > Has anybody else seen this?
>> >
>> > I am using Mac OS X 10.3 python 2.5.2 pygame 1.8.2 and I have tried both
>> > py2app 0.3.6 (stable) and py2app 0.4.4 (dev)
>> >
>> > ---
>> > James Paige
>> >
>>
>>
>

Re: [pygame] pygame.mixer.music broken in py2app games?

[Charlie Nolan]

I haven't had any problems with it.  Maybe the from/import construct
is confusing py2app?  Try this:
import pygame.mixer.music as music
-FM

On Fri, Dec 12, 2008 at 12:26 PM, James Paige  wrote:
> Hey, I was just working on bundling up a game for Mac with py2app, and
> the app always crashes on any use of pygame.mixer.music. I can reproduce
> it with code this simple:
>
>  from pygame.mixer import music
>
> This works perfectly when I run it normally, but in a py2app bundle that
> line (or any line that accesses pygame.mixer.music) will crash with an
> AttributeError
>
> Has anybody else seen this?
>
> I am using Mac OS X 10.3 python 2.5.2 pygame 1.8.2 and I have tried both
> py2app 0.3.6 (stable) and py2app 0.4.4 (dev)
>
> ---
> James Paige
>

Re: [pygame] Do we still need Python 2.3 support from Pygame?

[Charlie Nolan]

I think at this point, Pygame could drop official 2.3 support, but
unofficially attempt to keep it working as long as practical.  If
Debian want to support new Pygame on their old version, they're
welcome to report bugs for anything that gets broken by accident.

That would avoid the unit testing headache without immediately
breaking compatibility.

-FM

On Wed, Dec 10, 2008 at 11:12 PM, Lenard Lindstrom  wrote:
> This is not about removing Python 2.3 code. It  is about new code,
> particularly the unit test stuff. It is just tedious to keep checking if
> some Python feature is 2.3 compatible when I no longer have 2.3 on my
> machine.
>
> Lenard
>
> René Dudfield wrote:
>>
>> hi,
>>
>> the main reason for keeping 2.3 support was to support the last ye
>> olde Debian stable I think... However they finally got their new
>> release out with 2.5 as the standard python (unfortunately they
>> released with a version of pygame from 2005).  Plus the 2.3 python on
>> tiger OSX, and not requiring msvc71 on windows too... like everyone
>> has already mentioned.
>>
>> So hopefully we don't have to worry too much about 2.3 support.
>> However unless there's a good reason, I don't think there's no need to
>> rip out any 2.3 support code.
>>
>>
>
>
> --
> Lenard Lindstrom
> 
>
>

Re: [pygame] Do we still need Python 2.3 support from Pygame?

[Charlie Nolan]

Actually, I'm pretty sure that I've got Python 2.5 installed on a OS X
10.2 machine.  I remember that it was officially one OS X version
earlier than was supported, but it installed and runs just fine.  I've
been building py2app+Pygame stuff on it.

-FM

On Wed, Dec 10, 2008 at 7:30 PM, Joe Strout <[EMAIL PROTECTED]> wrote:
> On Dec 10, 2008, at 5:16 PM, Greg Ewing wrote:
>
 Do we still need to keep Pygame Python 2.3 compatible. I believe Python
 2.3 shipped with Mac OS X Tiger. Is it still the OS X default?
>>>
>>> No, OS X (10.5) comes with 2.5.1.
>>
>> Some people still use 10.4, though!
>
> True.  And that came with Python 2.3.5.
>
> But, is anyone still using 10.4 who's a pygame *developer*?  End-user apps
> could be bundled (with py2app), and then it shouldn't matter which version
> of python the user has installed (at least AIUI).
>
> Best,
> - Joe
>
>

Re: [pygame] Text at an angle

[Charlie Nolan]

Yeah, pure PyGame.  I've been contemplating using OpenGL to see if
that speeds things up a bit (I'm doing a full-screen refresh most
frames, thanks to scrolling).  Need to look up the 2D drawing stuff.

Thanks
-FM

On Mon, Dec 8, 2008 at 12:12 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm assuming you're using pure PyGame (no PyOpenGL) and that you know about
> pygame.font.
>
> Yes, I would recommend rendering the image in the largest font size, then
> using pygame.transform.rotozoom() to zoom in and rotate.  Alternately, if
> the text is static and there's not too much of it, you can just use an
> image.
>
> Ian
>

[pygame] Text at an angle

[Charlie Nolan]

I've got kind of an odd problem: I need to be able to display text at
an angle.  I just spent the past %(FAR_TOO_MANY)s hours trying to find
a way to get at FreeType's support from Python, but I'm really having
no luck.  The best I found was an interface to libgd, but I couldn't
figure out a way to extract the data to pygame or numpy efficiently.

Anybody got a suggestion for a way to do this?  I assume that
render->rotate doesn't give very good quality.  I was thinking maybe
render (2x size)->rotate->scale, but I don't know how much better
that's likely to be.

-FM

Re: [pygame] sprite groups and tilesheets

[Charlie Nolan]

> A good thing to do in a tile based game, is to blit all of the tiles
> to a single surface, so you aren't doing a bunch of blits every frame,
> and then just redraw the whole screen each frame using the rendered
> map.  If you have animated tiles of course, depending on how many
> tiles on screen are likely to be animated, this optimization will not
> be helpful.

It's also not going to be helpful if your map is large.  Assuming SDL
is willing to create a big enough surface (I've hit the limit with a
few bugs), you'll be using a ton of memory.

-FM

Re: [pygame] SDL_gfx integration

[Charlie Nolan]

ubuntu-desktop is (IIRC) a pseudo-package that just exists to make
sure other stuff is installed.  Removing it just means you won't get
new default software when you update, so it's not really harmful.

-FM

On Wed, Nov 19, 2008 at 8:28 PM, pymike <[EMAIL PROTECTED]> wrote:
> Oh, my apologies.. I'm afraid this thread is a bit OT now. Strike that,
> extremely OT.
>
> On Wed, Nov 19, 2008 at 8:27 PM, pymike <[EMAIL PROTECTED]> wrote:
>>
>> If I try to uninstall pulseaudio it makes me uninstall ubuntu-desktop. A
>> little red flag is telling me not to do this.
>>
>> Sigh... I guess I'll just wait for Ubuntu to fix their problems. Is there
>> a way to change pulseaudio's latency or w/e?
>>
>> On Wed, Nov 19, 2008 at 7:14 PM, pymike <[EMAIL PROTECTED]> wrote:
>>>
>>> pulseaudio is installed, but it's not enabled. Thanks for the link though
>>>
>>> On Wed, Nov 19, 2008 at 7:12 PM, René Dudfield <[EMAIL PROTECTED]> wrote:

 hi again,

 check out this thread:
 http://ubuntuforums.org/showthread.php?t=885437

 From this thread and notes on the SDL mailing list, it appears pulse
 audio is emulating alsa, and causing the delays.  Are you sure you
 don't have pulse audio installed?

 Apparently removing pulse audio fixes the problem... hopefully the
 ubuntu/pulse audio people will fix it though.  Better would be if
 ubuntu tested their OS with realtime/multimedia apps... and consider
 problems like non-working sound, and poor latency serious issues.


 cheers,
>>>
>>>
>>>
>>> --
>>> - pymike
>>> "Stop loling into a false sense of hilarity"
>>
>>
>>
>> --
>> - pymike
>> "Stop loling into a false sense of hilarity"
>
>
>
> --
> - pymike
> "Stop loling into a false sense of hilarity"
>

Re: [pygame] ugh!

[Charlie Nolan]

Ask the Ubuntu people about it.  You need to install a different
version of pygame, and the exact mechanism is distro-specific.  For
instance, Gentoo has python-updater, which can automatically upgrade
all your Python packages to the new version.
-FM

On Wed, Nov 19, 2008 at 8:33 PM, yanom @linuxmail.org
<[EMAIL PROTECTED]> wrote:
> so i just download pygame source and install again?
>> - Original Message -
>> From: "René Dudfield" <[EMAIL PROTECTED]>
>> To: pygame-users@seul.org
>> Subject: Re: [pygame] ugh!
>> Date: Wed, 19 Nov 2008 14:33:11 +1100
>>
>>
>> you need to install pygame for python 2.6 too.
>>
>> Different versions of python don't share packages.
>>
>> cu,
>>
>>
>> On Wed, Nov 19, 2008 at 2:26 PM, yanom @linuxmail.org
>> <[EMAIL PROTECTED]>wrote:
>>
>> > oops! sorry! I accidentallly hit the enter key while typing in the subject
>> > box, and it sent the mail.
>> > What i ment to say was...
>> > ugh! upgrade problems.
>> >
>> > i upgraded my  python from 2.5.2 from 2.6 by running every step of the
>> > install instruction as root on my Ubuntu. After i added 2.5.2's sys.path to
>> > 2.6's by adding an
>> >
>> > export PYTHONPATH=/all/of/:/the/paths/:/go/here/:$PYTHONPATH
>> >
>> > statement to my /etc/bash.bashrc, I logout, then log back in, and do:
>> >
>> > $ python
>> >
>> > (thus launching python 2.6)
>> >
>> > and do this:
>> >
>> > >>>import pygame
>> >
>> > And now it gets all cranky and says:
>> >
>> > no module named pygame.
>> >
>> >
>> >
>> > WHAT IS GOING ON???
>> > > - Original Message -
>> > > From: "yanom @linuxmail.org" <[EMAIL PROTECTED]>
>> > > To: pygame-users@seul.org
>> > > Subject: [pygame] ugh!
>> > > Date: Wed, 19 Nov 2008 11:16:01 +0800
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Powered by Outblaze
>> >
>> > >
>> >
>> >
>> > =
>> > Moving & Storage
>> > San Antonio Moving & Storage Solutions. Family Owned & Operaged.
>> >
>> > http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=e1aa04af53120fba4eb2f9167d904912
>> >
>> >
>> > --
>> > Powered by Outblaze
>> >
>
>>
>
>
> =
> Bottled Water
> Custom label water Wholesale Prices Full Color labels no extra charge.
> http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=fb8e323691bfc76d884dfa6ed4a64ccb
>
>
> --
> Powered by Outblaze
>

Re: [pygame] PYTHONPATH

[Charlie Nolan]

Yeah, it may be using .bash_login, in which case you'll need to put
PYTHONPATH or "source .bashrc" into that file.
-FM

On Tue, Nov 18, 2008 at 6:06 PM, Jake b <[EMAIL PROTECTED]> wrote:
> add an echo statement in your file, to make sure it's being executed.
> Because it might be reading a different config file depending on how
> it was launched.
>
> --
> Jake
>

Re: [pygame] SDL_gfx integration

[Charlie Nolan]

Er, you may need to trim the -FM off of that.  GMail, at least,
interpreted it as part of the URL.

This should be clean:
https://bugs.launchpad.net/ubuntu/+source/pygame/+bug/295369

-FM

On Mon, Nov 17, 2008 at 10:20 PM, Charlie Nolan <[EMAIL PROTECTED]> wrote:
> This looks likely:
> https://bugs.launchpad.net/ubuntu/+source/pygame/+bug/295369
> -FM
>
> On Mon, Nov 17, 2008 at 9:52 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>> hey,
>>
>> pymike, what's the url for your ubuntu bug report?
>>
>>
>>
>> On Tue, Nov 18, 2008 at 2:35 PM, pymike <[EMAIL PROTECTED]> wrote:
>>> Oooo I wonder what cool new stuffz will be in pygame 2.0. Mebbe mixer won't
>>> be messed up on ubuntu intrepid :(
>>>
>>> On Mon, Nov 17, 2008 at 7:57 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>>>
>>>> hey,
>>>>
>>>>
>>>> On Tue, Nov 18, 2008 at 12:33 PM, Forrest Voight <[EMAIL PROTECTED]>
>>>> wrote:
>>>> > I think I was wrong ... I don't remember what I was thinking. :)
>>>> >
>>>> > Anyway, the next major version of pygame already has sdl_gfx
>>>> > integrated I think, so this might be moot. :(
>>>> >
>>>>
>>>> note, that we are probably going to do some more 1.x releases of
>>>> pygame... so this could still be quite useful.
>>>>
>>>> cu!
>>>
>>>
>>>
>>> --
>>> - pymike
>>> "Stop loling into a false sense of hilarity"
>>>
>>
>

Re: [pygame] SDL_gfx integration

[Charlie Nolan]

This looks likely:
https://bugs.launchpad.net/ubuntu/+source/pygame/+bug/295369
-FM

On Mon, Nov 17, 2008 at 9:52 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hey,
>
> pymike, what's the url for your ubuntu bug report?
>
>
>
> On Tue, Nov 18, 2008 at 2:35 PM, pymike <[EMAIL PROTECTED]> wrote:
>> Oooo I wonder what cool new stuffz will be in pygame 2.0. Mebbe mixer won't
>> be messed up on ubuntu intrepid :(
>>
>> On Mon, Nov 17, 2008 at 7:57 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>>
>>> hey,
>>>
>>>
>>> On Tue, Nov 18, 2008 at 12:33 PM, Forrest Voight <[EMAIL PROTECTED]>
>>> wrote:
>>> > I think I was wrong ... I don't remember what I was thinking. :)
>>> >
>>> > Anyway, the next major version of pygame already has sdl_gfx
>>> > integrated I think, so this might be moot. :(
>>> >
>>>
>>> note, that we are probably going to do some more 1.x releases of
>>> pygame... so this could still be quite useful.
>>>
>>> cu!
>>
>>
>>
>> --
>> - pymike
>> "Stop loling into a false sense of hilarity"
>>
>

Re: [pygame] pygame mixer problem upgrading to ubuntu intrepid

[Charlie Nolan]

You probably just upgraded pygame from 1.7.1 to 1.8.1.  1.8.1
increased the default sound buffer size to avoid various hiccups in
sound playback.  (It was supposed to be in 1.8.0, but a bug caused it
to decrease and be stuck there.)  You can override it by calling
pygame.mixer.init or .pre_init and giving a buffer size.  Values get
rounded up to the next power of two.

Someone with SVN access might want to fix the default, by the way.
It's set to 1024*3 (=3072), but the power-of-two rounding makes that
effectively 4096.  The docs also say the buffer size "must be a power
of two", which the default isn't.  And that should really read "should
be", since it's rounded up otherwise.

-FM

On Sat, Nov 15, 2008 at 8:49 AM, pymike <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I recently upgraded my Ubuntu from Hardy (8.04) to Intrepid (8.10). Now
> sound/music are delaying about 10-20 milleseconds in pygame. :-S
>
> Sounds in other SDL applications (I've tested SuperTux 2 and Wormux) work
> perfectly, which makes me think it's not a sound driver issue.
>
>  Can anyone help me to get this fixed?
>
> Thanks :-)
>
> --
> - pymike
> "Stop loling into a false sense of hilarity"
>

Re: [pygame] python problems

[Charlie Nolan]

Whoa, whoa.  Slow down and use more punctuation so that we can
understand you.  What exactly are you trying to do?  Code would help,
and from what you said, I'm not even sure where the images are.

-FM

On Thu, Nov 13, 2008 at 9:50 AM, Matt Pearson <[EMAIL PROTECTED]> wrote:
> hey guys, im having trouble with python reading scripts when inside its own
> folder
> the folder is in the python26 folder but when i have a project that has
> images in it
> i put them in their own folder together. and it wont read the files inside
> the folder
>
> I thought i set the path for it but im not sure whats going on?
>
> Thanks

Re: [pygame] Linux binaries

[Charlie Nolan]

> Yes, certainly -- finding a better algorithm is always
> the best form of optimization!

Yup.  Even a supercomputer is going to choke if you feed it Bogosort.

Re: [pygame] Shaders and Examples not Working

[Charlie Nolan]

Looks like you need to make a call to glutInit() at the start of
InitGL.  Won't run here without it.
-FM

On Thu, Oct 23, 2008 at 5:31 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> I've condensed it down and ported it to pygame.
> http://www.geometrian.com/Programs/Tutorials/pygameshaders.zip
> Ian
>

[pygame] Geany and key presses

[Charlie Nolan]

If you have a question that isn't directly related to the thread
topic, please don't hijack that thread.  Start a new one.  It's easier
to follow the messages that way.

-FM

On Fri, Oct 31, 2008 at 4:54 PM, Matt Pearson <[EMAIL PROTECTED]> wrote:
> When i use Geany loading a python script, the keyboard commands interfere
> with
> the console window, i have a script where i move a sprite in 4 directions
> and once
> i press a key it closed the py window and shows and error in the console??

Re: [pygame] my rpg game (so far)

[Charlie Nolan]

For my method, just drop this into your main event-handling loop (with
changes as needed):
if event.type == USEREVENT
keys = pygame.key.get_pressed()
speed = constants.SCROLL_SPEED / graphics.constants.FPS

if keys[K_LEFT]:
pos[1] -= speed
if keys[K_RIGHT]:
pos[1] += speed
if keys[K_UP]:
pos[0] -= speed
if keys[K_DOWN]:
pos[0] += speed

You'll also want to do this in the setup:
FPS = 30
pygame.timer.set_timer(USEREVENT, 1000. / FPS)

Adjust FPS up to make it smoother, down to use less CPU.  30 FPS seems
to be a good setting for me.

-FM

On Fri, Oct 31, 2008 at 2:21 PM, Michael Fiano <[EMAIL PROTECTED]> wrote:
> On Fri, 31 Oct 2008 06:13:15 -0400
> Michael Fiano <[EMAIL PROTECTED]> wrote:
>
>> Right now if you are holding a directional key to move, and you press
>> a different directional key at the same time, the player will stop,
>> instead of changing directions. If anyone could give me some pointers
>> on how to do this I'd be very happy, because I want it to be
>> gamepad-friendly too.
>
> Correction: The player doesn't stop when a 2nd simultaneous direction
> is pressed. It does stop moving the player under the following
> conditions though, and I would like to somehow prevent it:
>
> If you hold down any cursor key then change directions by holding
> down another cursor key and then lift your finger off the second to
> resume the direction of the first, the avatar will actually stop
> instead. I want to resume moving in the first pressed (and
> still pressed) direction instead of stopping abruptly. I have tried the
> sugestions here to no avail. Are there any games with this type of
> movement functionality, or any sample code anywhere?
>

Re: [pygame] my rpg game (so far)

[Charlie Nolan]

set_repeat isn't exactly ideal because it produces jerky movement.  I
just ignore the events altogether and use pygame.key.get_pressed once
a tick.

-FM

On Fri, Oct 31, 2008 at 11:47 AM, Paul Pigg <[EMAIL PROTECTED]> wrote:
> Have you tried using the pygame.key.set_repeat() function?  Otherwise, I
> would use the KEYDOWN event to set the speed in either x or y direction (I
> like diagonal movement ;)) and the KEYUP event to reset the directional
> speed to zero.  With that method, you'd need logic to deal with abrupt
> changes such as the user holding the up arrow, then pressing the down arrow
> before releasing the up arrow (which may again be taken care of by
> set_repeat).
>
> --p
>
> On Fri, Oct 31, 2008 at 3:13 AM, Michael Fiano <[EMAIL PROTECTED]>
> wrote:
>>
>> On Fri, 31 Oct 2008 18:39:31 +1000
>> Nicholas Dudfield <[EMAIL PROTECTED]> wrote:
>>
>> > I am pretty sure you don't need to run event.pump() for every event.
>> >
>> > It doesn't seem like `keyinput` is being used at all so it's probably
>> > not needed.
>>
>> You're right. I don't need it anymore. keyinput was being used before
>> to make it so that more than one key could be pressed to move the
>> character. I gave up due to minor bugs in my code and forgot to remove
>> that little bit. What I would like to do:
>>
>> Right now if you are holding a directional key to move, and you press a
>> different directional key at the same time, the player will stop,
>> instead of changing directions. If anyone could give me some pointers
>> on how to do this I'd be very happy, because I want it to be
>> gamepad-friendly too.
>>
>> > 
>> > elif event.key == K_UP or event.key == K_DOWN or event.key == K_LEFT
>> > or event.key == K_RIGHT:
>> > do_stuff()
>> > > >
>> > The python idiom for this is
>> >
>> > 
>> > elif event.key in (K_UP, K_DOWN, K_LEFT, K_RIGHT):
>> > do_stuff()
>> > 
>>
>> Aha, nice. Thanks!
>
>

Re: [pygame] Pygame reloaded in SVN

[Charlie Nolan]

SDL_image 1.2.7?  As far as I can tell, the current version is only
1.2.6: http://www.libsdl.org/projects/SDL_image/

-FM

Re: [pygame] help

[Charlie Nolan]

I'm guessing it's working as designed.  Idle assumes you don't want it
to quit, so it catches the exception.
-FM

On Thu, Oct 30, 2008 at 2:30 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> Yes, I was thinking that, but the error seems to be a Python exception
> (indeed that's what sys.exit() does).  Perhaps the error is Python 2.6
> specific?
> Ian

Re: [pygame] Can't install pygame 1.8.1

[Charlie Nolan]

> src/pygame.h:60:20: error: Python.h: No such file or directory

Looks like you're missing the Python header files.  The rest of the
mess just looks like various reactions to that.

-FM

On Mon, Oct 27, 2008 at 8:48 PM, yanom @linuxmail.org
<[EMAIL PROTECTED]> wrote:
> When i try to run the setup.py script for pygame 1.8.1 (i finally decided to 
> upgrade) it gives this error:
>
> *
>
> [EMAIL PROTECTED]:/home/yanom/pygame-1.8.1release# python setup.py
>
> No Arguments Given, Perform Default Install? [Y/n]yes
> running install
> running build
> running build_py
> running build_ext
> building 'pygame.imageext' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -fPIC -D_REENTRANT -I/usr/X11R6/include 
> -I/usr/include/SDL -I/usr/include/SDL -I/usr/include -I/usr/include 
> -I/usr/include/python2.5 -c src/imageext.c -o 
> build/temp.linux-x86_64-2.5/src/imageext.o
> In file included from src/imageext.c:31:
> src/pygame.h:60:20: error: Python.h: No such file or directory
> In file included from src/imageext.c:31:
> src/pygame.h:84: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'lenfunc'
> src/pygame.h:85: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'ssizeargfunc'
> src/pygame.h:86: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'ssizeobjargproc'
> src/pygame.h:87: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'ssizessizeargfunc'
> src/pygame.h:88: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'ssizessizeobjargproc'
> src/pygame.h:89: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'readbufferproc'
> src/pygame.h:90: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'writebufferproc'
> src/pygame.h:91: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'segcountproc'
> src/pygame.h:92: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'charbufferproc'
> src/pygame.h:196: error: expected specifier-qualifier-list before 
> 'PyObject_HEAD'
> src/pygame.h:237: error: expected specifier-qualifier-list before 
> 'PyObject_HEAD'
> src/pygame.h:272: error: expected specifier-qualifier-list before 
> 'PyObject_HEAD'
> src/pygame.h:311: error: expected specifier-qualifier-list before 
> 'PyObject_HEAD'
> src/pygame.h:349: error: expected specifier-qualifier-list before 
> 'PyObject_HEAD'
> src/pygame.h:408: error: expected specifier-qualifier-list before 'PyObject'
> src/pygame.h:415: error: expected specifier-qualifier-list before 
> 'PyObject_HEAD'
> src/pygame.h:457: error: expected specifier-qualifier-list before 
> 'PyObject_HEAD'
> src/pygame.h:525: error: expected specifier-qualifier-list before 
> 'PyObject_HEAD'
> src/imageext.c:50: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before '*' token
> src/imageext.c:353: warning: function declaration isn't a prototype
> src/imageext.c: In function 'opengltosdl':
> src/imageext.c:356: error: 'PyObject' undeclared (first use in this function)
> src/imageext.c:356: error: (Each undeclared identifier is reported only once
> src/imageext.c:356: error: for each function it appears in.)
> src/imageext.c:356: error: 'pyopengl' undeclared (first use in this function)
> src/imageext.c:356: error: 'readpixels' undeclared (first use in this 
> function)
> src/imageext.c:356: warning: left-hand operand of comma expression has no 
> effect
> src/imageext.c:372: warning: implicit declaration of function 
> 'PyErr_SetString'
> src/imageext.c:372: error: 'PyExc_RuntimeError' undeclared (first use in this 
> function)
> src/imageext.c:372: error: expected expression before ')' token
> src/imageext.c:376: error: expected expression before ')' token
> src/imageext.c:383: error: 'PyExc_MemoryError' undeclared (first use in this 
> function)
> src/imageext.c:383: error: expected expression before ')' token
> src/imageext.c:403: error: expected expression before ')' token
> src/imageext.c:403: error: expected expression before ')' token
> src/imageext.c:357: warning: unused variable 'formatflag'
> src/imageext.c:357: warning: unused variable 'typeflag'
> src/imageext.c: At top level:
> src/imageext.c:418: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before '*' token
> src/imageext.c:496: error: expected '=', ',', ';', 'asm' or '__attribute__' 
> before 'image_builtins'
> src/imageext.c: In function 'initimageext':
> src/imageext.c:507: warning: implicit declaration of function 'Py_InitModule3'
> src/imageext.c:507: error: 'image_builtins' undeclared (first use in this 
> function)
> src/imageext.c:510: error: 'PyObject' undeclared (first use in this function)
> src/imageext.c:510: error: '_module' undeclared (first use in this function)
> src/imageext.c:510: warning: implicit declaration of function 
> 'PyImport_ImportModule'
> src/imageext.c:510: error: '_dict' undeclared (first use in th

Re: [pygame] Pyggy Awards are Go, Almost

[Charlie Nolan]

> Does it have to be your own Pyweek entry? or can you work with someone
> else's pyweek entry that has apparently been abandoned?

"Each entry must be based on an entry from an earlier PyWeek
competition. It can be any entry, not necessarily your own. However,
if you work on someone else's entry, you should change the name to
avoid confusion, and the original author(s) should be credited for
his/her/their contribution."
>From http://www.cosc.canterbury.ac.nz/greg.ewing/python/pyggy/ .

-FM

Re: [pygame] Pyggy Awards are Go, Almost

[Charlie Nolan]

I think you're missing the point of the competition.  It's
specifically for games that were previously entered in PyWeek.  Your
tool could be used by a Pyggy game, but can't compete on its own.
-FM

On Thu, Oct 23, 2008 at 5:45 AM, Abhinav Lele <[EMAIL PROTECTED]> wrote:
> Well im working on a utility/tool which allows u to make animations.
> But it is not restricted to just animation. As it progresses it will allow u
> to create applications also. And all this will be given to my app as a
> zip bundle.
>
> Its still under construction and I am experimenting with pygame. Previously
> I tried with SDL and lua but had some major issues on Windows, so I am now
> trying out pygame.
>
> The project link is http://code.google.com/p/openanimator/ and
> http://sourceforge.net/projects/openanimator/
>
>
> So will it be qualified for Pyggy ?
>
> -Abhinav
>
> On Thu, Oct 23, 2008 at 3:14 PM, Greg Ewing <[EMAIL PROTECTED]>
> wrote:
>>
>> Abhinav Lele wrote:
>>>
>>> is this going to consider tools/utilities that allow u to create
>>> games/apps using pygame ?
>>
>> I'm not sure what you mean by that. Can you explain
>> using more words?
>>
>> --
>> Greg
>
>
>

Re: [pygame] [bug] blit_array() fails with a 24 bit surface

[Charlie Nolan]

Ah, I see.  I misread what the docs were saying.  Carry on.

*quietly goes off to stand in a corner*
-FM

On Wed, Oct 22, 2008 at 9:43 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> Hi Charlie,
>
> 3d arrays work with 24 and 32 bit surfaces, 2d arrays with 16 and 32 bit
> surfaces. So blit_array should work. It it just tricky getting the byte
> alignments right.
>
> Lenard
>
>
> Charlie Nolan wrote:
>>
>> That may be a fundamental weakness of the method used, seeing as how
>> pixels*d doesn't work on 24-bit surfaces.  If so, it should definitely
>> give a better error message and be mentioned in the docs.
>>
>> -FM
>>
>> On Wed, Oct 22, 2008 at 3:34 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> I've just filed bug 24 at http://pygame.motherhamster.org/bugzilla/
>>>
>>> Pygame-1.9.0a0 (rev. 1668)
>>> numpy 1.0.4
>>> Python 2.5.2
>>>
>>> pygame.surfarray.blit_array() raises an exception when a 3d array is
>>> copied
>>> to a 24 bit surface.
>>>
>>> Test Program:
>>>
>>> import pygame
>>>
>>> pygame.surfarray.use_arraytype('numpy')
>>> s = pygame.Surface((10,10), 0, 24)
>>> a = pygame.surfarray.array3d(s)
>>> pygame.surfarray.blit_array(s, a)
>>>
>>>
>>> Exception:
>>> Traceback (most recent call last):
>>>  File "array_bug.py", line 6, in 
>>>  pygame.surfarray.blit_array(s, a)
>>>  File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line 260,
>>> in
>>> bli
>>> t_array
>>>  return numpysf.blit_array (surface, array)
>>>  File "C:\PRG\PYTHON25\lib\site-packages\pygame\_numpysurfarray.py", line
>>> 381,
>>> in blit_array
>>>  (array[:,:,1::3] >> losses[1] << shifts[1]) | \
>>> TypeError: unsupported operand type(s) for >>: 'float' and 'int'
>>>
>>>
>>> I will see what I can do with it.
>>>
>>> --
>>> Lenard Lindstrom
>>> <[EMAIL PROTECTED]>
>>>
>>>
>>>
>
>
> --
> Lenard Lindstrom
> <[EMAIL PROTECTED]>
>
>

Re: [pygame] Pyggy Awards are Go, Almost

[Charlie Nolan]

Greg, the rules on the site
(http://www.cosc.canterbury.ac.nz/greg.ewing/python/pyggy/) seem to
forbid games older than the previous PyWeek.  Are there any plans for
a special edition or some such that would allow older PyWeek games?

-FM

On Wed, Oct 22, 2008 at 8:28 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Richard and I have been working on setting up a web site
> for the Pyggy Awards, and it's very nearly ready to go!
>
> In case you've forgotten, the Pyggy Awards is going to be
> a showcase event for games based on a previous PyWeek entry.
> If you want to polish one of your PyWeek games and have
> somewhere to show off the result, this is it.
>
> The Pyggy Awards will be run in a very similar way to
> the PyWeek competition, with the following differences:
>
> * You can start working immediately, or even in the past,
> i.e. any further work you've already done on an existing
> PyWeek entry is eligible.
>
> * Any library code can be used, as long as it's open
> source.
>
> The only thing remaining to be decided is the dates for
> the judging period. The possibilities are:
>
> a) Early December, probably the first 2 weeks.
>
> b) Some time in February or March next year.
>
> Option (b) obviously allows more coding time, but the
> next PyWeek is going to be in early April, so it wouldn't
> leave much time for people to recover their energy.
>
> So I'm asking for feedback on this -- what would you
> prefer? More time, or more breathing space before the
> next PyWeek?
>
> --
> Greg
>

Re: [pygame] surfarray on 64-bit machines

[Charlie Nolan]

I may be having this same error.  I've got a bug report with that same
error message at one point (and on a 64-bit machine), even though it
works fine on my (32-bit) machine.  Could you try printing out
"array[:].shape"?  In my case, I do a sensible slice and somehow end
up with a 0x600 array.

-FM

On Wed, Oct 22, 2008 at 7:23 PM, Marius Gedminas <[EMAIL PROTECTED]> wrote:
> A user reported that PySpaceWar fails on 64-bit Linux machines if I try
> to scale the alpha channel.  Here's the code (simplified):
>
>import pygame
>import Numeric
>image = pygame.image.load('title.png')   # has an alpha channel
>mask = pygame.surfarray.array_alpha(image).astype(Numeric.Int)
>array = pygame.surfarray.pixels_alpha(self.image)
>alpha = 42.5 # a float between 1 and 255
>array[:] = (mask * alpha / 255).astype(Numeric.UnsignedInt8)
>
> The error happens on the last line, and it says
>
>ValueError: matrices are not aligned for copy
>
> Any ideas?  The code works fine on 32-bit systems.
>
> Marius Gedminas
> --
> If C gives you enough rope to hang yourself, C++ gives you enough rope to bind
> and gag your neighborhood, rig the sails on a small ship, and still have 
> enough
> rope left over to hang yourself from the yardarm.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFI/8PxkVdEXeem148RAkA6AJwMJ03rjyOqAh6NWRtif4Hf࿞㋀⟞恍
> o4PpuubhJjENjPrqIg0CZXQ=
> =2e46
> -END PGP SIGNATURE-
>
>

Re: [pygame] [bug] blit_array() fails with a 24 bit surface

[Charlie Nolan]

That may be a fundamental weakness of the method used, seeing as how
pixels*d doesn't work on 24-bit surfaces.  If so, it should definitely
give a better error message and be mentioned in the docs.

-FM

On Wed, Oct 22, 2008 at 3:34 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> I've just filed bug 24 at http://pygame.motherhamster.org/bugzilla/
>
> Pygame-1.9.0a0 (rev. 1668)
> numpy 1.0.4
> Python 2.5.2
>
> pygame.surfarray.blit_array() raises an exception when a 3d array is copied
> to a 24 bit surface.
>
> Test Program:
>
> import pygame
>
> pygame.surfarray.use_arraytype('numpy')
> s = pygame.Surface((10,10), 0, 24)
> a = pygame.surfarray.array3d(s)
> pygame.surfarray.blit_array(s, a)
>
>
> Exception:
> Traceback (most recent call last):
>  File "array_bug.py", line 6, in 
>   pygame.surfarray.blit_array(s, a)
>  File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line 260, in
> bli
> t_array
>   return numpysf.blit_array (surface, array)
>  File "C:\PRG\PYTHON25\lib\site-packages\pygame\_numpysurfarray.py", line
> 381,
> in blit_array
>   (array[:,:,1::3] >> losses[1] << shifts[1]) | \
> TypeError: unsupported operand type(s) for >>: 'float' and 'int'
>
>
> I will see what I can do with it.
>
> --
> Lenard Lindstrom
> <[EMAIL PROTECTED]>
>
>

Re: [pygame] Indie Game Host

[Charlie Nolan]

In other words, this has absolutely nothing to do with Pygame and
you're just someone who saw "game" in the list name.  Go away.

On Sat, Oct 18, 2008 at 4:56 PM, Matt Kremer <[EMAIL PROTECTED]> wrote:
> There were two responses, I'm going to respond to both in this message.
>
> For one, games are not played in-browser. They are temporarily loaded via
> JAVA and then run on the players computer.
>
> Also, I am not just someone who saw "game" in the list name, and my site
> supports any kind of game. JAVA is only used to temporarily store the game
> and run it. For instance, someone uploads a .exe in a .zip file (files must
> be zipped to upload). JAVA loads this zip, unzips it, and runs the exe.
> Nothing on the site is JAVA, they are all exe files.
>
> Thanks,
> Matt Kremer
>
> Quoting James Paige <[EMAIL PROTECTED]>:
>
>> I think that was just spam from somebody who saw "game" in the list name
>> and assumed it would be a good place to advertise his website
>> that appears to only support java games.
>>
>> ---
>> James
>>
>> On Fri, Oct 17, 2008 at 04:38:00PM -0500, pymike wrote:
>>>
>>>   OOC can the pygame games be played in browsers?
>>>
>>>   On Fri, Oct 17, 2008 at 3:52 PM, Matt Kremer
>>> <[EMAIL PROTECTED]>
>>>   wrote:
>>>
>>> Hello pygame users,
>>>
>>> I run a website called GMArcade (http://gmarcade.com). In short, we
>>> are
>>> an arcade for indie game developers, where users can post their
>>> games.
>>> Here is a list of features:
>>>
>>> -Upload your game with screenshots
>>> -Your game can immediately be played online, without users
>>> downloading
>>> (JAVA must be installed). Test this out by clicking this link (just
>>> click "Open" if prompted to download a JNLP file):
>>>
>>> http://gmarcade.com/generatejnlp.php?id=10
>>>
>>> -Participate in discussions on our forums
>>> -Comment and Rate other games
>>> -Start your own Blog!
>>> -Just hang out and have fun!
>>>
>>> I hope to attract users from PyGame, as well as other game
>>> development
>>> tools. It would be great to see some of you on the site :)
>>>
>>> Here's the link again:
>>>
>>> http://gmarcade.com/
>>>
>>> And if you want to request any new features, just post here:
>>>
>>> http://gmarcade.com/requestafeature/
>>>
>>> I hope to see you around, thanks again!
>>> -Matt Kremer
>>> http://gmarcade.com/
>>>
>>>   --
>>>   - pymike
>>>   "Stop loling into a false sense of hilarity"
>>
>
>
>
>

Re: [pygame] Good code for text wrapping?

[Charlie Nolan]

Yes, yes, I know, it's Wednesday and then some.  My laptop's display
decided to die on Tuesday and it's in for repairs.  Linux decided to
run fsck on the reboot as it was failing, and since then, I've got no
idea what it's up to, so I couldn't even bring it up to get files off.
 Drive's sitting in front of me, but I don't have any way to connect
it to a different machine.

I'll get on this once Murphy leaves me alone again.

-FM

On Fri, Oct 10, 2008 at 3:12 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> cool.  There's no rush :)  I haven't gotten back into the text
> wrapping mood yet either.
>
> I saw your mock font, for testing.  That's a good idea.
>
> cu,
>
> On Fri, Oct 10, 2008 at 6:13 PM, Charlie Nolan <[EMAIL PROTECTED]> wrote:
>> Just posting to say that no, I haven't forgotten about this.  I'd just
>> forgotten how many things I have to work on.  Anybody got a cloning
>> device handy?
>>
>> Failing that, give me a prod if there isn't a basic working version up
>> by Wednesday.  It'll only take a couple hours, I just need to find a
>> couple hours when I'm alert, not doing something else, and interested
>> in coding.
>>
>> -FM
>>
>

Re: [pygame] Shooting an image

[Charlie Nolan]

> is that bad?

Depends.  Did you accidentally the *whole* bullet?

Re: [pygame] Shooting an image

[Charlie Nolan]

> 3)yes I am recycling the same bullet. Why was this the topic of some jokes? 
> I'm new to pygame and that was probably before i joined the mailinglist.

Bullet theology.  As in "What happens after I go off the screen?"
Apparently, your world has reincarnation.

-FM

Re: [pygame] Good code for text wrapping?

[Charlie Nolan]

Just posting to say that no, I haven't forgotten about this.  I'd just
forgotten how many things I have to work on.  Anybody got a cloning
device handy?

Failing that, give me a prod if there isn't a basic working version up
by Wednesday.  It'll only take a couple hours, I just need to find a
couple hours when I'm alert, not doing something else, and interested
in coding.

-FM

Re: [pygame] Linux distribution(s) of a finished product

[Charlie Nolan]

Actually, in many respects, the best thing to do is just get your
program files out there (in some usable form) as soon as possible.  If
you get people interested in what you have, the community will provide
distribution methods for you.  I work on Endgame: Singularity, and we
just provide a tarball of the program files.  The distros handle
packaging it for their users.

-FM

On Tue, Oct 7, 2008 at 5:13 PM, Wayne Koorts <[EMAIL PROTECTED]> wrote:
> Hi Keith,
>
> I would suggest starting on Ubuntu Linux.  This will cover a huge number of
> Linux users and you will also be able to more easily adapt the package to
> any other Debian based distribution, of which there are many.
>
>> This results in a better formed question: Can I get all the pygame parts
>> (including things like numpy/numeric) into one location and rely on a
>> distro's Python to just work? I'm pretty sure my python code is compliant
>> back to 2.3.
>
> The standard way of working this scenario is to create a package, with just
> your components in it, which then contains metadata for its dependencies so
> that the package manager ("apt" in the case of Ubuntu or other Debian based
> distros) will then handle the dependencies.  You can specify which version
> of a particular application or library is required and as long as you test
> it on the system you are aiming for you should be fine.
>
> Have a look at the following document for details on packaging for Ubuntu:
> https://wiki.ubuntu.com/PackagingGuide/Complete
>
> Look at the Solarwolf package for Ubuntu for a current example of a pygame
> application to base your package on:
> http://packages.ubuntu.com/hardy/games/solarwolf
>
> --
> Regards,
> Wayne Koorts
> Registered Linux User #330079
> http://www.wkoorts.com
>

Re: [pygame] pygame on iPhone

[Charlie Nolan]

I think Hitler was less restrictive than Apple.

(What?  You knew someone was going to Godwin this sooner or later.  :)

-FM

On Sun, Oct 5, 2008 at 6:13 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> Also windows CE/windows mobile phones run python.
>
> It seems even microsoft is less restrictive, and more open than apple for 
> this.
>
>
> On Mon, Oct 6, 2008 at 3:51 AM, yanom @linuxmail.org
> <[EMAIL PROTECTED]> wrote:
>> I agree with you, Greg. I don't even have an iPhone, but python on the 
>> iPhone definitely would be nice. I hear Nokia phones already run Python.
>

Re: [pygame] Saving Alpha Channels

[Charlie Nolan]

Well, you could try getting the alpha array via
pygame.surfarray.pixels_alpha and then running:
alphas[...] = 128 # Sets all alpha values to 128.

Might have to run it through Surface.convert_alpha before it's got an
alpha array to work with, though.

-FM

On Sat, Oct 4, 2008 at 11:47 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 4, 2008 at 8:51 PM, Brad Montgomery <[EMAIL PROTECTED]>
> wrote:
>>
>> Would something like PIL's putalpha do what you want? (provided you *have*
>> PIL)
>
> Yes, I have PIL.
>>
>> http://www.pythonware.com/library/pil/handbook/image.htm (search for
>> putalpha)
>>
>> import Image
>> my_image = Image.open('somefile.jpg')
>> my_image.put_alpha(0)
>> my_image.save('somefile.png')
>>
>> This would convert all the black (int val for black = 0) in your image
>> to alpha's, but then you'd have to save to something that supports an
>> alpha channel.
>>
>> --
>> brad [bradmontgomery.net]
>
> Well, I want to set the alpha value for every pixel.  So, every pixel,
> regardless of its color should be 50% transparent.  The code I posted does
> that, but it doesn't save that alpha data to the file.
> Ian
>

Re: [pygame] Game Maker but with Python?

[Charlie Nolan]

Hey, don't let its future stop you.  Writing that kind of thing is
great practice, and you never know; you might come up with something
good.

On 10/1/08, Nathan Whitehead <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 1, 2008 at 5:09 PM, Ron Dippold <[EMAIL PROTECTED]> wrote:
> ...
>> It would be nice having a python scriptable Game Maker, but that would be
>> a
>> huge undertaking - it's 100x more work to write a game maker that requires
>> no coding than it is to write a single game. But you might take a look at
>> Game Wizard ( http://www.pygame.org/project/601/ )
>
> I agree, it would be a huge undertaking.  As much as I'm tempted to
> start coding it up, I realize that it would almost certainly never get
> finished and be a waste of effort.  But it's fun to think about!  And
> I really am tempted to code on it.
> --
> Nathan
>

Re: [pygame] AppState-0.1 released

[Charlie Nolan]

The idea is that most cheating will be obvious, so you can block
individual users who are polluting the high score table.  As Nathan
pointed out, though, getting a new Google account is pretty easy, so
even that's not terribly effective.

-FM

On 9/27/08, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Horst JENS wrote:
>
>> Somehow i would feel uncomfortable if i had to type in my gmail account
>> password just to upload an highscore - even if it's a open-source app.
>
> What's the reasoning behind requiring a password for
> this, anyway?
>
> As far as I can see, the only threat it protects against
> is someone else pretending to be you and giving you
> one of their high scores. But that benefits you, not
> them!
>
> To guard against people faking their own high scores,
> some kind of cryptographic arrangement is needed,
> not passwords. Even then, it's hard to see how you
> could prevent someone spoofing the protocol if the
> game is open source.
>
> --
> Greg
>
>

Re: [pygame] AppState-0.1 released

[Charlie Nolan]

Well, you could switch things up so that the users use the normal web
interface to get an auth token, which they put into the app.

-FM

On 9/27/08, Nathan Whitehead <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 27, 2008 at 9:04 AM, Horst JENS <[EMAIL PROTECTED]> wrote:
>> Somehow i would feel uncomfortable if i had to type in my gmail account
>> password just to upload an highscore - even if it's a open-source app.
>
> You don't have to use your gmail account, you can create a new Google
> Account just for gaming.  Just use something like
> "[EMAIL PROTECTED]" for your email.  Then go to
> mailinator.com to verify the email.  Works fine.
> --
> Nathan
>

Re: [pygame] Good code for text wrapping?

[Charlie Nolan]

I like Greg's suggestion, it sounds like the sanest way to handle
this.  I'll go ahead and rough out a skeleton system.

René - Yeah, I'm thinking we'll just use a bare class, since it's got
somewhat nicer syntax than a dict.  (style.bold instead of
style["bold"])  As far as inheritance goes, the default should
probably be to clobber everything, but it might be nice to allow
bleed-through too.  Useful, for instance, if you wanted to set the
entire passage bold but it already had individual
colors/italics/underline in place.

-FM

On 9/25/08, René Dudfield <[EMAIL PROTECTED]> wrote:
> hey,
>
> I like the idea of doing it as a separate module.
>
> 
> let's work on it here...
> http://code.google.com/p/pygame/
>
> branches/text/
>
> I've added you to the project... (if anyone else wants to help with
> it, please send me your email off list).
> 
>
>
> A simple style dict/class which goes along with each part of text
> would work fine I think.  This method seems to work ok for html/css
> etc.
>
> We need to make sure that styles can be applied inside of styles.  I
> guess a simple inheritance would work there?
>
> Either:
> - child styles inherit from the top, over riding what they declare?
> - child styles are completely new, inheriting nothing?
>
> I think the simplest implementation would to make the style be applied
> as is... with nothing inherited from the parent.  Then we can mess
> with inheritance of child styles separately.
>
>
> cheers,
>
>
>
>
>
> On Thu, Sep 25, 2008 at 4:16 PM, Charlie Nolan <[EMAIL PROTECTED]>
> wrote:
>> Sure, I'm always happy to help.  I guess the first issue to look at is
>> where to put this.
>>
>> One possibility would be methods on the font.Font class.
>> Pro:
>> * Right next to the normal render method and hence an obvious place to
>> look.
>> * We might even be able to fold it into the main render function.
>> Con:
>> * Forces us to stick with a single font for the entire text.
>> * Clutters up that class.  If we merge with render instead, we make it
>> much more complicated.
>> * Forced to use C, since we're working in a C class.  (AFAIK, there's
>> no way to mix like that without monkeypatching.)
>>
>> Another possibility would be in its own module, just as naked functions.
>> Pro:
>> * Simple to use.
>> * Everything's grouped together and easy to scan through.
>> Con:
>> * When we start incorporating styles, naked functions get clumsy (as
>> my example already shows).  There's just too much extra data that has
>> to be shoved into the function call.
>>
>> And the third that comes to mind is building a class that represents a
>> block of text with various properties and giving it a render method.
>> Pro:
>> * Styles, especially, benefit from the complexity segmentation this
>> provides.  The final attributes can be built piecemeal and in a
>> sensible order, instead of trying to shove everything into one
>> function call.
>> * This gives us an easy place to store glyph position data for
>> handling click/drag.
>> Con:
>> * Not as easy to use as naked functions, as creating an ordinary block
>> of wrapped text is now a two-step process.
>>
>> My preference would be either the class or a hybrid of class and naked
>> functions.  The hybrid would put the functionality into the naked
>> functions, with the class essentially acting as a "make this sane"
>> wrapper around the complex parts of the naked functions.
>>
>> -FM
>>
>> On 9/24/08, René Dudfield <[EMAIL PROTECTED]> wrote:
>>> hey,
>>>
>>> would you like to work with me in creating something for inclusion in
>>> pygame?
>>>
>>> This would mean working out a simple api, making docs, examples, and
>>> unittests.
>>>
>>> Something basic that we can have a look at, for adding the most easy
>>> and useful features.  We can try and avoid most of the tricky issues
>>> for now.
>>>
>>>
>>>
>>> If anyone else is interested, we can set up a google host page or
>>> something to work on it?
>>>
>>> cheers,
>>>
>>>
>>>
>>>
>>> On Tue, Sep 23, 2008 at 10:11 PM, Charlie Nolan <[EMAIL PROTECTED]>
>>> wrote:
>>>> A fair amount of this is already in that file, down in print_string
>>>> and print_line.  (You're welcome to as much of the file as you like,
>>>> but I'd strongly suggest 

Re: [pygame] Good code for text wrapping?

[Charlie Nolan]

Sure, I'm always happy to help.  I guess the first issue to look at is
where to put this.

One possibility would be methods on the font.Font class.
Pro:
* Right next to the normal render method and hence an obvious place to look.
* We might even be able to fold it into the main render function.
Con:
* Forces us to stick with a single font for the entire text.
* Clutters up that class.  If we merge with render instead, we make it
much more complicated.
* Forced to use C, since we're working in a C class.  (AFAIK, there's
no way to mix like that without monkeypatching.)

Another possibility would be in its own module, just as naked functions.
Pro:
* Simple to use.
* Everything's grouped together and easy to scan through.
Con:
* When we start incorporating styles, naked functions get clumsy (as
my example already shows).  There's just too much extra data that has
to be shoved into the function call.

And the third that comes to mind is building a class that represents a
block of text with various properties and giving it a render method.
Pro:
* Styles, especially, benefit from the complexity segmentation this
provides.  The final attributes can be built piecemeal and in a
sensible order, instead of trying to shove everything into one
function call.
* This gives us an easy place to store glyph position data for
handling click/drag.
Con:
* Not as easy to use as naked functions, as creating an ordinary block
of wrapped text is now a two-step process.

My preference would be either the class or a hybrid of class and naked
functions.  The hybrid would put the functionality into the naked
functions, with the class essentially acting as a "make this sane"
wrapper around the complex parts of the naked functions.

-FM

On 9/24/08, René Dudfield <[EMAIL PROTECTED]> wrote:
> hey,
>
> would you like to work with me in creating something for inclusion in
> pygame?
>
> This would mean working out a simple api, making docs, examples, and
> unittests.
>
> Something basic that we can have a look at, for adding the most easy
> and useful features.  We can try and avoid most of the tricky issues
> for now.
>
>
>
> If anyone else is interested, we can set up a google host page or
> something to work on it?
>
> cheers,
>
>
>
>
> On Tue, Sep 23, 2008 at 10:11 PM, Charlie Nolan <[EMAIL PROTECTED]>
> wrote:
>> A fair amount of this is already in that file, down in print_string
>> and print_line.  (You're welcome to as much of the file as you like,
>> but I'd strongly suggest you look into refactoring it.  It's good
>> enough for one isolated project, but probably not up to library
>> quality.)
>>
>>> - aligning text, left, right, center etc.
>>> - vertical alignment... top, bottom, center.
>>> - text color
>> Check.
>>
>>> - each part of text having a separate font/attributes.  So you can
>>> then do words with bold, italics etc.
>> Everything but the font is easy to extend (the font's ugly to do, and
>> probably overkill).  I've already got underline in there.  Might want
>> to swap the style list for a style dict/object, though, to avoid
>> degenerating into positional hell.
>>
>>> - selecting text.  Based on mouse click, which letter and word does it
>>> collide with?
>> I've already got the baseline in for this, by way of EditableText's
>> handle_click function.
>>
>>> - breaking words (word-break), so it can add a long word like
>>> "complexifcation" as "complexif-\ncation"
>>
>> More-or-less present.  Right now, it'll break on any character,
>> without adding a hyphen, but extending it shouldn't be hard.  Of
>> course, if you want intelligent hyphenation, that's an icky can of
>> worms all by itself.
>>
>>> - justify text.
>>> - letter spacing
>>> - line spacing
>>> - word spacing
>>> - indenting
>>> - padding around text.
>> Somewhat annoying, mostly because they affect selecting text.  With
>> this many weird things, it might be a good idea to look for a way to
>> merge the layout and select code, possibly by storing a map as you lay
>> things out.
>>
>>> - flowing around areas...
>>> - eg( place an image, and the text flows around it)
>>> - example here:  http://www.csstextwrap.com/example_for_demo.php
>> This one gets a bit ugly, and also runs into the layout/select
>> duplication mentioned above.
>>
>>> - splitting text up into 'pages',
>>> - different sized pages or Rects could be useful too.
>> Not too hard.  When the printing clips off the end of 

Re: [pygame] Good code for text wrapping?

[Charlie Nolan]

A fair amount of this is already in that file, down in print_string
and print_line.  (You're welcome to as much of the file as you like,
but I'd strongly suggest you look into refactoring it.  It's good
enough for one isolated project, but probably not up to library
quality.)

> - aligning text, left, right, center etc.
> - vertical alignment... top, bottom, center.
> - text color
Check.

> - each part of text having a separate font/attributes.  So you can
> then do words with bold, italics etc.
Everything but the font is easy to extend (the font's ugly to do, and
probably overkill).  I've already got underline in there.  Might want
to swap the style list for a style dict/object, though, to avoid
degenerating into positional hell.

> - selecting text.  Based on mouse click, which letter and word does it
> collide with?
I've already got the baseline in for this, by way of EditableText's
handle_click function.

> - breaking words (word-break), so it can add a long word like
> "complexifcation" as "complexif-\ncation"

More-or-less present.  Right now, it'll break on any character,
without adding a hyphen, but extending it shouldn't be hard.  Of
course, if you want intelligent hyphenation, that's an icky can of
worms all by itself.

> - justify text.
> - letter spacing
> - line spacing
> - word spacing
> - indenting
> - padding around text.
Somewhat annoying, mostly because they affect selecting text.  With
this many weird things, it might be a good idea to look for a way to
merge the layout and select code, possibly by storing a map as you lay
things out.

> - flowing around areas...
> - eg( place an image, and the text flows around it)
> - example here:  http://www.csstextwrap.com/example_for_demo.php
This one gets a bit ugly, and also runs into the layout/select
duplication mentioned above.

> - splitting text up into 'pages',
> - different sized pages or Rects could be useful too.
Not too hard.  When the printing clips off the end of the available
area, you move on to the next one.

> - scrolling text.
Are you thinking marquee or scrollbar?  Either one seems out of scope.

> - text render method.
Not sure we need/want this, but it would be easy enough to add.  You'd
also want to add a way to replace the related methods (metrics,
get_linesize, etc.).  My main worry here is scope creep.  Actually, if
you're going into this much depth, wouldn't you just subclass
pygame.Font?

---

>  - text flow other than left->right (right->left, mixed, top->down)
I think this really belongs upstream in SDL, assuming it's not there
already.  Once it renders a string correctly, this is just another
easy layout/select issue.

>  - support for non-letter fonts (e.g. button glyphs for help text) --
>  although I suppose you could handle it by something you described,
>  flowing text around images, if the images could be floated as well
I'm pretty sure you can do this already.  As long as you have the
font, you can render whatever you like in it.

>  - support for non-breaking spaces and hyphens
NBSP is handled correctly.  Hyphens fall under breaking words properly.

>  - proper handling of line-breaking in different languages (e.g.,
>  French inserts a space or two between the last letter of a sentence
>  and a final exclamation point, don't want to break there, some
>  languages consider certain combinations of letters to really be only
>  one, can't break in between them, etc.)
Most of this falls under word breaks again.  French's pre-! space is
kinda annoying, unless they already use an NBSP.

>  - proper support for full Unicode fonts
I haven't run into anything broken here.  DejaVu seems to render
perfectly well.  Most of this is up to SDL, though we'd have to pay
attention to control characters (switching RTL/LTR without warning
does ugly things).

---

Most of this isn't too bad to add to what I've already got, but you'd
want to be really careful with adding them one-by-one.  It'd be really
easy to get scope creep or just turn the entire thing into hacks of
hacks.

In some ways, I'd be relieved if you didn't use my code, because it's
already held together with duct tape and baling wire.  Unfortunately,
I'm not sure there *is* a sane way to handle this stuff, there are
just too many special cases.

I think the important thing is to get something in soonish that
handles as many of the common cases as we can.  We don't want this
degenerating into something that will come out shortly after Duke
Nukem Forever.

-FM

Re: [pygame] Good code for text wrapping?

[Charlie Nolan]

I'll happily chip in my word-wrap code, if you want it as a starting
point for pygame.  It's not beautiful, but it does have a very nice
property:

orig_string[x] -> "".join(wrapped_string)[x]

They're not always equal, because it converts some spaces to a
zero-width character for alignment purposes.  (The char was originally
\x00, hence strip_to_null, but that caused issues elsewhere,
presumably with C strings.)

http://code.google.com/p/endgame-singularity/source/browse/trunk/code/graphics/text.py?r=892

-FM

On 9/17/08, pymike <[EMAIL PROTECTED]> wrote:
> Yeah pygame.font needs support for \n. :P
>
> On Wed, Sep 17, 2008 at 2:31 PM, Charlie Nolan
> <[EMAIL PROTECTED]>wrote:
>
>> Hmm, I've written this too.  Given that it seems pretty common,
>> wouldn't this be a good candidate for adding to pygame.font.Font?
>>
>> -FM
>>
>> On 9/16/08, Marius Gedminas <[EMAIL PROTECTED]> wrote:
>> > On Tue, Sep 16, 2008 at 12:11:45PM +1000, René Dudfield wrote:
>> >> The cookbook has this entry, but it doesn't work with new lines.
>> >> http://www.pygame.org/wiki/TextWrapping
>> >>
>> >> Anyone have any code like this that supports new lines?
>> >
>> > http://mg.pov.lt/pyspacewar/trac/browser/trunk/src/pyspacewar/ui.py#L466
>> >
>> > Output example: http://mg.pov.lt/pyspacewar/pyspacewar-help-screen.png
>> >
>> > It's GPL-ed, feel free to use or ask me for a licence change if that's
>> > not suitable.
>> >
>> > Marius Gedminas
>> > --
>> > If you are smart enough to know that you're not smart enough to be an
>> > Engineer, then you're in Business.
>> >
>>
>
>
>
> --
> - pymike (http://pymike.4rensics.org/)
>

Re: [pygame] pygame.org - update finished!

[Charlie Nolan]

While we're on the subject of docs, it'd be really nice to have older
documentation available.  Not everybody is running the bleeding-edge
version, and it's frustrating to find something useful only to realize
it's not in the version you have (or have to use).

-FM

On 9/18/08, KKarasu <[EMAIL PROTECTED]> wrote:
> Hi ian.
>
> Mmm just one thing i found dificult to find the pdf release of the
> reference guide shouldnt be on the docs page?
> I know there is one. but i just found it googling it.
> It should be a not in the documents page showing it available for download.
> its very usefull when u dont have net or the site is down...as it
> happened this week.
>
>
>
> Ian Mallett wrote:
>> http://www.pygame.org/docs/
>> doesn't have links to the modules Color and Scrap and the alphabetical
>> order is incorrect in some places.
>>
>> Ian
>
>

Re: [pygame] Good code for text wrapping?

[Charlie Nolan]

Hmm, I've written this too.  Given that it seems pretty common,
wouldn't this be a good candidate for adding to pygame.font.Font?

-FM

On 9/16/08, Marius Gedminas <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at 12:11:45PM +1000, René Dudfield wrote:
>> The cookbook has this entry, but it doesn't work with new lines.
>> http://www.pygame.org/wiki/TextWrapping
>>
>> Anyone have any code like this that supports new lines?
>
> http://mg.pov.lt/pyspacewar/trac/browser/trunk/src/pyspacewar/ui.py#L466
>
> Output example: http://mg.pov.lt/pyspacewar/pyspacewar-help-screen.png
>
> It's GPL-ed, feel free to use or ask me for a licence change if that's
> not suitable.
>
> Marius Gedminas
> --
> If you are smart enough to know that you're not smart enough to be an
> Engineer, then you're in Business.
>

Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux

[Charlie Nolan]

That's duplicating my results on Gentoo, too.  I guess that confirms
that this one is upstream.

-FM

On 9/4/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> Attached is a C version of font_test.py. It takes a font size as its
> only argument. Running the program for both pitch 21 and 210 I get the
> same results as I get for font_test.py.
>
> Lenard
>
>
> Lenard Lindstrom wrote:
>>
>> I can't account for why the numbers match at a pitch of 210, but not
>> 21. I did find the place in SDL_ttf where the dpi is set to the
>> FreeType default of 72. And the post to the FreeType mailing list I
>> referred to earlier,
>> http://lists.nongnu.org/archive/html/freetype-devel/2002-08/msg00020.html,
>>
>> does imply that font size, in pixels, is affected by some operating
>> system provided value. But then this could involve values passed to
>> FreeType or FreeType as a display driver. On Windows there are no
>> explicit Windows api calls, just C library calls. So I don't know what
>> I imply any more. Maybe a C only version of font_test.py will clear
>> some things up.
>>
>> Lenard
>>
>>
>> Brian Fisher wrote:
>>> Lenard, are you saying you think it still may be a dpi problem?
>>>
>>> cause I think if dpi was the problem in this case, the discrepancy
>>> would scale with font size. But as there is no discrepancy between
>>> the platforms when the font size is 210 (i.e. charlies gentoo matches
>>> your windows box), it seems to me that dpi (or any font scaling
>>> really) is not different, and therefore not the cause here
>>>
>>> I really think SDL_ttf is fixing the freetype scaling so it doesn't
>>> vary with platform. It would just make sense.
>>>
>>> did I misunderstand or am I missing something there?
>>>
>>>
>>> On Thu, Sep 4, 2008 at 1:38 PM, Lenard Lindstrom <[EMAIL PROTECTED]
>>> > wrote:
>>>
>>> As for display point size, that may be the case with Windows, but
>>> what about Unix.
>>>
>>>
>>
>>
>
>

Re: [pygame] Question - Comparing strings

[Charlie Nolan]

Okay, I admit it, I'm bored enough to look deeper.  Offhand, I see a
few things that don't fit right.

> def WordSelection():

In Python, we write function names like_this.  CamelCase is for
classes, UPPERCASE for constants.  Everything else gets
lowercase_with_underscores.  It's just a style convention, but it
makes it _much_ easier for others to read your code.  I'll make the
switch when I rewrite a line, just be sure to change things uniformly.

> if WordListFile == "default" or "default" or "Default" or "d" or "D":

This does not do what you think it does.  What you want is this:
if word_list_file.lower() in ("default", "d"):

> MaxLine = linecache.getline(WordListFile, 1)
> GottenWord = linecache.getline(WordListFile, random.randint(2, MaxLine))

You've got a type problem here.  Python doesn't require you to declare
what type any variable is, but it does rigidly enforce them.
Essentially, what's happening is that somewhere in random, a bit of
code will try to do this:
"4" + 1

Since there are two logical ways to put these together, "41" and 5,
Python just disallows adding strings and ints together.  What you need
to do is convert, like so:
max_line = int(linecache.getline(word_list_file, 1))

You're also getting your lines the Hard Way(tm).  It's much easier to
leave out the line count and do this:
lines = open(file_name).readlines()
chosen_word = random.choice(lines).strip()

When you go a step further and allow multiple words, you should make
sure that you grab the lines before you enter the loop, so that you
only fetch them once.

-FM

On 9/4/08, Charlie Nolan <[EMAIL PROTECTED]> wrote:
> Glad to see a new newbie, it's the only way to get experts.  On the
> other hand, this is the *pygame* mailing list.  We use python, but
> it's not exactly the topic at hand.  For more general discussion, try
> one of the places listed here:
> http://python.org/community/
>
>
> That said, I'm a nice guy, so you get a free pass this time.  It
> sounds like you've probably got whitespace hanging around that you
> don't want.  Try changing this:
> print "the word was", word, "and you guessed", guess
> to this:
> print "the word was %r and you guessed %r" % (word, guess)
>
> My guess is that you'll get something like this printed out:
> the word was 'cheese\n' and you guessed 'cheese'
>
> In that case, just add .strip() to the end of whichever line you set
> that variable on, so in my example, it'd change this:
> word = WordSelection()
> to this:
> word = WordSelection().strip()
>
> -FM
>
> On 9/4/08, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Hey,
>> I only recently found out about Python and started looking at it a
>> week ago. It seems like a brilliant coding language.
>>
>>  I'm starting by making a small simple "guess the word" (hangman
>> clone) type game. The game selects a random word from a .txt file
>> (with the option to either use the standard txt file or enter your
>> own).
>>
>> The two problems I have is:
>> 1. When I compare the word the person guesses and the word the program
>> chose, it treats it as the "wrong word" no matter what.
>>
>> 2. When I try puttin a number on the first line of the file (to be
>> used in the random number generator so that it cuts the range down to
>> between 2 and number-of-lines-in-file) I get: "TypeError: cannot
>> concatenate 'str' and 'int' objects"
>>
>> I'm completely new at this, and I can't seem to find a sollution in
>> any of the documentation or tutorial pages...
>>
>> the code:
>> import random # Imports lib for random function
>> import linecache  # Imports lib for reading one line from a file
>>
>> def WordSelection():
>>  WordListFile = raw_input("enter word list file name, or choose the
>> (d)efault list: ")
>>  if WordListFile == "default" or "default" or "Default" or "d" or "D":
>>  WordListFile = "WordList.txt"
>>  MaxLine = linecache.getline(WordListFile, 1)
>>  GottenWord = linecache.getline(WordListFile, random.randint(2,
>> MaxLine))
>>  return GottenWord
>>
>> print "Welcome to Guess The Word"
>> print "v0.1b by: Esc"
>> word = WordSelection()
>> print "the word is: ", word
>> guess = raw_input()
>> print "the word was", word, "and you guessed", guess
>>
>> if guess == word:
>>  print "well done, that was correct."
>> else:
>>  print "to bad, that was incorrect."
>>
>>
>> The .txt file:
>> 5 <- the highest
>> random number
>> cheese   \
>> apple} The words that the
>> program reads
>> pear  } and uses in the game.
>> nut   /
>>
>> When I remove MaxLine and put in 4 instead it works like a charm.
>>
>> hope someone can help,
>> - esc
>>
>

Re: [pygame] Question - Comparing strings

[Charlie Nolan]

Glad to see a new newbie, it's the only way to get experts.  On the
other hand, this is the *pygame* mailing list.  We use python, but
it's not exactly the topic at hand.  For more general discussion, try
one of the places listed here:
http://python.org/community/


That said, I'm a nice guy, so you get a free pass this time.  It
sounds like you've probably got whitespace hanging around that you
don't want.  Try changing this:
print "the word was", word, "and you guessed", guess
to this:
print "the word was %r and you guessed %r" % (word, guess)

My guess is that you'll get something like this printed out:
the word was 'cheese\n' and you guessed 'cheese'

In that case, just add .strip() to the end of whichever line you set
that variable on, so in my example, it'd change this:
word = WordSelection()
to this:
word = WordSelection().strip()

-FM

On 9/4/08, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hey,
> I only recently found out about Python and started looking at it a
> week ago. It seems like a brilliant coding language.
>
>  I'm starting by making a small simple "guess the word" (hangman
> clone) type game. The game selects a random word from a .txt file
> (with the option to either use the standard txt file or enter your
> own).
>
> The two problems I have is:
> 1. When I compare the word the person guesses and the word the program
> chose, it treats it as the "wrong word" no matter what.
>
> 2. When I try puttin a number on the first line of the file (to be
> used in the random number generator so that it cuts the range down to
> between 2 and number-of-lines-in-file) I get: "TypeError: cannot
> concatenate 'str' and 'int' objects"
>
> I'm completely new at this, and I can't seem to find a sollution in
> any of the documentation or tutorial pages...
>
> the code:
> import random # Imports lib for random function
> import linecache  # Imports lib for reading one line from a file
>
> def WordSelection():
>   WordListFile = raw_input("enter word list file name, or choose the
> (d)efault list: ")
>   if WordListFile == "default" or "default" or "Default" or "d" or "D":
>   WordListFile = "WordList.txt"
>   MaxLine = linecache.getline(WordListFile, 1)
>   GottenWord = linecache.getline(WordListFile, random.randint(2,
> MaxLine))
>   return GottenWord
>
> print "Welcome to Guess The Word"
> print "v0.1b by: Esc"
> word = WordSelection()
> print "the word is: ", word
> guess = raw_input()
> print "the word was", word, "and you guessed", guess
>
> if guess == word:
>   print "well done, that was correct."
> else:
>   print "to bad, that was incorrect."
>
>
> The .txt file:
> 5 <- the highest
> random number
> cheese   \
> apple} The words that the
> program reads
> pear  } and uses in the game.
> nut   /
>
> When I remove MaxLine and put in 4 instead it works like a charm.
>
> hope someone can help,
> - esc
>

Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux

[Charlie Nolan]

Ah, good.  Couldn't bear to look at the replies until I was
half-asleep, just in case things blew up in my face.  Glad to see my
various fears were unfounded.  :)

James:
It was attached to the original post, looks like Brian re-attached it for you.

Brian:
Aha, test results!  Much appreciated.

René:
Looks like Gentoo builds a pretty standard SDL_ttf.  No patches, it
just specifies the various paths and passes on the system "Do I have
X11?" flag.

Brian (again):
I've only spotted the discrepancy at that particular size.  If you,
for instance, bump the size way up to 210 (exactly 10x the original),
you get this under Gentoo:

(110, 143)
(110, 143)




[(0, 95, 0, 79, 110), (0, 95, 0, 79, 110)]
[(0, 95, 0, 79, 110), (0, 95, 0, 79, 110)]

No mismatch in the letters at all.  I'd cross-check in Windows, but
VMware took offense to my most recent kernel upgrade and is out of
commission for the time being.  From other tests I'd run while finding
the correct conditions to reproduce the discrepancy, I predict that if
you run it on either of your test systems, you'll get identical
results.

Looking at the behavior of the font at other sizes, it looks like
*both* of the observed results are anomalous, but that the Gentoo
flavor happens to cancel itself for display purposes.  Not sure how
helpful that bit of information is, though.

-FM

On 9/2/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
> Hmm.. looks like SDL_ttf claims that it opens fonts at 72 dpi:
> http://jcatki.no-ip.org:8080/SDL_ttf/SDL_ttf_frame.html
>
> ... so how is the point size supposed to map to pixels then? Does 72 dpi
> seem to be correct?
>
> Also, if you make the font much much bigger, does the size discrepancy on
> gentoo Linux get bigger proportionally as well?
>
> On Tue, Sep 2, 2008 at 10:30 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
>
>> Hi Charlie,
>>
>> Your problem was not being ignored. But I could find any operating
>> dependent places in pygame.font. Apparently there are though. Character
>> size, in pixels, depends not just on pitch, but also on the screen
>> resolution, dots per inch. This is a feature of FreeTypes, on which
>> pygame.font is built. The screen resolution is an arbitrary value that can
>> vary with operating system, and can be customized on Windows. I will look
>> to
>> see if the screen resolution can be set for FreeTypes when I get the time.
>> Here is a link to the FreeTypes mailing list posting explaining why pixel
>> sizes vary:
>>
>> http://lists.nongnu.org/archive/html/freetype-devel/2002-08/msg00020.html
>>
>> Lenard
>>
>>
>>
>> Charlie Nolan wrote:
>>
>>> Okay, we don't quite seem to be understanding each other here, so let
>>> me be explicit.
>>>
>>> 1. This is not a large issue, and I understand that.  It's a 1-pixel
>>> error, and if there are other priorities at the moment, fine, say
>>> that.  At the same time, that 1-pixel error triggered word-wrapping
>>> and caused a perplexing bug on my end.  Isn't this exactly the kind of
>>> cross-platform issue that python and pygame are supposed to prevent?
>>>
>>> 2. I am not a C/++ coder, nor do I know SDL.  Last I checked, that was
>>> kinda the point of pygame: you don't have to.  From where I sit, this
>>> looks like a bug.  It's possible that it's a version mismatch or some
>>> obscure option, but I've got no way to determine that unless you tell
>>> me how.
>>>
>>> 3. As mentioned, I suspect this is an underlying SDL issue.  As a
>>> result of point 2, I can't exactly go to them with this myself,
>>> because I neither know nor care about how pygame handles fonts.  I
>>> just want it to work correctly.  Therefore, if this is an SDL issue, I
>>> need someone to take it to them for me.
>>>
>>> 4. We could rapidly narrow down the list of possibilities if a couple
>>> people would take 5 minutes (if that) to run the test I gave and see
>>> who's affected by it.  I have confirmation from my end that it's
>>> appeared on at least three separate Windows systems, so other *NIX
>>> results would be particularly useful, and not, I would think, terribly
>>> hard to come by here.
>>>
>>> 5. In the abscence of suggestions or external test results, I am left
>>> to assume that I'm being ignored and/or swept under the carpet.  I've
>>> done my best to give you every piece of information I could, so I
>>> don't feel it's unreasonable to expect minimal effort on your part in
>>> return.  Throw me a bon

Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux

[Charlie Nolan]

Okay, we don't quite seem to be understanding each other here, so let
me be explicit.

1. This is not a large issue, and I understand that.  It's a 1-pixel
error, and if there are other priorities at the moment, fine, say
that.  At the same time, that 1-pixel error triggered word-wrapping
and caused a perplexing bug on my end.  Isn't this exactly the kind of
cross-platform issue that python and pygame are supposed to prevent?

2. I am not a C/++ coder, nor do I know SDL.  Last I checked, that was
kinda the point of pygame: you don't have to.  From where I sit, this
looks like a bug.  It's possible that it's a version mismatch or some
obscure option, but I've got no way to determine that unless you tell
me how.

3. As mentioned, I suspect this is an underlying SDL issue.  As a
result of point 2, I can't exactly go to them with this myself,
because I neither know nor care about how pygame handles fonts.  I
just want it to work correctly.  Therefore, if this is an SDL issue, I
need someone to take it to them for me.

4. We could rapidly narrow down the list of possibilities if a couple
people would take 5 minutes (if that) to run the test I gave and see
who's affected by it.  I have confirmation from my end that it's
appeared on at least three separate Windows systems, so other *NIX
results would be particularly useful, and not, I would think, terribly
hard to come by here.

5. In the abscence of suggestions or external test results, I am left
to assume that I'm being ignored and/or swept under the carpet.  I've
done my best to give you every piece of information I could, so I
don't feel it's unreasonable to expect minimal effort on your part in
return.  Throw me a bone, here!

-FM

On 9/2/08, René Dudfield <[EMAIL PROTECTED]> wrote:
> hi,
>
> It's likely the different compilation options for freetype. Or even
> gentoo specific patches to freetype or sdl_ttf.
>
> Otherwise it could be different bitdepth surfaces.  eg, 24bit on one
> machine and 16bit on another.
>
> cheers,
>
>
> On Tue, Sep 2, 2008 at 4:04 PM, Charlie Nolan <[EMAIL PROTECTED]>
> wrote:
>> *taps on the glass*  Anybody out there?
>>
>> On 8/25/08, Charlie Nolan <[EMAIL PROTECTED]> wrote:
>>> So, anything else you want me to poke at, or is someone going to take
>>> a look?  For that matter, have you guys been able to duplicate the
>>> problem?
>>>
>>> -FM
>>>
>>> On 8/23/08, Charlie Nolan <[EMAIL PROTECTED]> wrote:
>>>> It was at 2.3.7.  I downgraded it to 2.3.5 temporarily, and it shows
>>>> the same results as 2.3.7.
>>>>
>>>> -FM
>>>>
>>>> On 8/22/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
>>>>> That's right for SDL_ttf. What freetype version does Gentoo have.
>>>>> Pygame
>>>>> 1.8 uses freetype-2.3.5 on Windows.
>>>>>
>>>>> Lenard
>>>>>
>>>>>
>>>>> Charlie Nolan wrote:
>>>>>> SDL_ttf is at 2.0.9 on Linux, and after digging a bit, the SDL_ttf.dll
>>>>>> that came with pygame shows version 2.0.9.0.  Looks like a match to
>>>>>> me.
>>>>>>
>>>>>> On 8/22/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> It may be a difference between different versions of SDL_ttf or of
>>>>>>> freetype,
>>>>>>> which may not be a bug if the new er behavior is part of a bug fix.
>>>>>>>
>>>>>>> So what version of SDL_ttf do you have on Windows and on Linux?
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Aug 22, 2008 at 12:04 PM, Charlie Nolan
>>>>>>> <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I suspect this will just get passed upstream to SDL, but someone
>>>>>>>> will
>>>>>>>> need to translate for them.
>>>>>>>>
>>>>>>>> The "7" glyph in the attached font at size 21 behaves inconsistently
>>>>>>>> on Windows (XP SP2) and Linux (Gentoo).  Running the test script on
>>>>>>>> the two systems, I get these results:
>>>>>>>>
>>>>>>>> Linux:
>>>>>>>> (11, 16)
>>>>>>>> (12, 16)
>>>>>>>>
>>>>>>>> 
>>>>>>>> 
>>>>>>>>
>>>>>>>> [(0, 9, 0, 8, 11), (0, 9, 0, 8, 11)]
>>>>>>>> [(0, 9, 0, 8, 11), (-1, 9, 0, 8, 11)]
>>>>>>>>
>>>>>>>>
>>>>>>>> Windows:
>>>>>>>> (11, 16)
>>>>>>>> (12, 16)
>>>>>>>>
>>>>>>>> 
>>>>>>>> 
>>>>>>>>
>>>>>>>> [(0, 10, 0, 8, 11), (0, 10, 0, 8, 11)]
>>>>>>>> [(0, 10, 0, 8, 11), (0, 11, 0, 8, 12)]
>>>>>>>>
>>>>>>>>
>>>>>>>> My interpretation of this is that the 7 is behaving a bit screwy at
>>>>>>>> that size.  It renders as 12x16, but has an X offset of -1, for an
>>>>>>>> effective size of 11x16.  On Windows, the X offset appears to be
>>>>>>>> lost,
>>>>>>>> thus causing the glyph to incorrectly have an extra pixel of padding
>>>>>>>> on the left.
>>>>>>>>
>>>>>>>> I'm also puzzled as to why maxx is one larger on Windows, but that
>>>>>>>> part doesn't seem to cause a problem.
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux

[Charlie Nolan]

*taps on the glass*  Anybody out there?

On 8/25/08, Charlie Nolan <[EMAIL PROTECTED]> wrote:
> So, anything else you want me to poke at, or is someone going to take
> a look?  For that matter, have you guys been able to duplicate the
> problem?
>
> -FM
>
> On 8/23/08, Charlie Nolan <[EMAIL PROTECTED]> wrote:
>> It was at 2.3.7.  I downgraded it to 2.3.5 temporarily, and it shows
>> the same results as 2.3.7.
>>
>> -FM
>>
>> On 8/22/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
>>> That's right for SDL_ttf. What freetype version does Gentoo have. Pygame
>>> 1.8 uses freetype-2.3.5 on Windows.
>>>
>>> Lenard
>>>
>>>
>>> Charlie Nolan wrote:
>>>> SDL_ttf is at 2.0.9 on Linux, and after digging a bit, the SDL_ttf.dll
>>>> that came with pygame shows version 2.0.9.0.  Looks like a match to
>>>> me.
>>>>
>>>> On 8/22/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> It may be a difference between different versions of SDL_ttf or of
>>>>> freetype,
>>>>> which may not be a bug if the new er behavior is part of a bug fix.
>>>>>
>>>>> So what version of SDL_ttf do you have on Windows and on Linux?
>>>>>
>>>>>
>>>>> On Fri, Aug 22, 2008 at 12:04 PM, Charlie Nolan
>>>>> <[EMAIL PROTECTED]>wrote:
>>>>>
>>>>>
>>>>>> I suspect this will just get passed upstream to SDL, but someone will
>>>>>> need to translate for them.
>>>>>>
>>>>>> The "7" glyph in the attached font at size 21 behaves inconsistently
>>>>>> on Windows (XP SP2) and Linux (Gentoo).  Running the test script on
>>>>>> the two systems, I get these results:
>>>>>>
>>>>>> Linux:
>>>>>> (11, 16)
>>>>>> (12, 16)
>>>>>>
>>>>>> 
>>>>>> 
>>>>>>
>>>>>> [(0, 9, 0, 8, 11), (0, 9, 0, 8, 11)]
>>>>>> [(0, 9, 0, 8, 11), (-1, 9, 0, 8, 11)]
>>>>>>
>>>>>>
>>>>>> Windows:
>>>>>> (11, 16)
>>>>>> (12, 16)
>>>>>>
>>>>>> 
>>>>>> 
>>>>>>
>>>>>> [(0, 10, 0, 8, 11), (0, 10, 0, 8, 11)]
>>>>>> [(0, 10, 0, 8, 11), (0, 11, 0, 8, 12)]
>>>>>>
>>>>>>
>>>>>> My interpretation of this is that the 7 is behaving a bit screwy at
>>>>>> that size.  It renders as 12x16, but has an X offset of -1, for an
>>>>>> effective size of 11x16.  On Windows, the X offset appears to be lost,
>>>>>> thus causing the glyph to incorrectly have an extra pixel of padding
>>>>>> on the left.
>>>>>>
>>>>>> I'm also puzzled as to why maxx is one larger on Windows, but that
>>>>>> part doesn't seem to cause a problem.
>>>>>>
>>>>>>
>>>
>>>
>>
>

Re: [pygame] Fill doesn't seem to work as expected.

[Charlie Nolan]

Actually, come to think of it, it might be a good idea to add a
function that has the expected effect.  Essentially the optimized C
equivalent of:

def naive_fill(self, color, rect, flags):
blit_me = pygame.Surface(rect[2:])
blit_me.fill(color, None, flags)
self.blit(blit_me, rect)

Not sure what you'd call it, though.

-FM

On 8/30/08, Charlie Nolan <[EMAIL PROTECTED]> wrote:
> It's a bit confusing at first, until you realize what fill is: It's a
> way to set large numbers of pixels to the same value, completely
> ignoring whatever was there before.  Since this is a write-only,
> no-decision operation, it's very fast.  The flags are just extra
> attributes that you're setting, beyond the normal RGBA.
>
> The correct method is, as you discovered, to blit another surface onto
> the first one.  Alternatively, you could try iterating through a
> surfarray, which might be faster, since you don't have to read another
> surface.
>
> -FM
>
> On 8/29/08, Ron Dippold <[EMAIL PROTECTED]> wrote:
>> This is pygame 1.8.1 on WinXP, DX9.
>>
>> I'm trying to dim the entire window for a pause screen. It seems like the
>> logical way to do this would be to
>>
>> # screen = pygame.display.set_mode( (800,600), 0 )   at start of
>> program
>> screen.get_surface().fill( (100,100,100), None, BLEND_MULT )
>>
>> but this results in everything being turned hideously green/cyan (and not
>> dimmer at all). It doesn't seem to matter whether I use BLEND_RGB_MULT,
>> BLEND_RGBA_MULT, or even ADD/SUB instead of MULT, or specify the rect
>> instead of None.
>>
>> What does work is to do:
>>  dim = pygame.Surface( screen.get_size() ).convert()
>>  dim.fill( ( 100, 100, 100 ) )
>>  screen.blit( dim, (0,0), None, BLEND_MULT )
>> which does exactly what I'd expect.
>>
>> Am I missing something on the .fill method? I can use the workaround, so
>> this is just curiosity.
>>
>> Ron
>>
>>
>>
>>
>

Re: [pygame] Fill doesn't seem to work as expected.

[Charlie Nolan]

It's a bit confusing at first, until you realize what fill is: It's a
way to set large numbers of pixels to the same value, completely
ignoring whatever was there before.  Since this is a write-only,
no-decision operation, it's very fast.  The flags are just extra
attributes that you're setting, beyond the normal RGBA.

The correct method is, as you discovered, to blit another surface onto
the first one.  Alternatively, you could try iterating through a
surfarray, which might be faster, since you don't have to read another
surface.

-FM

On 8/29/08, Ron Dippold <[EMAIL PROTECTED]> wrote:
> This is pygame 1.8.1 on WinXP, DX9.
>
> I'm trying to dim the entire window for a pause screen. It seems like the
> logical way to do this would be to
>
> # screen = pygame.display.set_mode( (800,600), 0 )   at start of program
> screen.get_surface().fill( (100,100,100), None, BLEND_MULT )
>
> but this results in everything being turned hideously green/cyan (and not
> dimmer at all). It doesn't seem to matter whether I use BLEND_RGB_MULT,
> BLEND_RGBA_MULT, or even ADD/SUB instead of MULT, or specify the rect
> instead of None.
>
> What does work is to do:
>   dim = pygame.Surface( screen.get_size() ).convert()
>   dim.fill( ( 100, 100, 100 ) )
>   screen.blit( dim, (0,0), None, BLEND_MULT )
> which does exactly what I'd expect.
>
> Am I missing something on the .fill method? I can use the workaround, so
> this is just curiosity.
>
> Ron
>
>
>
>

Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux

[Charlie Nolan]

So, anything else you want me to poke at, or is someone going to take
a look?  For that matter, have you guys been able to duplicate the
problem?

-FM

On 8/23/08, Charlie Nolan <[EMAIL PROTECTED]> wrote:
> It was at 2.3.7.  I downgraded it to 2.3.5 temporarily, and it shows
> the same results as 2.3.7.
>
> -FM
>
> On 8/22/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
>> That's right for SDL_ttf. What freetype version does Gentoo have. Pygame
>> 1.8 uses freetype-2.3.5 on Windows.
>>
>> Lenard
>>
>>
>> Charlie Nolan wrote:
>>> SDL_ttf is at 2.0.9 on Linux, and after digging a bit, the SDL_ttf.dll
>>> that came with pygame shows version 2.0.9.0.  Looks like a match to
>>> me.
>>>
>>> On 8/22/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
>>>
>>>> It may be a difference between different versions of SDL_ttf or of
>>>> freetype,
>>>> which may not be a bug if the new er behavior is part of a bug fix.
>>>>
>>>> So what version of SDL_ttf do you have on Windows and on Linux?
>>>>
>>>>
>>>> On Fri, Aug 22, 2008 at 12:04 PM, Charlie Nolan
>>>> <[EMAIL PROTECTED]>wrote:
>>>>
>>>>
>>>>> I suspect this will just get passed upstream to SDL, but someone will
>>>>> need to translate for them.
>>>>>
>>>>> The "7" glyph in the attached font at size 21 behaves inconsistently
>>>>> on Windows (XP SP2) and Linux (Gentoo).  Running the test script on
>>>>> the two systems, I get these results:
>>>>>
>>>>> Linux:
>>>>> (11, 16)
>>>>> (12, 16)
>>>>>
>>>>> 
>>>>> 
>>>>>
>>>>> [(0, 9, 0, 8, 11), (0, 9, 0, 8, 11)]
>>>>> [(0, 9, 0, 8, 11), (-1, 9, 0, 8, 11)]
>>>>>
>>>>>
>>>>> Windows:
>>>>> (11, 16)
>>>>> (12, 16)
>>>>>
>>>>> 
>>>>> 
>>>>>
>>>>> [(0, 10, 0, 8, 11), (0, 10, 0, 8, 11)]
>>>>> [(0, 10, 0, 8, 11), (0, 11, 0, 8, 12)]
>>>>>
>>>>>
>>>>> My interpretation of this is that the 7 is behaving a bit screwy at
>>>>> that size.  It renders as 12x16, but has an X offset of -1, for an
>>>>> effective size of 11x16.  On Windows, the X offset appears to be lost,
>>>>> thus causing the glyph to incorrectly have an extra pixel of padding
>>>>> on the left.
>>>>>
>>>>> I'm also puzzled as to why maxx is one larger on Windows, but that
>>>>> part doesn't seem to cause a problem.
>>>>>
>>>>>
>>
>>
>

Re: [pygame] Re: pygame key repeat

[Charlie Nolan]

Heh, we're all basically repeating each other, here.

Anyway, the way to use get_pressed is to drop it into a variable, then
index into it with the pygame.K_* constants.

keys = pygame.key.get_pressed()
if keys[pygame.K_UP]:
  pass # Up key is down

etc.

[pygame] Re:

[Charlie Nolan]

For continuous movement, it's generally better to ignore key events
and just check to see which keys are down (via pygame.key.get_pressed)
once every tick.

On 8/24/08, yanom @linuxmail.org <[EMAIL PROTECTED]> wrote:
> I have a problem with my pygame project:
> i used pygame.key.set_repeat(2,2) to make it so that continually holding
> down the left or right arrow keys moves a character. i have a problem
> though:
> whenever i press a key other than left or right, even if i am still holding
> an arrow key, my character stops moving. here is my code:
>
>
>
>
> import pygame, os, sys
> from pygame.locals import *
> pygame.init()
> clock = pygame.time.Clock()#start the clock
> screen = pygame.display.set_mode((640, 680), 0, 32)#create the screen,
> conveniently called screen
> enemy = pygame.image.load("enemy.sub.png").convert_alpha()#load sub images
> player = pygame.image.load("player.sub.png").convert_alpha()
> enemyrect = enemy.get_rect() #create rects
> playerrect = player.get_rect()
> playerrect = playerrect.move(500,500)#move the player sub to the bottom of
> the screen
> bullet = pygame.image.load("bullet.png").convert_alpha()#load the bullet
> image
> bulletrect = bullet.get_rect()#create bullet rect
> #bulletrect = bulletrect.move(0,780)#move it to the bottom
> speed = [2,0] #top speed of the enemysub
> pygame.key.set_repeat(2,2) #enable key repeat
> while 1:#main game loop
>   clock.tick(60)#60 fps max
>   enemyrect=enemyrect.move(speed) #bounce  |
>   if enemyrect.right > 640: speed = [-2, 0]#   |
>   if enemyrect.left <0: speed = [2, 0]#|
>   if bulletrect.top > 600:
>   bulletrect.left = enemyrect.left
>   bulletrect.top = enemyrect.top
>   else:
>   bulletrect=bulletrect.move(0,7)
>   for event in pygame.event.get(): #event query|
>   if event.type == QUIT:#  |
>   exit()#  |
>   if event.type == KEYDOWN:#   |
>   if event.key == K_RIGHT:#|
>   playerrect = playerrect.move(2,0)#   |
>   if event.key == K_LEFT:# |
>   playerrect = playerrect.move(-2,0)#  |
>   screen.fill((0,255,255)) #fill screen
>   screen.blit(enemy, enemyrect)#blit enemy
>   screen.blit(player, playerrect)#blit player
>   screen.blit(bullet,bulletrect)#blit bullet
>   pygame.display.update() #update screen
>
>
> how do i solve this problem?
>
> =
> Tecpel - Propel Quality Measurement
> Wide range of quality sources from Taiwan.
> http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=d1e2a9b5471fc3d9949f564a2f7d0acf
>
>
> --
> Powered by Outblaze
>

Re: [pygame] Shooting an object

[Charlie Nolan]

Make sure you store the position as a float internally and cast back
to int (if needed) for display.  Otherwise, you can get some annoying
issues when the speed is low compared to the framerate.

On 8/23/08, yanom @linuxmail.org <[EMAIL PROTECTED]> wrote:
>
>> - Original Message -
>> From: "Ian Mallett" <[EMAIL PROTECTED]>
>> To: pygame-users@seul.org
>> Subject: Re: [pygame] Shooting an object
>> Date: Sat, 23 Aug 2008 13:36:28 -0700
>>
>>
>> OK, for shooting, you want to have a class of Bullet.  When the enemy
>> fires,
>> add an instance of bullet.  The bullet's position will be the enemy's
>> position, and the speed will be a constant broken into x and y components
>> with cos(radians(angle)) and sin(radians(angle)).  Each frame, you add the
>> speed of the bullet to the bullet's position.
>
>>
> ok thanks
>
> =
> Tours from Las Vegas
> Bus & Air Tours to the Grand Canyon Monument Valley, Bryce & Zion.
> http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=5ec9e22c3648e0f36638288f64c6b564
>
>
> --
> Powered by Outblaze
>

Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux

[Charlie Nolan]

It was at 2.3.7.  I downgraded it to 2.3.5 temporarily, and it shows
the same results as 2.3.7.

-FM

On 8/22/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> That's right for SDL_ttf. What freetype version does Gentoo have. Pygame
> 1.8 uses freetype-2.3.5 on Windows.
>
> Lenard
>
>
> Charlie Nolan wrote:
>> SDL_ttf is at 2.0.9 on Linux, and after digging a bit, the SDL_ttf.dll
>> that came with pygame shows version 2.0.9.0.  Looks like a match to
>> me.
>>
>> On 8/22/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
>>
>>> It may be a difference between different versions of SDL_ttf or of
>>> freetype,
>>> which may not be a bug if the new er behavior is part of a bug fix.
>>>
>>> So what version of SDL_ttf do you have on Windows and on Linux?
>>>
>>>
>>> On Fri, Aug 22, 2008 at 12:04 PM, Charlie Nolan
>>> <[EMAIL PROTECTED]>wrote:
>>>
>>>
>>>> I suspect this will just get passed upstream to SDL, but someone will
>>>> need to translate for them.
>>>>
>>>> The "7" glyph in the attached font at size 21 behaves inconsistently
>>>> on Windows (XP SP2) and Linux (Gentoo).  Running the test script on
>>>> the two systems, I get these results:
>>>>
>>>> Linux:
>>>> (11, 16)
>>>> (12, 16)
>>>>
>>>> 
>>>> 
>>>>
>>>> [(0, 9, 0, 8, 11), (0, 9, 0, 8, 11)]
>>>> [(0, 9, 0, 8, 11), (-1, 9, 0, 8, 11)]
>>>>
>>>>
>>>> Windows:
>>>> (11, 16)
>>>> (12, 16)
>>>>
>>>> 
>>>> 
>>>>
>>>> [(0, 10, 0, 8, 11), (0, 10, 0, 8, 11)]
>>>> [(0, 10, 0, 8, 11), (0, 11, 0, 8, 12)]
>>>>
>>>>
>>>> My interpretation of this is that the 7 is behaving a bit screwy at
>>>> that size.  It renders as 12x16, but has an X offset of -1, for an
>>>> effective size of 11x16.  On Windows, the X offset appears to be lost,
>>>> thus causing the glyph to incorrectly have an extra pixel of padding
>>>> on the left.
>>>>
>>>> I'm also puzzled as to why maxx is one larger on Windows, but that
>>>> part doesn't seem to cause a problem.
>>>>
>>>>
>
>

Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux

[Charlie Nolan]

SDL_ttf is at 2.0.9 on Linux, and after digging a bit, the SDL_ttf.dll
that came with pygame shows version 2.0.9.0.  Looks like a match to
me.

On 8/22/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
> It may be a difference between different versions of SDL_ttf or of freetype,
> which may not be a bug if the new er behavior is part of a bug fix.
>
> So what version of SDL_ttf do you have on Windows and on Linux?
>
>
> On Fri, Aug 22, 2008 at 12:04 PM, Charlie Nolan
> <[EMAIL PROTECTED]>wrote:
>
>> I suspect this will just get passed upstream to SDL, but someone will
>> need to translate for them.
>>
>> The "7" glyph in the attached font at size 21 behaves inconsistently
>> on Windows (XP SP2) and Linux (Gentoo).  Running the test script on
>> the two systems, I get these results:
>>
>> Linux:
>> (11, 16)
>> (12, 16)
>>
>> 
>> 
>>
>> [(0, 9, 0, 8, 11), (0, 9, 0, 8, 11)]
>> [(0, 9, 0, 8, 11), (-1, 9, 0, 8, 11)]
>>
>>
>> Windows:
>> (11, 16)
>> (12, 16)
>>
>> 
>> 
>>
>> [(0, 10, 0, 8, 11), (0, 10, 0, 8, 11)]
>> [(0, 10, 0, 8, 11), (0, 11, 0, 8, 12)]
>>
>>
>> My interpretation of this is that the 7 is behaving a bit screwy at
>> that size.  It renders as 12x16, but has an X offset of -1, for an
>> effective size of 11x16.  On Windows, the X offset appears to be lost,
>> thus causing the glyph to incorrectly have an extra pixel of padding
>> on the left.
>>
>> I'm also puzzled as to why maxx is one larger on Windows, but that
>> part doesn't seem to cause a problem.
>>
>> -Charlie Nolan
>>
>

[pygame] BUG: Inconsistent font behavior between Windows and Linux

[Charlie Nolan]

I suspect this will just get passed upstream to SDL, but someone will
need to translate for them.

The "7" glyph in the attached font at size 21 behaves inconsistently
on Windows (XP SP2) and Linux (Gentoo).  Running the test script on
the two systems, I get these results:

Linux:
(11, 16)
(12, 16)




[(0, 9, 0, 8, 11), (0, 9, 0, 8, 11)]
[(0, 9, 0, 8, 11), (-1, 9, 0, 8, 11)]


Windows:
(11, 16)
(12, 16)




[(0, 10, 0, 8, 11), (0, 10, 0, 8, 11)]
[(0, 10, 0, 8, 11), (0, 11, 0, 8, 12)]


My interpretation of this is that the 7 is behaving a bit screwy at
that size.  It renders as 12x16, but has an X offset of -1, for an
effective size of 11x16.  On Windows, the X offset appears to be lost,
thus causing the glyph to incorrectly have an extra pixel of padding
on the left.

I'm also puzzled as to why maxx is one larger on Windows, but that
part doesn't seem to cause a problem.

-Charlie Nolan


font_test.py
Description: Binary data


acknowtt.ttf
Description: application/font-ttf

Re: [pygame] fmodf on msvc transform.c... any ideas brian?

[Charlie Nolan]

Correct me if I'm wrong, but doesn't unittest specifically give you a
way to perform setup and tear-down actions before/after each test?
Seems like that would be a good candidate for calling init and quit.

-FM

On 6/29/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> Marcus von Appen wrote:
>> On, Sun Jun 29, 2008, Lenard Lindstrom wrote:
>>
>>
>>> Lenard Lindstrom wrote:
>>>
>>
>> [...]
>>
>>> I take that back. Rearranging the test execution to that of the
>>> automated build site gives me an error. It is unrelated to PixelArray.
>>>
>>> ERROR: test_surfarray_ref (surflock_test.SurfaceLockTest)
>>> --
>>> Traceback (most recent call last):
>>>   File "test\surflock_test.py", line 141, in test_surfarray_ref
>>> ar = pygame.surfarray.pixels2d (sf)
>>>   File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line
>>> 122, in pix
>>> els2d
>>> return numericsf.pixels2d (surface)
>>> ValueError: unsupport bit depth for 2D reference array
>>>
>>> --
>>> Ran 469 tests in 24.000s
>>>
>>> FAILED (errors=1)
>>>
>>>
>>> My experience is such errors are related to the display's settings. One
>>> or more unit tests which call pygame.display.set_mode fail to do proper
>>> cleanup by later calling pygame.quit .
>>>
>>
>> Probably you've got a 24bpp setting active, which caused the surflock
>> test to fail as I forgot to explicitly set the surface depth to 32
>> bit. Fixed in rev.
>>
>>
> Okay, it works. But one should be able to rely on the default
> pre-pygame.init() setting, 32 bpp, for each unit test. A unit test that
> confirms this default could fail. Too much interference between test
> modules.
>
> --
> Lenard Lindstrom
> <[EMAIL PROTECTED]>
>
>

Re: [pygame] fmodf on msvc transform.c... any ideas brian?

[Charlie Nolan]

Brian Fisher wrote:
> The automated build thing should be using a fresh directory each time. I
> think the solution to the crash is just for me to look into it and figure it
> out.

What an amazingly logical idea.  It'll never work.  ;)
-FM



signature.asc
Description: OpenPGP digital signature

Re: [pygame] BUG: pygame.time tick()?

[Charlie Nolan]

Actually, *YES*, I checked, it is true that "the relevant source is in
SDL".  As I thought, SDL_Delay is not a simple sleep(ms) call, it's
got its own loop, functionally identical to the one I gave, excepting
only that the relevant calls are low-level.  Don't believe me?  Grab a
copy of the SDL source, go into src/timer/unix/SDL_systimer.c and
scroll down to line 112, which is where the loop starts.

I will grant, there are plenty of other code paths based on the
intricacies of what's available on your system.  I don't have the time
or the patience to go check all of them out, but I'd wager that they
use the same basic structure.

-FM

On Fri, Jun 27, 2008 at 3:16 PM, Brian Fisher <[EMAIL PROTECTED]> wrote:
> It's not true that the relevant source is in SDL - clock.tick does call
> SDL_Delay, but all SDL_Delay takes a number of ticks to sleep, and then just
> sleeps that long. It's pygame source that is deciding how long to
> sleep/wait.
>
> ... also no need to guess at the source, you can get at it from the web,
> even:
> http://www.seul.org/viewcvs/viewcvs.cgi/trunk/src/time.c?rev=1240&root=PyGame&view=auto
>
> Basically, I think this could be fixed in pygame source without an SDL
> change, just by putting a max on how long to wait in clock tick - and that
> delay could be maxed out at the framerate (surely you never would wait
> longer than 100ms to regulate a 10fps timer, right?)
>
> here's the relevant source (accurate_delay is passed in as 0, and the
> framerate arg is what was passed to tick):
> 
>
> // to be called by the other tick functions.
> static PyObject*
>
> clock_tick_base(PyObject* self, PyObject* arg, int use_accurate_delay)
> {
> PyClockObject* _clock = (PyClockObject*) self;
> float framerate = 0.0f;
> int nowtime;
>
> if (!PyArg_ParseTuple (arg, "|f", &framerate))
>
> return NULL;
>
> if (framerate)
> {
> int delay, endtime = (int) ((1.0f / framerate) * 1000.0f);
> _clock->rawpassed = SDL_GetTicks () - _clock->last_tick;
> delay = endtime - _clock->rawpassed;
>
>
> /*just doublecheck that timer is initialized*/
> if (!SDL_WasInit (SDL_INIT_TIMER))
> {
> if (SDL_InitSubSystem (SDL_INIT_TIMER))
> {
> RAISE (PyExc_SDLError, SDL_GetError ());
>
> return NULL;
> }
> }
>
> if (use_accurate_delay)
> delay = accurate_delay (delay);
> else
> {
> // this uses sdls delay, which can be inaccurate.
>
> if (delay < 0)
> delay = 0;
>
> Py_BEGIN_ALLOW_THREADS;
> SDL_Delay ((Uint32) delay);
> Py_END_ALLOW_THREADS;
> }
>
> if (delay == -1)
>
> return NULL;
> }
>
> nowtime = SDL_GetTicks ();
> _clock->timepassed = nowtime - _clock->last_tick;
> _clock->fps_count += 1;
> _clock->last_tick = nowtime;
> if (!framerate)
>
> _clock->rawpassed = _clock->timepassed;
>
> if (!_clock->fps_tick)
> {
> _clock->fps_count = 0;
> _clock->fps_tick = nowtime;
> }
> else if (_clock->fps_count >= 10)
>
> {
> _clock->fps = _clock->fps_count /
> ((nowtime - _clock->fps_tick) / 1000.0f);
> _clock->fps_count = 0;
> _clock->fps_tick = nowtime;
> Py_XDECREF (_clock->rendered);
>
> }
> return PyInt_FromLong (_clock->timepassed);
> }
>
>
>

Re: [pygame] BUG: pygame.time tick()?

[Charlie Nolan]

clock.tick goes through SDL_Delay, so the relevant source isn't in
pygame, but I'm guessing things look roughly like this:

def delay(ms):
until = time.time() + ms
sleep_time = ms
while sleep_time > 0:
time.sleep(sleep_time)
sleep_time = until - time.time()

So what's happening is this:
1. delay is called and goes to sleep for 1/30th of a second.
2. clock is set back X hours.
3. delay wakes up, goes back to sleep for X hours.
4. clock is set forward X hours.
5. delay will still be sleeping for X hours, because it doesn't see
the new time.

Since the loop above is more or less the Right Way to do things, the
answer to your issue is contained in an old joke:
"Doc, you gotta help me."
"What's the matter?"
"My elbow hurts terribly when I do this."  *demonstrates*
"Well, don't do that!"

-FM


On 6/27/08, John Leach <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Could anyone comment on this problem with the otherwise fantastic
> pygame.
>
> pygame 1.8.0
> OS Fedora 8 Linux 32-bit
> python 2.5.1
>
> Code essentials:-
>
> clock = pygame.time.Clock()
> while 1:
>   clock.tick(30)
>   # various sprite and text blits
>   pygame.display.flip()
>
> This code runs really well and looks great on my test systems (thanks
> René), however when I transferred to a couple of new computers the
> program has been hanging. All the moving sprites, moving text etc freeze
> on the screen after a period of time.
>
> I could ssh into the box and everything looked ok. The problem looked to
> be that my pygame was hanging somewhere.
>
> I noticed the hangs were occurring exactly on the hour and tracked the
> problem to the fact that every hour these machines call ntpdate to set
> the system clock.
>
> I ssh'ed into a running computer and was able to reproduce the problem
> by running ntpdate manually. The program froze at exactly the time that
> I ran ntpdate.
>
> For these machines, the BIOS clock was set to approx 2 hours behind the
> current local time and the local time zone is 10 hours in advance of
> UTC. Linux is configured for UTC.
>
> So my analysis of the problem is as follows:-
>
> ntpdate was changing the time by approximately 8 hours - quite a large
> change. And I suspect that the
> clock.tick(30)
> statement is hanging at that point.
> As I understand the function of clock.tick() it is to slow down the
> processing to match the frame rate specified. So clock.tick() will have
> a delay loop in it while it waits for the next frame interval to come
> around. So it seems likely that the program would have frozen for 8
> hours then come back to life.
> (however I semi-tested this by changing the time back into the future
> via ntpdate and the program did not come back into action again).
>
> The time module is in C which is not a language I know so I have not
> been able to diagnose the problem further.
>
> Workarounds: for anyone reading this at a later date and having this
> problem, the possible workarounds I can think of are:-
> 1) setting the UTC date and time correctly in the bios first up
> 2) setting the date and time using ntpdate on first installation then
> rebooting (to set the hardware clock)
> 3) setting the date and time using ntpdate on first installation and
> then using hwclock to write this time back to the BIOS
> 4) Having done one of the above 3, using ntpd instead of ntpdate to
> ensure the time stays correct without major sudden changes.
>
> The problem does not appear to happen now that I have corrected the
> times (or has not happened since I corrected the times on those
> computers).
>
> It is also worth pointing out that the problem did not occur every time
> ntpdate was run with a large time change; I put that down to the fact
> that if ntpdate was run when the program was not in clock.tick() then it
> was ok, but if it occurred when inside clock.tick() then the problem
> could occur. Possibly the reverse could be true.
>
> Does this sound likely?
>
> Regards
> John Leach
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: [pygame] Proposed additions to Transform: connected components, upper and lower thresholding, and centroids

[Charlie Nolan]

Nirav Patel wrote:
> The plan is to be able to do while having to traverse the image array
> as few times as possible.  I want to be able to run it at 30 fps on an
> OLPC XO while still leaving time to do other stuff each frame.

You might want to just write it up in C, then, if you need that kind of
performance.  I'll warn you, though, that it's awfully easy to implement
this kind of thing badly, and end up worse off than if you'd just used
prebuilt pieces to start with.

The job of a library (like pygame) is to provide common functions that
can be assembled into larger things.  If you want something that does
exactly what you need as efficiently as possible, you've got to do it
yourself.  Otherwise, the library ends up bloated with dozens of
single-use functions (or function features) that are a royal mess to
maintain.

-FM



signature.asc
Description: OpenPGP digital signature

Re: [pygame] Re: scale

[Charlie Nolan]

No, you want to avoid a colorkey when scaling.  Without seeing the
artifacts, it's hard to say, but I suspect that your problem is that
you're currently using a colorkey, but need to switch to alpha for scaling.

-FM

Chris wrote:
> Can't believe I missed that with how much I have been reading the pygame
> documentation.
> 
> Thank you.
> 
> When I tried it, smoothscale created several single pixel artifacts
> around the edges of my image.  Is that a result of transparency scaling?
> 
> Should I give it a solid background, transform then colorkey the
> background to transparent afterwards?
> 
> I'll try that tomorrow.
> 
> René Dudfield wrote:
>> hi,
>>
>> have you tried transform.smoothscale?
>>
>> cheers,
>>
>> On Tue, Jun 17, 2008 at 12:19 PM, Chris <[EMAIL PROTECTED]>
>> wrote:
>>> The gimp uses an image resize function that is perfect.  I use it in PHP
>>> with my online shop images. Going from larger to smaller, of course. 
>>> I had
>>> hoped that transform would operate the same way but the image
>>> degradation
>>> is... noticeable to severe.
>>>
>>> Excuse me if I missed the discussion target.
>>>
>>> René Dudfield wrote:
 Hello,

 a few notes below.


 On Tue, Jun 17, 2008 at 10:49 AM, Nirav Patel <[EMAIL PROTECTED]>
 wrote:
> As part of my project to add computer vision stuff to pygame, I'd like
> to write a function or functions that do the following.
>
> For vision purposes, it would be very useful to have thresholding with
> both upper and lower boundaries, returning both the number of pixels
> within the threshold and the centroid of those pixels.  This is a
> trivial addition to the existing transform.threshold() function, but
> is it acceptable to modify the input options and the output of an
> existing function?  Would it break compatibility with existing pygame
> games?  Would it make sense to have a second function so similar to an
> existing one?
>
 You could modify the existing function if the old functionality stays
 the same.  Probably by adding another default argument.  We try not to
 break existing functionality.

 I think the current one can use just one distance from the color.  So
 it's both a lower, and upper threshold.  I'm just wondering if it
 could be used already to do what you want?

> The other function, which is also similar (and could even just be an
> option in thresholding), is thresholding with connected component
> detection.  This would involve supplying an upper and lower threshold,
> a Surface, and optionally a mask.  The function would find the largest
> blob of pixels in the Surface within the threshold, make a mask of
> those pixels if desired, and return the centroid and number of pixels
> in the blob.
>
 Currently this can sort of be done by making a mask from the
 thresholded image.  Mask has a get_bounding_rect() function.  Doing
 the get_bounding_rect on a mask turns out to be fast because you
 process way less data -- as mask is 1 bit per pixel.  Then you can
 sort the bounding rects on size to find the largest one.

 I'm not sure if that will be suitable for your task though, but I
 think maybe you could do things this way.


> It could also be useful to have multiple connected component
> detection, for "multi-touch" without having to use different colored
> objects (or if you are using IR LEDs like the Wii does), but I'm not
> sure how to handle that in a single pass of the array.  Actually, I'm
> not really sure how I'm going to handle both detection and creating a
> mask in a single pass either.  It may be necessary to store the
> starting pixel, ending pixel, and size of each connected component on
> the first pass, keeping track of which was the largest yet, and then
> have a shorter second pass to create the mask that only starts at the
> starting pixel and ends at the ending pixel.
>
 Multiple areas can be found like above with Mask.get_bounding_rect().

 Doing everything in one pass is hard... but if you reduce the data
 down -- by using a mask -- then the second pass can act on 32x less
 data.

 eg, a 1024x1024 image:
>>> (1024 * 1024 * 4) / 32.
 131072.0

 So that is 4MB on the first pass down to 131KB of data to process on
 the second pass.



> Any comments, reality checks, questions, or suggestions would be
> greatly appreciated.
>
> Nirav
>
>>>
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [pygame] Storing images in a list

[Charlie Nolan]

Unless you explicitly copy the image or build it multiple times, there's
no copying "behind the scenes".  They'll all point to the same image.

-FM

Chris wrote:
> Jake,
> 
> The image loads here...
> 
> def game_image (image_file):
> image = pygame.image.load (image_file).convert_alpha ()
> return image
> 
> The image is assigned like...
> 
> red_stone = game_image ("red_stone.png")
> 
> Later, it goes into the list like...
> 
> board_layout.append ([red_stone, (x, y)...])
> 
> So is a copy of red_stone in the list or just a pointer?
> 
> 
> Jake b wrote:
>>> When an element of the list says , is that pointing
>>> to a
>>> spot in the memory or is the actual image being stored in that index?
>> That's a surface. You can have multiple variables point to the same
>> surface.
>>
>>> Would I have 64 images in my list if every space is occupied or would
>>> I have just
>>> 2 images in memory?
>> I can't be sure without seeing your init/draw code, but it sounds like
>> you probably have 64.
>>
>> Are you doing something like this?
>>
>> def init():
>> """game init"""
>> red = pygame.Surface( [10, 10] )
>> red.fill( pygame.color.Color( "red" ) )
>> blue = pygame.Surface( [10, 10] )
>> blue.fill( pygame.color.Color( "blue" ) )
>> # init tiles with color red
>> for tile in tile_list:
>> # sharing one surface for tiles
>> tile.image = red
>>
>> def draw():
>> """game draw"""
>> for tile in tile_list:
>> # draw using tile.image
> 



signature.asc
Description: OpenPGP digital signature

Re: [pygame] Proposed additions to Transform: connected components, upper and lower thresholding, and centroids

[Charlie Nolan]

Nirav Patel wrote:
> For vision purposes, it would be very useful to have thresholding with
> both upper and lower boundaries, returning both the number of pixels
> within the threshold and the centroid of those pixels.  This is a
> trivial addition to the existing transform.threshold() function, but
> is it acceptable to modify the input options and the output of an
> existing function?  Would it break compatibility with existing pygame
> games?  Would it make sense to have a second function so similar to an
> existing one?

transform.threshold... does not work the way you think it does.  It's
not a simple computer imaging "below or above value X" threshold, it's
"are we within X or color Y".  You can approximate a two-level threshold
with something like this:

def simple_threshold(surface, min=0, max=255):
dest_surface = pygame.Surface(surface.get_size(), 0, surface)
avg = (min + max) // 2
dist = avg - min
color = (avg, avg, avg)
threshold = (dist, dist, dist)

pygame.transform.threshold(dest_surface, surface, color, threshold)
return dest_surface

Really, the best thing to do might be to create a
transform.grayscale_threshold function.  As you can see, the current
threshold function doesn't exactly do what you need, even though the
name matches.

As to the centroid, that might be best as its own function.

> The other function, which is also similar (and could even just be an
> option in thresholding), is thresholding with connected component
> detection.  This would involve supplying an upper and lower threshold,
> a Surface, and optionally a mask.  The function would find the largest
> blob of pixels in the Surface within the threshold, make a mask of
> those pixels if desired, and return the centroid and number of pixels
> in the blob.

Again, separate out your pieces.  What you're describing is
bw_threshold, followed by connected_components and get_centroids.

> It could also be useful to have multiple connected component
> detection, for "multi-touch" without having to use different colored
> objects (or if you are using IR LEDs like the Wii does), but I'm not
> sure how to handle that in a single pass of the array.  Actually, I'm
> not really sure how I'm going to handle both detection and creating a
> mask in a single pass either.  It may be necessary to store the
> starting pixel, ending pixel, and size of each connected component on
> the first pass, keeping track of which was the largest yet, and then
> have a shorter second pass to create the mask that only starts at the
> starting pixel and ends at the ending pixel.

Go look up the standard connected components algorithm.  It's two-pass,
by necessity.  If you try to do it in a single pass, you end up with an
O(n^2) algorithm instead of O(n).

What connected components does is take a BW image and turn it into a
grayscale image, with each color of pixel representing a different
connected component.  So starting color is irrelevant, since you have to
process it down to BW to start with.

-FM



signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

Works fine for me on almost-pristine 1.8.  (I've got a patch in locally
to fix the "buffer is always 256" bug that tends to cause crackly sound.)

-FM

Astan Chee wrote:
> Ok. I just tried upgrading to pygame 1.8 and true enough, nothing
> appears. Im not sure why. Maybe doing the env var settings (
> http://wiki.wxpython.org/IntegratingPyGame ) breaks something new that
> is introduced in 1.8? I reverted it back to 1.7.1 and it worked again
> fine. Although using 1.8 didnt break my other games that were pure
> pygame, only the ones that did things mentioned in that website. Anyone
> have any idea why?
> Cheers
> Astan
> 
> Astan Chee wrote:
>> This is very unusual. Can you get a screenshot of this fuzzy circle
>> and two small dots? Maybe its the size of the pygame window not sizing
>> properly. Also, once you click on the "navigate/open navigation"
>> button, the pygame window behaves like a wxDialog, in that it becomes
>> a child window of the main UI and unless the child window is closed,
>> interaction with the parent is disabled. Anyway, I'll try and upgrade
>> mine to pygame 1.8 and see if it still happens.
>> Thanks again
>> Cheers
>>
>> etrek wrote:
>>> I have tried both ways to open navigation console.  I create some
>>> objects and then click on "Navigation Information" tab.  Then click
>>> on "Resume" button to start time.  Then click on "Navigate/Open
>>> Navigation Console" button.  A separate Pygame window does not
>>> appear.  All I see is a fuzzy circle and two small dots (My guess is
>>> they represent, Sun,Earth,Moon) on the same screen as the Navigation
>>> Information UI screen.  Also, once I have clicked on the
>>> "Navigate/Open Navi..." button, the UI becomes unresponsive, i.e.
>>> "Pause" button, tabs (Object Editor, etc.) stop working, and can't
>>> resize or move the UI.  I have to close the Python.exe console
>>> window, or shut the program down in Task Manager in order to shut it
>>> down.
>>>
>>> I have Windows Vista32, Pygame 1.8.0, latest wxPython, Python 2.5 and
>>> PyOpengl
>>> -etrek
>>>
>>>
>>> - Original Message - From: "Astan Chee" <[EMAIL PROTECTED]>
>>> To: 
>>> Sent: Friday, June 13, 2008 6:41 PM
>>> Subject: Re: [pygame] my 3d planet game
>>>
>>>
>>>> I havent tested this in pygame 1.8.0. There are 2 ways of opening
>>>> the navigation console, via the menu and from the button. Both open
>>>> a new window (pygame window) with the 3D shape. While the console is
>>>> open, you cant interact with the main window. The new pygame window
>>>> has to be closed before normal interaction can be resumed (kinda
>>>> mimicing the dialog modal behaviour). The navigation console should
>>>> have 2 minimaps on the bottom right and left corner. Are this not
>>>> appearing for you?
>>>> Cheers
>>>>
>>>>
>>>> etrek wrote:
>>>>> Does this work with Pygame 1.8.0?
>>>>> Is the Navagation Console supposed to be on the same screen as the
>>>>> Navagation menu?  Or is it supposed to open a new window (Pygame
>>>>> window) with the 3D shapes?  All I see is a fuzzy dark circle on
>>>>> the Navagation menu page.  The navagation keys, or clicking with
>>>>> mouse just causes the circle to flicker.
>>>>>
>>>>> Thanks,
>>>>> etrek
>>>>>
>>>>>
>>>>> - Original Message - From: "Astan Chee" <[EMAIL PROTECTED]>
>>>>> To: 
>>>>> Sent: Friday, June 13, 2008 2:21 AM
>>>>> Subject: Re: [pygame] my 3d planet game
>>>>>
>>>>>
>>>>>> Charlie Nolan wrote:
>>>>>>> Looks good.  A few notes:
>>>>>>> * Mouse scroll down is equivalent to s (move back), not f (move up).
>>>>>>>
>>>>>> Thanks. Im not so good at manuals or documenting code.
>>>>>>> * When dragging with RMB, the mechanics feel off.  The mouse cursor
>>>>>>> should stay on top of roughly the same bit of space as I drag it,
>>>>>>> not
>>>>>>> have the space go zooming out past it.
>>>>>>>
>>>>>> I dont know how to do this in pygame. Is there an example
>>>>>> somewhere of how 

Re: [pygame] my 3d planet game

[Charlie Nolan]

Look up the syntax for gluPerspective.  Two of the parameters are called
"fovy" and "aspect".  The point is that *those* parameters are the ones
that drive the display, so when you apply them to the mouse rotation,
it'll feel more natural.

-FM

Astan Chee wrote:
> Hi,
> Thanks for the explanation but again, I dont understand the terms you
> are using. I only call gluPerspective once; how or what are aspect
> parameters?
> It seems that the last part you are describing is similar with what I am
> already doing. What or how is mine different?
> Thanks again.
> 
> Charlie Nolan wrote:
>> He's missing a major detail, namely that you're going to need to
>> translate to/from spherical co-ordinates if you want to do it right.
>> You could just toy around with the look speed until you found something
>> close to right, but you might as well just get it right to start with.
>>
>> Whenever you call gluPerspective, store the fovy and aspect parameters.
>>   Multiply fovy by aspect to get fovx.  Divide each of these by the
>> respective screen dimension to get unitx and unity, the arc size (in
>> degrees) represented by each pixel in the x and y directions,
>> respectively.
>>
>> From there, you just use whatever code you already have for handling
>> drags and multiply the mouse motion by unitx and unity to get the amount
>> you need to turn the view by.
>>
>> I may have missed a few details, but that's the basic method.
>>
>> -FM
>>
>> Astan Chee wrote:
>>  
>>> James Paige wrote:
>>>
>>>> On Fri, Jun 13, 2008 at 07:21:30PM +1000, Astan Chee wrote:
>>>>  
>>>>  
>>>>>> * When dragging with RMB, the mechanics feel off.  The mouse cursor
>>>>>> should stay on top of roughly the same bit of space as I drag it, not
>>>>>> have the space go zooming out past it.
>>>>>>  
>>>>>> 
>>>>> I dont know how to do this in pygame. Is there an example somewhere
>>>>> of how to do this?
>>>>> 
>>>> WHen you recieve the right mouse button's mouse down event, store the
>>>> X/Y position of the mouse. Then, until you recieve the mouse up event,
>>>> position the camera according to the difference between the current
>>>> position of the mouse and the position when the right button was first
>>>> pressed.
>>>> 
>>> Somehow I still dont understand this.Can you paraphrase this in
>>> pseudocode or some snippet?
>>> Thanks
>>>
>>>> ---
>>>> James Paige
>>>>
>>>> 
>>
>>
>>
>>   
> 



signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

He's missing a major detail, namely that you're going to need to
translate to/from spherical co-ordinates if you want to do it right.
You could just toy around with the look speed until you found something
close to right, but you might as well just get it right to start with.

Whenever you call gluPerspective, store the fovy and aspect parameters.
  Multiply fovy by aspect to get fovx.  Divide each of these by the
respective screen dimension to get unitx and unity, the arc size (in
degrees) represented by each pixel in the x and y directions, respectively.

From there, you just use whatever code you already have for handling
drags and multiply the mouse motion by unitx and unity to get the amount
you need to turn the view by.

I may have missed a few details, but that's the basic method.

-FM

Astan Chee wrote:
> James Paige wrote:
>> On Fri, Jun 13, 2008 at 07:21:30PM +1000, Astan Chee wrote:
>>  
 * When dragging with RMB, the mechanics feel off.  The mouse cursor
 should stay on top of roughly the same bit of space as I drag it, not
 have the space go zooming out past it.
  
   
>>> I dont know how to do this in pygame. Is there an example somewhere
>>> of how to do this?
>>> 
>>
>> WHen you recieve the right mouse button's mouse down event, store the
>> X/Y position of the mouse. Then, until you recieve the mouse up event,
>> position the camera according to the difference between the current
>> position of the mouse and the position when the right button was first
>> pressed.
>>   
> Somehow I still dont understand this.Can you paraphrase this in
> pseudocode or some snippet?
> Thanks
>> ---
>> James Paige
>>
>>   
> 





signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

Charlie Nolan wrote:
>> Thanks! So the keyboard shortcuts work in linux as well?
> 
> Looks good.  A few notes:
> * Mouse scroll down is equivalent to s (move back), not f (move up).
> * When dragging with RMB, the mechanics feel off.  The mouse cursor
> should stay on top of roughly the same bit of space as I drag it, not
> have the space go zooming out past it.
> * When time is paused, keys aren't repeating, so you can only turn by
> mouse or by pounding the key like mad.
> 
> -FM

Oh, and could we get a plain-text version of the manual, too?  Even a
bare-bones PDF reader feels bulky compared to a text editor.  And it
looks like all you're using PDF for is to embed screenshots, which
aren't critical.
-FM



signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

> Thanks! So the keyboard shortcuts work in linux as well?

Looks good.  A few notes:
* Mouse scroll down is equivalent to s (move back), not f (move up).
* When dragging with RMB, the mechanics feel off.  The mouse cursor
should stay on top of roughly the same bit of space as I drag it, not
have the space go zooming out past it.
* When time is paused, keys aren't repeating, so you can only turn by
mouse or by pounding the key like mad.

-FM



signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

Found it.  I just had to not set the other environment variable
(SDL_WINDOWID) either, and it worked fine.
-FM

Astan Chee wrote:
> No, and the wx window should be on a seperate thread as the
> pygame/opengl one. The wx window calls the pygame one though. But yeah,
> they are two separate windows.
> Thanks for trying though.
> Cheers
> Astan
> 
> Charlie Nolan wrote:
>> What is it that you're trying to do?  Reuse the same window for both
>> pygame/OpenGL and wx?  If so, it might work better to separate them into
>> two windows.
>>
>> I haven't really done anything with OpenGL though, so take that with a
>> grain of salt.
>>
>> -FM
>>
>> Astan Chee wrote:
>>  
>>> Thanks for the feedback. I really appreciate it.
>>>
>>> Charlie Nolan wrote:
>>>
>>>> (python:31706): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a
>>>> pixmap or window
>>>> The program 'python' received an X Window System error.
>>>> This probably reflects a bug in the program.
>>>> The error was 'BadWindow (invalid Window parameter)'.
>>>>   (Details: serial 54 error_code 3 request_code 18 minor_code 0)
>>>>   (Note to programmers: normally, X errors are reported asynchronously;
>>>>that is, you will receive the error a while after causing it.
>>>>To debug your program, run it with the --sync command line
>>>>option to change this behavior. You can then get a meaningful
>>>>backtrace from your debugger if you break on the gdk_x_error()
>>>> function.)
>>>>   
>>> I have no clue what is causing this. I know wx and pygame isnt supposed
>>> to be used together, but it works on windows yet Im wondering what I
>>> have to do to get it to play nice in linux. Maybe someone from the
>>> mailing list can help?
>>>
>>>> Traceback (most recent call last):
>>>>   File "wxSol.py", line 1768, in OnCountDown
>>>> self.RefreshSingle()
>>>>   File "wxSol.py", line 2172, in RefreshSingle
>>>> self.CalcElemPerc()
>>>>   File "wxSol.py", line 2231, in CalcElemPerc
>>>> info = self.elements[int(num)]
>>>> KeyError: -1
>>>> 
>>> I think I've fixed this bug. Something about an invalid key and uploaded
>>> a new version.
>>> Thanks again.
>>> Cheers
>>> Astan
>>>
>>> 
>>
>>   
> 



signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

What is it that you're trying to do?  Reuse the same window for both
pygame/OpenGL and wx?  If so, it might work better to separate them into
two windows.

I haven't really done anything with OpenGL though, so take that with a
grain of salt.

-FM

Astan Chee wrote:
> Thanks for the feedback. I really appreciate it.
> 
> Charlie Nolan wrote:
>> (python:31706): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a
>> pixmap or window
>> The program 'python' received an X Window System error.
>> This probably reflects a bug in the program.
>> The error was 'BadWindow (invalid Window parameter)'.
>>   (Details: serial 54 error_code 3 request_code 18 minor_code 0)
>>   (Note to programmers: normally, X errors are reported asynchronously;
>>that is, you will receive the error a while after causing it.
>>To debug your program, run it with the --sync command line
>>option to change this behavior. You can then get a meaningful
>>backtrace from your debugger if you break on the gdk_x_error()
>> function.)
> I have no clue what is causing this. I know wx and pygame isnt supposed
> to be used together, but it works on windows yet Im wondering what I
> have to do to get it to play nice in linux. Maybe someone from the
> mailing list can help?
>> Traceback (most recent call last):
>>   File "wxSol.py", line 1768, in OnCountDown
>> self.RefreshSingle()
>>   File "wxSol.py", line 2172, in RefreshSingle
>> self.CalcElemPerc()
>>   File "wxSol.py", line 2231, in CalcElemPerc
>> info = self.elements[int(num)]
>> KeyError: -1
>>   
> I think I've fixed this bug. Something about an invalid key and uploaded
> a new version.
> Thanks again.
> Cheers
> Astan
> 



signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

Google Code actually isn't supposed to allow deleting files.  I guess
you had little enough exposure that you got the "whoops, wrong file"
exception.

-FM

P.S.  Feh, my turn to drop off the list.  Direct TO/CC's screw up the
reply button.  :/

Astan Chee wrote:
> Whops, sorry. Dropped you off the list there.
> Versions? sure, but Im sure I deleted the old one before uploading the
> new one just now. Does the new one come up with the old interface?
> h, I'll have a look and change it accordingly next time
> Cheers
> 
> Charlie Nolan wrote:
>> It doesn't look like you actually got a new version uploaded.  Remember,
>> with Google Code, you have to use a new filename each time, so include a
>> version number of some kind.
>>
>> Also, I think you meant to put this on the list, not directly to me.
>>
>> Back up, try again.  :)
>>
>> -FM
>>
>> Astan Chee wrote:
>>  
>>> Charlie Nolan wrote:
>>>
>>>> The main interface is going to be too tall for 1280x800.  If you move
>>>> the second section of the Object Editor to the right of the first
>>>> (instead of below), you should be able to drop the height
>>>> significantly.
>>>> 
>>> Hi,
>>> I've changed the layout abit to be less tall but with the same width.
>>> Its uploaded on the project page ( http://code.google.com/p/planetgame/
>>> ) plus I've had to fix some bugs.
>>> Thanks again for your feedback.
>>> Cheers
>>>
>>> 
>>
>>   
> 





signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

Astan Chee wrote:

> Im guessing you are using linux,right? Commenting out
> os.environ['SDL_VIDEODRIVER'] = 'windib'
> should work if you are on linux.

Right.  Tried that, got a new error:

(python:31706): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a
pixmap or window
The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 54 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

>> I also got some KeyErrors (with key 0, then many instances of key -1)
>> the first time I ran it, 
> Do you have a screenshot of this?

No, but I just got it to reproduce.  Wasn't from the display at all, it
was from unpausing time.  Apparently I didn't unpause it long enough
earlier for it to actually tick.

Traceback (most recent call last):
  File "wxSol.py", line 1768, in OnCountDown
self.RefreshSingle()
  File "wxSol.py", line 2172, in RefreshSingle
self.CalcElemPerc()
  File "wxSol.py", line 2231, in CalcElemPerc
info = self.elements[int(num)]
KeyError: 0
Traceback (most recent call last):
  File "wxSol.py", line 1768, in OnCountDown
self.RefreshSingle()
  File "wxSol.py", line 2172, in RefreshSingle
self.CalcElemPerc()
  File "wxSol.py", line 2231, in CalcElemPerc
info = self.elements[int(num)]
KeyError: -1

The -1 then repeats until I pause it again.

-FM



signature.asc
Description: OpenPGP digital signature

Re: [pygame] my 3d planet game

[Charlie Nolan]

You can apparently support python 2.4 by changing the one place where
you have "class foo():" to read "class foo:".

The main interface is going to be too tall for 1280x800.  If you move
the second section of the Object Editor to the right of the first
(instead of below), you should be able to drop the height significantly.

If I try to Navigate, I get this error:

(python:30836): Gdk-WARNING **: gdkdrawable-x11.c:878 drawable is not a
pixmap or window
No available video device
error("No available video device") in Inited() (wxSol.py:line 346) <-
Run() (wxSol.py:line 990)

I also got some KeyErrors (with key 0, then many instances of key -1)
the first time I ran it, but I'm not getting those to duplicate now, so
I can't be more specific.

-FM



signature.asc
Description: OpenPGP digital signature

Re: [pygame] [PLEASE TEST]: New locking code

[Charlie Nolan]

No, you should not be able to release a lock that you don't have.  The
threading module sets precedent, if nothing else:

>>> import threading
>>> threading.Lock().release()
Traceback (most recent call last):
  File "", line 1, in ?
thread.error: release unlocked lock

RLock is even stricter, it requires that you be in the same thread
that acquired the lock, which is analogous to our situation.

-FM

On 6/11/08, Marcus von Appen <[EMAIL PROTECTED]> wrote:
> On, Wed Jun 11, 2008, Charlie Nolan wrote:
>
>> Errors should never pass silently.
>> Unless explicitly silenced.
>
> It is - at least for me - no error, if I try to unlock a surface that a)
> has no locks or b) is locked by something else. Instead I'd vote for a
> return value, which indicates whether the unlock() call was successful
> or not.
>
>   if surface.unlock ():
>   print "Unlock successful"
>   ...
>
> This let's us preserve backwards compatibility while letting the user
> check for success through the return value without the need to write
> extensive try: except: statements.
>
> Regards
> Marcus
>

Re: [pygame] [PLEASE TEST]: New locking code

[Charlie Nolan]

On a major release, yes, but not on a bugfix release.
-FM

On 6/10/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
> I would disagree that it's more important that all the code that ran before
> runs on the new version without exception than it is to change the new
> version so that bad nonfunctioning or error-prone code doesn't silently
> fail.
>
> The way I think of it is,  What happens when the code that didn't run before
> fails to run with the new error checking? If what happens is the developer
> learns that the code is bad and it breaks and messes up locking, and it gets
> rewritten in a way that makes sense, than I say it's a good thing, and if
> that developer were me I would appreciate it very much that the behavior
> changed.
>
> I do admire and appreciate the devotion to backwards compatibility, I just
> think there are cases that are worth changing the behavior, and so far this
> seems like a good one to me.
>
>
> On Tue, Jun 10, 2008 at 6:07 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>
>> sure.  We want to try to not breaking existing code if possible.
>>
>> Note, that currently Marcus's code seems to work with the existing
>> surfarray using code that I've tried.  I've tried the
>> example/arraydemo.py and one app so far.
>>
>> Here's a list of surfarray using code if someone wants to test more:
>> http://www.google.com/codesearch?q=import+surfarray
>>
>> cheers,
>>
>>
>>
>> On Wed, Jun 11, 2008 at 10:26 AM, Brian Fisher
>> <[EMAIL PROTECTED]> wrote:
>> > Even bad broken code?
>> >
>> > On Tue, Jun 10, 2008 at 4:09 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Also note that we *need* to retain compatibility with existing code -
>> >> at least for pygame 1.8.1.  We shouldn't break existing code.
>> >>
>>
>

Re: [pygame] PATCH: Readability fix for "make chunk a power of 2" (src/mixer.c)

[Charlie Nolan]

It's a cut-and-dry issue, folks.  The buffer size was being set to
256, regardless of what was passed in.  If you happen to have a
os/software/machine combination that can keep up with such a small
buffer, you'll be fine, otherwise, it'll be crackly.

This isn't some random bug that we're trying to track down.  We know
what the issue was.  As far as the functionality is concerned, my
change is a no-op, it's strictly for readability's sake.  Just test
that they perform the same, and that's sufficient.

-FM

On 6/10/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
> For what it's worth, I tested on both Windows XP and Vista and never
> experienced any of the problems with the short mixer buffer crackliness that
> is unique to pygame 1.8.0 - it's not just on OS thing, it's apparently
> hardware dependent.
>
> On Tue, Jun 10, 2008 at 12:51 PM, etrek <[EMAIL PROTECTED]> wrote:
>
>> Just a note about changing the mixer code again:
>> Remember that Lenard's 1222 revision fixed the crackling (crappy sound) on
>> WindowsXP/Vista systems.
>> Please make sure any new changes made to code involving mixer are tested
>> on
>> WindowsXP and/or Vista,
>> and not just on Linux systems. Before making them a part of any production
>> versions of Pygame.
>>
>> I appreciate the work you guys do on Pygame - I've been doing some cool
>> stuff with. Keep up the good work:)
>>
>> Thanks
>>
>>
>

Re: [pygame] [PLEASE TEST]: New locking code

[Charlie Nolan]

Modify it to print a warning to stderr and then go ahead for 1.8.1,
then throw an error in 1.9?

-FM

On 6/10/08, René Dudfield <[EMAIL PROTECTED]> wrote:
> Also note that we *need* to retain compatibility with existing code -
> at least for pygame 1.8.1.  We shouldn't break existing code.
>
>
> On Wed, Jun 11, 2008 at 8:45 AM, Charlie Nolan <[EMAIL PROTECTED]>
> wrote:
>> That was the point, yes.  Silently failing is a Bad Idea.
>>
>> -FM
>>
>> On 6/10/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
>>> I assume you are saying surface.unlock should throw an exception as
>>> opposed
>>> to do nothing in the cases where it's not valid? (if so, I agree)
>>>
>>> Or was there some other condition you were thinking of as well?
>>>
>>> On Tue, Jun 10, 2008 at 3:23 PM, Charlie Nolan <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Errors should never pass silently.
>>>> Unless explicitly silenced.
>>>>
>>>> -FM
>>>>
>>>> On 6/10/08, Marcus von Appen <[EMAIL PROTECTED]> wrote:
>>>> > Hi,
>>>> >
>>>> > regarding Jake's unlock() report I changed the locking behaviour to be
>>>> > more strict about who can unlock a locked surface.
>>>> >
>>>> > While it was possible to completely unlock a surface at any time from
>>>> > anywhere, it is now strongly tied to the object, which caused the
>>>> > lock.
>>>> >
>>>> > While it was possible to do stuff like
>>>> >
>>>> >   subsurface = surface.subsurface (...)
>>>> >   subsurface.lock ()
>>>> >   surface.unlock ()
>>>> >   # surface is unlocked again although subsurface is locked
>>>> >   ...
>>>> >   sfarray = pygame.surfarray.pixels3d(surface)
>>>> >   surface.unlock ()
>>>> >   # Monsters live here
>>>> >   ...
>>>> >
>>>> > you now have to explicitly release the lock using the object that
>>>> > caused
>>>> > it:
>>>> >
>>>> >   subsurface = surface.subsurface (...)
>>>> >   subsurface.unlock ()
>>>> >   surface.unlock () # No effect
>>>> >   subsurface.unlock ()  # Now the lock is released.
>>>> >   # surface is unlocked again
>>>> >   ...
>>>> >   sfarray = pygame.surfarray.pixels3d(surface)
>>>> >   surface.unlock () # Nothing happens
>>>> >   del sfarray   # Surface will be unlocked
>>>> >   # Rainbowland's coming!
>>>> >   ...
>>>> >
>>>> > The surface.get_locked() method was adjusted accordingly and works as
>>>> > supposed now. Additionally the surface got a new get_locks() method,
>>>> > which returns a tuple with the object holding a lock. Though this is
>>>> > not
>>>> > always exact or very helpful, it can give you a quick overview about
>>>> > the
>>>> > reason for a dangling lock (numpy surfarrays for example are not
>>>> > listed,
>>>> > but a surface buffer instead as that one caused the lock).
>>>> >
>>>> > As this is tightly bound to reference counts, weakref pointers and
>>>> > other
>>>> > big sources for errors, I beg anyone to test it extensively with your
>>>> > code.
>>>> >
>>>> > Attached you'll find the patch, which hopefully brings love, joy,
>>>> >  happiness and less errors to pygame.
>>>> >
>>>> > Regards
>>>> > Marcus
>>>> >
>>>>
>>>
>>
>

Re: [pygame] [PLEASE TEST]: New locking code

[Charlie Nolan]

That was the point, yes.  Silently failing is a Bad Idea.

-FM

On 6/10/08, Brian Fisher <[EMAIL PROTECTED]> wrote:
> I assume you are saying surface.unlock should throw an exception as opposed
> to do nothing in the cases where it's not valid? (if so, I agree)
>
> Or was there some other condition you were thinking of as well?
>
> On Tue, Jun 10, 2008 at 3:23 PM, Charlie Nolan <[EMAIL PROTECTED]>
> wrote:
>
>> Errors should never pass silently.
>> Unless explicitly silenced.
>>
>> -FM
>>
>> On 6/10/08, Marcus von Appen <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> > regarding Jake's unlock() report I changed the locking behaviour to be
>> > more strict about who can unlock a locked surface.
>> >
>> > While it was possible to completely unlock a surface at any time from
>> > anywhere, it is now strongly tied to the object, which caused the lock.
>> >
>> > While it was possible to do stuff like
>> >
>> >   subsurface = surface.subsurface (...)
>> >   subsurface.lock ()
>> >   surface.unlock ()
>> >   # surface is unlocked again although subsurface is locked
>> >   ...
>> >   sfarray = pygame.surfarray.pixels3d(surface)
>> >   surface.unlock ()
>> >   # Monsters live here
>> >   ...
>> >
>> > you now have to explicitly release the lock using the object that caused
>> > it:
>> >
>> >   subsurface = surface.subsurface (...)
>> >   subsurface.unlock ()
>> >   surface.unlock () # No effect
>> >   subsurface.unlock ()  # Now the lock is released.
>> >   # surface is unlocked again
>> >   ...
>> >   sfarray = pygame.surfarray.pixels3d(surface)
>> >   surface.unlock () # Nothing happens
>> >   del sfarray   # Surface will be unlocked
>> >   # Rainbowland's coming!
>> >   ...
>> >
>> > The surface.get_locked() method was adjusted accordingly and works as
>> > supposed now. Additionally the surface got a new get_locks() method,
>> > which returns a tuple with the object holding a lock. Though this is not
>> > always exact or very helpful, it can give you a quick overview about the
>> > reason for a dangling lock (numpy surfarrays for example are not listed,
>> > but a surface buffer instead as that one caused the lock).
>> >
>> > As this is tightly bound to reference counts, weakref pointers and other
>> > big sources for errors, I beg anyone to test it extensively with your
>> > code.
>> >
>> > Attached you'll find the patch, which hopefully brings love, joy,
>> >  happiness and less errors to pygame.
>> >
>> > Regards
>> > Marcus
>> >
>>
>

Re: [pygame] [PLEASE TEST]: New locking code

[Charlie Nolan]

Errors should never pass silently.
Unless explicitly silenced.

-FM

On 6/10/08, Marcus von Appen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> regarding Jake's unlock() report I changed the locking behaviour to be
> more strict about who can unlock a locked surface.
>
> While it was possible to completely unlock a surface at any time from
> anywhere, it is now strongly tied to the object, which caused the lock.
>
> While it was possible to do stuff like
>
>   subsurface = surface.subsurface (...)
>   subsurface.lock ()
>   surface.unlock ()
>   # surface is unlocked again although subsurface is locked
>   ...
>   sfarray = pygame.surfarray.pixels3d(surface)
>   surface.unlock ()
>   # Monsters live here
>   ...
>
> you now have to explicitly release the lock using the object that caused
> it:
>
>   subsurface = surface.subsurface (...)
>   subsurface.unlock ()
>   surface.unlock () # No effect
>   subsurface.unlock ()  # Now the lock is released.
>   # surface is unlocked again
>   ...
>   sfarray = pygame.surfarray.pixels3d(surface)
>   surface.unlock () # Nothing happens
>   del sfarray   # Surface will be unlocked
>   # Rainbowland's coming!
>   ...
>
> The surface.get_locked() method was adjusted accordingly and works as
> supposed now. Additionally the surface got a new get_locks() method,
> which returns a tuple with the object holding a lock. Though this is not
> always exact or very helpful, it can give you a quick overview about the
> reason for a dangling lock (numpy surfarrays for example are not listed,
> but a surface buffer instead as that one caused the lock).
>
> As this is tightly bound to reference counts, weakref pointers and other
> big sources for errors, I beg anyone to test it extensively with your
> code.
>
> Attached you'll find the patch, which hopefully brings love, joy,
>  happiness and less errors to pygame.
>
> Regards
> Marcus
>

Re: [pygame] PATCH: Readability fix for "make chunk a power of 2" (src/mixer.c)

[Charlie Nolan]

The replacement should be functionally identical to the old version,
so if you extract each to an individual function, you can just check
to see that they're equal.  chunk is both input and output.

A good set of values to test:
-1, 0, 42, 255, 256, 257, 1023, 1024, 1025, 1024 * 3, 4095, 4096, 4097

Incidentally, 1024 * 3 is a strange value to use for the default
buffer size.  It'll always get bumped to 1024 * 4 when it hits this
chunk of code.  (or dropped to 256, in the bugged code)

I'd do it myself, but given my level of C knowledge, it'd take an
inordinate amount of time.  Modifying existing code is a whole lot
easier than creating it from whole cloth.

-FM

On 6/10/08, René Dudfield <[EMAIL PROTECTED]> wrote:
> hi,
>
> thanks for the patch, sorry I haven't got around to applying it yet.
>
> Since I think the existing code works, I thought I'd just leave it for
> now - and do other 1.8.1 things.
>
> If you can give me a test function to prove your patch also works,
> then I'll add it - but otherwise I won't apply it until pygame 1.9
> since the existing code *seems* to work.
>
>
> cheers,
>
>
> On Tue, Jun 10, 2008 at 6:05 PM, Charlie Nolan <[EMAIL PROTECTED]>
> wrote:
>> So is the patch ever going to get applied to SVN, or are people just
>> smiling and ignoring me?  :)
>>
>> -FunnyMan3595 (Charlie Nolan)
>>
>> On 5/22/08, René Dudfield <[EMAIL PROTECTED]> wrote:
>>> Thanks Charlie.
>>>
>>> Yeah, I hope to finish off most of the 1.8.1 things this weekend - and
>>> then do some RC releases for about a week.
>>>
>>> If you feel like doing some more patches here are the things to do ...
>>> http://www.pygame.org/wiki/todo#Open%20Issues
>>>
>>> cheers,
>>>
>>>
>>>
>>> On Thu, May 22, 2008 at 6:10 PM, Charlie Nolan <[EMAIL PROTECTED]>
>>> wrote:
>>>> Hopefully this simplifies that section enough that we don't get
>>>> another mixup like the one 1222 fixed:
>>>> http://www.seul.org/viewcvs/viewcvs.cgi/trunk/src/mixer.c?root=PyGame&rev=1222&r1=1158&r2=1222
>>>>
>>>> Applies to revision 1236.
>>>>
>>>> The bug's in 1.8.0, and it does ugly things to the sound.  Might want
>>>> to get a bugfix release out soon.
>>>>
>>>> -Charlie Nolan
>>>>
>>>
>>
>

Re: [pygame] PATCH: Readability fix for "make chunk a power of 2" (src/mixer.c)

[Charlie Nolan]

So is the patch ever going to get applied to SVN, or are people just
smiling and ignoring me?  :)

-FunnyMan3595 (Charlie Nolan)

On 5/22/08, René Dudfield <[EMAIL PROTECTED]> wrote:
> Thanks Charlie.
>
> Yeah, I hope to finish off most of the 1.8.1 things this weekend - and
> then do some RC releases for about a week.
>
> If you feel like doing some more patches here are the things to do ...
> http://www.pygame.org/wiki/todo#Open%20Issues
>
> cheers,
>
>
>
> On Thu, May 22, 2008 at 6:10 PM, Charlie Nolan <[EMAIL PROTECTED]>
> wrote:
>> Hopefully this simplifies that section enough that we don't get
>> another mixup like the one 1222 fixed:
>> http://www.seul.org/viewcvs/viewcvs.cgi/trunk/src/mixer.c?root=PyGame&rev=1222&r1=1158&r2=1222
>>
>> Applies to revision 1236.
>>
>> The bug's in 1.8.0, and it does ugly things to the sound.  Might want
>> to get a bugfix release out soon.
>>
>> -Charlie Nolan
>>
>

[pygame] BUG: Detecting rotation at multiples of 90

[Charlie Nolan]

transform.c, 574..586
if (!(((int) angle) % 90))
{
#  (snip) Exact rotation for angles that are multiples of 90.
}

There's a subtle bug here, in that casting to int will eliminate the
full-precision rotation on every range (90*x, 90*x + 1).  My C-fu is a
bit weak, but I think that can be fixed by changing the if statement
to:
if ( !( angle % 90.0f ) )

-FunnyMan3595 (Charlie Nolan)

Re: [pygame] Fast simple transposition (90-degree rotation)?

[Charlie Nolan]

It's special-casing multiples of 90 since at least 1.7.1, from what I
read in the source.

In fact, there looks to be a subtle bug in how it detects them, but
I'll make a separate post for that.

-FM

On 6/10/08, Terry Hancock <[EMAIL PROTECTED]> wrote:
> What's the best way to do (exact) 90-degree rotations in PyGame?
>
> There doesn't seem to be a separate "transpose" operation in the
> "transform" module (I.e. an operation that swaps x & y coordinates).
>
> Does the "rotate" function special-case 90-degree interval rotations?
>
> Or is it more efficient to convert a PyGame Surface to a Python Imaging
> Library image and then transpose that? (PIL does have a separate
> "transpose" method).
>
> How efficient can this be? If I need to get a mirror image or a
> transposition of an existing surface (say a full-screen 1024x768 image),
> is it worth caching the result to disk? Or would it be faster to just
> flip it in memory whenever I need it? (IOW, how does a 90-degree
> rotation or a "flip" compare to a disk I/O on most computers?)
>
> BTW, I tried to look this up, but I can't find a discussion of it in the
> documentation, and wasn't sure how to look it up in the ML archives.
>
> Thanks,
> Terry
>
> --
> Terry Hancock ([EMAIL PROTECTED])
> Anansi Spaceworks http://www.AnansiSpaceworks.com
>
>

Re: [pygame] Re: [BUG] mixer.init() mixer.get_init() inconsistancies 1.8.0

[Charlie Nolan]

In case it's useful, here are my results, from pygame 1.8.0 on Gentoo Linux:

Tried (11025, -16, 1), got (11025, -16, 0)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (11025, -16, 2), got (11025, -16, 1)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (11025, -8, 1), got (11025, 8, 0)
Sample rate equal? True
Sample width equal? False
Sample number of output channels equal? False
Tried (11025, -8, 2), got (11025, 8, 1)
Sample rate equal? True
Sample width equal? False
Sample number of output channels equal? False
Tried (11025, 8, 1), got (11025, 8, 0)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (11025, 8, 2), got (11025, 8, 1)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (22050, -16, 1), got (22050, -16, 0)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (22050, -16, 2), got (22050, -16, 1)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (22050, -8, 1), got (22050, 8, 0)
Sample rate equal? True
Sample width equal? False
Sample number of output channels equal? False
Tried (22050, -8, 2), got (22050, 8, 1)
Sample rate equal? True
Sample width equal? False
Sample number of output channels equal? False
Tried (22050, 8, 1), got (22050, 8, 0)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (22050, 8, 2), got (22050, 8, 1)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (44100, -16, 1), got (44100, -16, 0)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (44100, -16, 2), got (44100, -16, 1)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (44100, -8, 1), got (44100, 8, 0)
Sample rate equal? True
Sample width equal? False
Sample number of output channels equal? False
Tried (44100, -8, 2), got (44100, 8, 1)
Sample rate equal? True
Sample width equal? False
Sample number of output channels equal? False
Tried (44100, 8, 1), got (44100, 8, 0)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (44100, 8, 2), got (44100, 8, 1)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (48000, -16, 1), got (48000, -16, 0)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (48000, -16, 2), got (48000, -16, 1)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (48000, -8, 1), got (48000, 8, 0)
Sample rate equal? True
Sample width equal? False
Sample number of output channels equal? False
Tried (48000, -8, 2), got (48000, 8, 1)
Sample rate equal? True
Sample width equal? False
Sample number of output channels equal? False
Tried (48000, 8, 1), got (48000, 8, 0)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False
Tried (48000, 8, 2), got (48000, 8, 1)
Sample rate equal? True
Sample width equal? True
Sample number of output channels equal? False

On 6/7/08, Frankie <[EMAIL PROTECTED]> wrote:
> On Jun 7, 3:59 pm, Frankie <[EMAIL PROTECTED]> wrote:
> *snip*
>
> Here's a related possible bug that makes me suspect that those
> inconsistancies may be something to do with my setup. (I get these
> problems on the release and the svn HEAD running on Ubuntu 8.04. The
> versions of the requirements are all the ones from the repositories.)
>
> #The problem is that:
> import pygame
> import numpy
> import math
> #when the mixer is initialised with 1 output channel
> pygame.mixer.init(44100, -8, 1)
> #and numpy is used instead of numpy for sndarray
> pygame.sndarray.use_arraytype('numpy')
> #and then make_sound is run on a one-dimension array (in this case a
> sine wave at the pitch of the note A4)
> pygame.sndarray.make_sound(numpy.sin(numpy.array(xrange(1)) * 440
> * 2 * math.pi / 44100)
> #I get this error
> : Array must be 2-dimensional for stereo
> mixer
>
> For me it works just changing "if channels == 1:" to "if channels ==
> 0:" on line 122 of _numpysndarray.py. But this fix conflicts with
> fixing the bug this is a reply to.
>
> Numeric arrays work fine for me by the way. Which is weird, because I
> looked at the c for that and it seemed more or less a 1:1 translation
> (for that section).
>
> Oh, and whilst I was in _numpysndarray.py I saw array(...) and
> samples(...) (whose implementation should probably be merged, even if
> they're left seperate in the api considering the only difference is
> the ".raw" in the line "data = sound.get_buffer().raw" unilke the
> Numeric implementation) use the line "channels =
> mixer.get_num_channels()" to get the number of mixing chan

Re: [pygame] unsubscribe

[Charlie Nolan]

You missed.  See: http://www.pygame.org/wiki/info

On 6/4/08, Jason Ward <[EMAIL PROTECTED]> wrote:
> unsubscribe
>

Re: [pygame] weakref WeakKeyDictionary machinery.

[Charlie Nolan]

And why are you asking us?  This is the pygame mailing list, last I
checked, and a quick search of the code suggests that pygame doesn't
use either Weak*Dictionary.

On 6/1/08, Gabriel Hasbun <[EMAIL PROTECTED]> wrote:
> Hello I searched the whole web for good examples on weakref module's
> WeakKeyDictionary, but have found none, All I find is the Python Docs
> explanations, and some examples which actually doesn't explain how the
> mechanism of key reference removal works:
>
> import weakref
> class Tracking:
> _instances_dict = weakref.WeakValueDictionary(  )
> _num_generated = 0
> def _ _init_ _(self):
> Tracking._num_generated += 1
> Tracking._instances_dict[Tracking._num_generated] = self
> def instances(  ): return _instances_dict.values(  )
> instances = staticmethod(instances)
>
>
>
>

Re: [pygame] [Pygame] How can I have an accurate timing when I am showing an image?

[Charlie Nolan]

That's actually a standard problem with scheduling; you'll sometimes
be jostled out of the delay before the time is up.  The solution that
the sched module uses is essentially this:

startTime = time.time()
desiredEndTime = startTime + TIME_TEST_IMAGE
# Your setup would go here.
while True:
current_time = time.time()
if current_time >= desiredEndTime:
break
else:
pygame.time.delay(desiredEndTime - time.time())

For a delay of 800 ms, you might want to use pygame.time.wait.  If
that's not accurate enough (I'm only seeing ~1ms off), you can always
use pygame.time.wait for the first 700 ms, and then use that loop for
the last 100 ms.

Also, if the exact display time is critical, you might want to take a
look into how long it takes to display and clear the image, move as
much of that work as possible elsewhere, and adjust your timing for
what you can't avoid.  Loading and blitting the image, for instance,
could be moved before the start, since the image isn't actually
displayed until you call display.update.

-Charlie Nolan

On Fri, May 23, 2008 at 2:38 PM, Francesco Martino
<[EMAIL PROTECTED]> wrote:
> I am using Pygame for building a psychological experiment.
> The code should do something very easy: it should display an image for
> a limited amount of time, then show a blank screen and then another
> image. Images are stored as bitmap files (470 Kb each).
> The main requisite for this program is that timing needs to be very
> accurate, namely if I say that an image should be displayed for 800
> msec the amount of error should be as little as possibile.
>
> The code is very simple: each image is shown using
>
>startTime = time.time()
>test = image.load(image1).convert() #image1 is the name of the file
>surf.blit(test, (0,0))
>display.update()
>pygame.time.delay(TIME_TEST_IMAGE)
>stopTime = time.time()
>img_length = stopTime - startTime
>
> Using the Python time module, I see that error is acceptable for my
> purposes (the range is TIME_TEST_image +/-1, plus a costant error of
> 45 msec, so image is displayed for about 845 msec) in most of the
> cases. Unfortunately, sometimes the image is displayed for a shorter
> time (with a costant error of 11 msec, so image is displayed for about
> 811 msec) Since it happens with an irregular rate, it is very
> difficult to understand the reason. Has anyone some ideas? Is there a
> better way to display images for a fixed period of time with pygame?
>
> Thank you for any idea
> Francesco
>

[pygame] PATCH: Readability fix for "make chunk a power of 2" (src/mixer.c)

[Charlie Nolan]

Hopefully this simplifies that section enough that we don't get
another mixup like the one 1222 fixed:
http://www.seul.org/viewcvs/viewcvs.cgi/trunk/src/mixer.c?root=PyGame&rev=1222&r1=1158&r2=1222

Applies to revision 1236.

The bug's in 1.8.0, and it does ugly things to the sound.  Might want
to get a bugfix release out soon.

-Charlie Nolan


pygame-sound-patch-svn.patch
Description: Binary data