The attached code will produce ten 64x64 blocks of color,
the first nine being:
white, white/black, red, orange, yellow, green, blue, indigo, and violet
the white comes from the background screen being filled with white, so the first and second blocks are really: transparent and transparent/black

the first two color entries in the palette are both black, but index 0 is used as the color key.

When blitting image1 (the transparent/black) one to special_image surface.. basically, all pixel values of '\x01' are converted to '\x00' because it does an index lookup or some type of bug.

Basically the desired results are the last block to look just like the second (transparent/black) block via a blit() copy. I know this can easily be done with non-8bpp screen/surfaces, but I 8bpp still exists and should work properly. (My project requires it specifically, also)

You can see what is happening to the pixel data by writing the following two objects out to files and viewing with a hex editor (like i said all '\x01' become '\x00' (when they should be identical, in my opinion):

pygame.image.tostring( image1 )
pygame.image.tostring( special_image)

Created attachment 21
colors lost

my second attachment shows something someone figured out to *make* it work, although it's very hackish and a workaround.. not really making any sense and i can't understand what's happening but take a look

Created attachment 22
hackish workaround

Honestly, I don't understand what you are trying to achieve with this example.

However, it looks like the core of the issue here is that you have duplicate color entries in your palette, and you don't like that pygame is picking to represent colors that match that duplicate entry in your destination pixels as the first entry in the palette.

That behavior is not a bug - it's perfectly appropriate for a palette-based system. If you have duplicate color entries in your palette, you've made it impossible to practically distinguish one entry from the next, and you have to expect stuff like this to happen. I'm closing this as not a bug.

My recommendation would be to make every color entry in your palette distinct.

With pygame 1.7.1 and python 2.5 on Windows XP SP2, when I try to load an image using a python file object instead of passing a path, pygame crashes.

Reproducing is as simple as:

import pygame
pygame.image.load( open( 'image.png', 'r' ) )

While

pygame.image.load( 'image.png' )

works fine, and is what I converted my code to to work around the issue. It looks like this may be a return of an old bug, as I found some notes from years ago on the mailing list about the same kind of crash bug. My previous environment, pygame 1.7 and python 2.4 did not exhibit the same behaviour.

I have not tested with 1.8, as I didn't see a download option for it on the main pygame.org site.

This is fixed in latest (pre-release 1.8)

You can download an installer for the latest (again, pre-release) here:
http://thorbrian.com/pygame/builds.php

For a workaround in 1.7.1, see here:
http://archives.seul.org/pygame/users/Nov-2007/msg00133.html

1.8 has been released, and has this problem fixed in it.

Created attachment 12
Patch to fix MSYS detection when MSYS was not installed by the installer

The MSYS detection code in msys.py, specifically find_msys_registry(), attempts to find the directory the MSYS installer's uninstall entry has recorded in the Windows Registry, raising a LookupError exception if no result was found which allows higher code to fall back to prompting the user.

However, the call to _winreg.OpenKey is outside the try/except block, so if the key does not exist the wrong exception is thrown, and setup.py aborts without ever offering the prompt.

The attached patch corrects this, by ensuring that the OpenKey is performed inside the outer try block, and the outer try block raises a LookupError on an exception. The inner try block is still necessary to ensure that the finally clause is run if we successfully OpenKeyed.

Thanks for the report.

Fixed in SVN revision 1644

Created attachment 14
Test script to reproduce the problem

I have some code that takes an image, loads it into a surface, and blits an alpha transparent image with BLEND_RGBA_MULT to erase the corners. It works perfectly on Linux and Windows XP, but when I test it on my Mac the corners do not vanish, they just turn yellow. I would guess this means that the colors are mixed up when blitting in this way. The machine in question is a G7 PowerPC Mac. (I don't have access to an Intel Mac) so this could be an endiannness issue.

I am using python 2.5.2 (the python.org build) and pygame 1.8.1release-svn1537

Created attachment 15
kitten.jpg used by the test script

Created attachment 16
alpha_corner.png used by the test script

Created attachment 17
The entire test in a zip file

Lenard Lindstrom notes that adding .convert_alpha() to the line that loads alpha_conrer.png avoids this problem.

See: http://comments.gmane.org/gmane.comp.python.pygame/16810

-  corner = pygame.image.load(os.path.join("data", "alpha_corner.png"))
+  corner = pygame.image.load(os.path.join("data", "alpha_corner.png")).convert_alpha()

I believe rev. 1923 fixes this bug. However, it should be verified on a Mac.

I can confirm that this bug is fixed using the nightly build with subversion revision 1923. I tested on the same PowerPC Mac where I originally noticed the bug.

there doesn't seem to be an easy way to list all submitted bugs.

see https://bugs.launchpad.net/gcalctool as example:
Filters
Open 	       14
Critical 	0
New 	        2
Unassigned     14
All bugs ever reported 	54

I had to use the advanced search because you can't make a blank search on the normal search form to find any bugs.

At http://pygame.motherhamster.org/ there is a link labelled "All Open Bugs" which leads you directly to this list:

http://pygame.motherhamster.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&known_name=All+Open+Bugs&query_based_on=All+Open+Bugs&field0-0-0=noop&type0-0-0=noop&value0-0-0=

hi,

I updated the bugzilla link on this page:
http://pygame.org/wiki/patchesandbugs

To point to here: http://pygame.motherhamster.org/

Hopefully that'll solve that usability issue, since people will be directed to the easier to use page from the main pygame.org page.


Closing bug.


cu,

  ** registered this already.
  ** using our own hg.pygame.org domain is possible:
  http://confluence.atlassian.com/display/BITBUCKET/Using+your+Own+Bitbucket+Domain+Name

  ** will post a message on the mail list for people who want to be
  added.

  ** No way to import bugzilla bugs into bitbucket issues?  Need to check if this has been done before?
  ** http://confluence.atlassian.com/display/BITBUCKET/Using+your+Bitbucket+Issue+Tracker
  ** there is an issues api
  http://confluence.atlassian.com/display/BITBUCKET/Issues

  ** import all of the history with the hg convert plugin.
  *** http://mercurial.selenic.com/wiki/ConvertExtension
  ** Need author map, to convert pygame svn author usernames into
  bitbucket user names for people who care.
  *** email mailing list asking for bitbucket usernames of commiters.
  *** the format needed is: 'First Last <[email protected]>'
  *** will check an authormap file into svn.
  ** what to do with branches, and trunk?
  ** instead of a trunk the root should be the trunk.

  ## uses 'creol' syntax.  Will need to convert pages from html into
  this format.
     *** there is a html2creol converter here:
     http://code.google.com/p/python-creole/
     *** will keep current pygame wiki up, with links to new pages until
  conversion is complete.
  ## Check with bitbucket if they have plans to support .rst soon.
  ## need to create mirror system to keep website up to date.
     *** on wiki change, download new data then convert from creol format into html.

  ** delete files in trunk, and put a we_have_moved.txt file in there.

  ** mirror download files from the bitbucket download page to the pygame
  /ftp page.
  ** need to think how the html page will be structured. Do we just list
  all files on bitbucket?  I think we just list all of the files

  ** instructions on hg, and submitting patches.  As well as writing
  docs.

Created attachment 6
support display.set_mode((0,0))

[quote from the SDL_SetVideoMode docs]
As of SDL 1.2.10, if width and height are both 0, it will use the width and height of the current video mode (or the desktop mode, if no mode has been set).
[/quote]

The patch adds support for this behavior to pygame. 
It also makes the (w, h) argument optional.

marcus modified to support either width or height being 0 with the other arg non-zero, and committed rev. 1150

Created attachment 34
Sample script of one example where it does not work.

Using the command pygame.mixer.music.play() only plays the background once no matter what parameter is given.  -1 will cause it to only play once.  > 1 will still only cause it to play once.  I have only tried this with a .mid file.  pygame.mixer.Sound works as it should.

Created attachment 31
The error message.

I tried to upload a bmp file as a screenshot for a project on the website and got the attached error message.

png works fine by the way.

The unofficial way, which seems to be in some old documentation cached by google but not in any of the actual documentation anymore, is to do myrect.move(0, 0).  This is non-obvious and mysteriously undocumented now.  A Rect.copy() method is much clearer and should be trivial to implement.

Also, Rect(myrect) to do a copy is inconvenient because then it requires an import of Rect in every source file that you want to copy rects in.  A Rect.copy() would lift that requirement, and is in line with Python style, e.g. dict.copy().

Err... ok, looking through the docs, there is a copy function available as __copy__ which copy.copy() will use.  So why not just make it Rect.copy() as dict does?

More relevant, it is consistent with Surface.copy.
Added in revision 1924.

When running synergy http://synergy2.sourceforge.net/ on a windows xp or vista machine, virtual mouse input mode (automatically on when either mouse grabbed and cursor invisible or fullscreen and cursor invisible) gets all broken. The mouse moves wrong and seems to want to stick to the edge of the window.

The attached script can be used to play with mouse grab, fullscreen and cursor visible

Created attachment 10
a test script to play with mouse and fullscreen settings

Hi,

I think this bug should be reported to SDL and synergy bug trackers.

cu,

link to synergy bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1973818&group_id=59275&atid=490467

link to SDL bug:
http://bugzilla.libsdl.org/show_bug.cgi?id=590

No activity from either synergy or sdl at their respective given bug report links.
2009-05-27

I've been working on tracking down a bug for a while now and only just was able to attribute it to pygame failing. In my application, calling pygame.event.post simply does nothing if the binaries have been stripped to only contain the ppc code. The i386 code works, but the ppc code does not work on an i386 machine or a ppc machine. I have not yet tried a fat binary on a ppc machine, but I doubt it will make a difference.

Calling pygame.event.post raises no exception, and the event is not received from the event queue. The event queue still receives events normally, though.

My build environment:
OS: Mac OS 10.5.2
Python: 2.5.2, built with "-Wall -fno-strict-aliasing -g -O2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -mmacosx-version-min=10.3.9" as CFLAGS and LDFLAGS.
PyObjC: 1.4, built painfully and using the same CFLAGS and LDFLAGS.
py2app: 0.3.6.

Created attachment 9
A simple proof-of-concept

This zipfile contains just enough code to demonstrate the bug. You most likely need a version of python linked against the 10.4u SDK. It might also work built on a PPC machine linked with only PPC binaries, but I don't have access to a PPC machine and I can't try it. At any rate, the event posted on mousedown only shows up in the queue from the i386 binary when I build it. Run mkbuild.sh to invoke py2app and separate the resulting bundle into PPC and i386 bundles.

Hello,

thanks for the report and test case.  I'm not near a mac at the moment, but should have access to one later in the week.



In the mean time...

Which version of SDL are you using?

SDL_PushEvent is the function used in SDL.  Are you able to check to see if that works ok by itself?  Then we will be able to see if it is an SDL specific bug, or a pygame specific bug.

I checked on the sdl bug tracker, and found no bugs to do with SDL_PushEvent listed, and I found none on google.

If you find it to be a SDL specific bug please make a bug report here:
http://bugzilla.libsdl.org/



cheers,

I did some more testing, and I found that it was something to do with how I was trying to bootstrap my application. If I don't use the runEventLoop function provided by PyObjC, it works fine. I'd say this is a nonissue because I got it to work. If somebody really wanted to look into why it doesn't work, that's fine, but I think it was partly my nonstandard usage of PyObjC with pygame.

Trying out the new sndarray/numpy features and stereo sound. Very short script with error message:

from pygame import mixer, sndarray
from numpy import array

mixer.init(stereo=2)

sndarray.use_array('numpy')
sound = sndarray.make_sound(array([(x, 2*x) for x in xrange(22050)], dtype='int16'))

Traceback (most recent call last):
  File "pygame_snd.py", line 4, in <module>
    mixer.init(stereo=2)
TypeError: init() takes no keyword arguments

In general pygame functions, and documentation do not support kw args, but the documentation does show defaults.

This should be fixed in the 1.9 release of pygame, to make it more friendly.

Done in revision 1893.

The documentation says that Font.render()'s background argument defaults to None, however if None actually used it raises an exception:

TypeError: Invalid background RGBA argument

This became problematic when I wanted to extend the default Font class with my own render function. I can't simply accept a background argument with a default value of None and pass it on to the original renderer, if the background is None then the argument has to be excluded completely.

Created attachment 36
proposed patch font render for enable background=None

based on revision 2827

Created attachment 37
test for attachment 36

Created attachment 8
Bugfix patch

pygame.image.save doesn't save to the correct format.  This code should demonstrate:

import pygame

#original test file is a 320x240 88.7kB png file 
im = pygame.image.load('/tmp/img0.png')

#yields img1.png, 13.0kB jpeg file
pygame.image.save(im, '/tmp/img1.png')

#yields img2.PNG, 191.5 kB TGA file
pygame.image.save(im, '/tmp/img2.PNG')

#yields img3.tga, 191.5 kB TGA file
pygame.image.save(im, '/tmp/img3.tga')

#yields img4/jpeg, 13.0 kB jpeg file
pygame.image.save(im, '/tmp/img4.jpeg')

#end of script

I believe the problem lies in src/imageext.c, around line 450.  I've attached a patch which I believe fixes the problem.

By the way, this is one of my first patches ever, so comments on the way I've submitted it are welcome.

committed 1205

Nick, please confirm in that revision.

... as far as feedback on the patch goes - what you submitted is a patched file, which is not the same thing as a patch. Subversion can produce patches for you with the diff command.

Your test script was great, btw - turns out there was also a problem with saving .JPEG files (would save as TGA's)

I actually did create a diff, but attached the wrong file.  D'oh!

originally reported by inahe to the mailing list.

attached is a script that reproduces the problem.

Created attachment 4
Test case

Bug confirmed.

Changing:
    cursor = SDL_CreateCursor (anddata, xordata, w, h, spotx, spoty);
to:
    cursor = SDL_CreateCursor (xordata, anddata, w, h, spotx, spoty);

  in mouse.c just makes the cursor all black.


A test needs to be written for :pygame.mouse.set_cursor:  and also for "pygame.cursors.compile"

Likely to be pygame.cursors.compile I think...

Documentation here for SDL_CreateCursor:
  http://sdl.beuc.net/sdl.wiki/SDL_CreateCursor

In the SDL_CreateCursor documentation, it is given that white is 0 and black is 1, so in the compile function in cursors.py the following line
fillitem = fillitem | 1
should come in the black section of the if block and not in the white section.
This would set the colours right.

Created attachment 32
Patch for cursors.py

Created attachment 33
Program to test the memory leak. Comment line 32 and try again

I think I detected a memory leak with the pygame.image.save function, but I am a beginner so perhaps I do something wrong. Using python 2.6.2, pygame 1.9.1, windows XP.


I used Windows Task Manager to detect the leak.

I ran into this too. I took a look at the code and noticed that saving PNGs loads the imageext module while saving BMPs does not. I switched to saving BMPs and my code no longer leaks memory. So the problem is somewhere in the PNG saving code. Have not tried JPG, but that might help narrow it down further.

Jpeg is stable as BMP. 
PNG is causing memory leak also for me (AMD SMP 64 BIT - Ubuntu 10.04, pygame 1.9.1)

Created attachment 38
patch to fix the memory leak

The write_png function was not deallocating the structures it created in the png library. This adds the call to make sure that both structures are deallocated.

The patch does not correctly handle a specific error case. I don't see how to handle it. (details in comment in patch). However, that is an unlikely case and the only problem remaining is the memory leak.

No test case added as I'm not sure how to write a test on a memory leak.

In the pygame 0.8.1 tarball, all files in lib/ have 700 permissions. The icon file freesansbold.ttf and the icon files pygame.ico and pygame_icon.* included.

When installing pygame system-wide, the restrictive 700 permissions on these files are kept, as they are just installed as data. Of course, they are now owned by root, not the user - so a regular user cannot access them. This causes pygame-based applications including at least childsplay, but probably more, to fail to run, because freesansbold.ttf cannot be opened. Changing the permissions on freesansbold.ttf to 644 resolves this problem.

See this Mandriva forum thread:

http://forum.mandriva.com/viewtopic.php?p=606600#606600

and this one from PCLOS:

http://hack.mypclinuxos.com/index.php?action=printpage;topic=606.0

both a result of this bug.

Created attachment 18
pygame-1.8.1release.tar.gz with corrected permissions, unix line endings, and .pyc files removed

I am guessing that some poor misguided windows-using soul just converted the zip file into a tarball without realizing the implications :)

I have fixed the permissions, fixed the line-ending style on all .py files, and removed all .pyc files

I'm not sure who has permissions to upload a new tarball to the main site.

Rene, did you make the original tarball? Can you check out James' fixed version and upload it if it's good?

thanks!

hi,

the pygame 1.9 release will fix these issues.  

Executable bits on files have been addressed with a script made by Lenard and modified by me, and I have made a note to check line endings before release.

I think it happened because I used the sdist command on a windows machine from a non-fresh checkout.

Adding a note to the how_to_release_pygame.txt about it.

Will just leave the 1.8.1release how it is, and ask people to move to 1.9... which also fixes more bugs.

I really should have looked at this earlier... but the 1.9 release is only 2-3 weeks away now.

cu,

Pygame 1.8.1 (downloaded yesterday (July 31, 2008))
WinXP, Python 2.5.1

I had a hard time debugging this and tracking it to a specific pygame call, but I finally did it!  My codebase is large, and separated into several modules/layers of abstraction.  I'm not sure exactly what causes the crash, but I know what I was doing in the area it occurs!

def move(self, offsets):
    """Blits the screen surface to itself with the provided offset (in tiles).

    Note: Old tiles are not cleared!
    """
    x = offsets[0] * self.font_width
    y = offsets[1] * self.font_height
    self.surface.set_colorkey()
    self.surface.blit(self.surface, (x, y))
    self.surface.set_colorkey(self._colorkey)
    self.redraw()

This code works the first time it is called for each surface, but on the second call it crashes.  I just tried blitting a surface to itself in an interactive interpreter, but that crashed on the first try!  Also I think the (new in this version?) surface mask is being modified incorrectly/not being cleared by surface.set_colorkey?

Everything works fine in PyGame 1.7 so this is caused by something in the new surface code.

This appears to be an SDL bug (it crashes in SDL, and it doesn't seem to happen with SDL 1.2.7). You are experiencing it with the latest pygame because the latest installs SDL 1.2.13. As far as I know, no SDL bug has been created for this (yet).

The bug fix for overlapping blits has been in the SDL SVN for some time. The Windows dependencies for Pygame 1.9.0 use a post 1.2.13 version of SDL (SVN revision 4114) which incorporates the fix.

As for surface mask, that is a separate issue. If it is a genuine bug it will be assigned its own bug report.

Created attachment 19
Test case showing colorkey blit causing tiling with a self blit

To run:

python test.py

The test case shows how blitting a surface with colorkey to itself causes repetitive patterns with a positive offset. Four blue rectangles are displayed when only two are expected.

A follow-up.

The attached test case shows how a blitting a surface with colorkey to itself causes an unexpected result. The image is repeated multiple times. I believe this is what Ed Blake refers to when questioning if the "surface mask is being modified incorrectly/not being cleared by surface.set_colorkey".

This happens when a positive offset is used in a self blit. It was fixed in SDL, but is still a problem with Pygame specific blits, which involve destination alpha or blend blits. The copy overwrites the uncopied part of the surface, which is then copied itself. The solution is to reverse the copy direction in this case. Correcting self blits will be added to Pygame's todo list.

colorkey self blit support finished in rev 1953.

register_quit results in segfault, check the following:

import pygame

def foo():
    pass

pygame.register_quit(foo)
exit()
Segmentation fault


[784.028418] python[14917]: segfault at 00000008 eip 0811270c esp bf899310 error 4


Tested on Ubuntu hardy with python 2.5.2. I was unable to run pygame 1.8 properly on my system to test is as well. 

Best regards,
Markos Gogoulos

Python 2.5.4, Windows 98, Pygame 1.9.0.

This is also a Windows bug. The example code causes a page fault.

PYTHON caused an invalid page fault in
module PYTHON25.DLL at 015f:1e0711a9.

A Windows related register_quit crash was also noted by Brian Fisher at the automated build site when the Pygame unit test suite was run as a single process. The crash involved __PYGAMEinit__ in base_test.py registering pygame_quit for every pygame.init() call after the base_test.py tests ran. The automated builds started crashing after I added a pygame.init() to surfarray_test.py without a corresponding pygame.quit() call. I found the same problem on my machine, with the error dialog appearing at program completion. The crashes stopped when I pairing every pygame.init() with a pygame.quit() in surfarray_test.py (rev 1874).

Quoted directly from the Python 2.5.4 Python/C API Reference Manual

"5.2 Process Control 

....

int Py_AtExit( void (*func) ()) 

Register a cleanup function to be called by Py_Finalize(). The cleanup function will be called with no arguments and should return no value. At most 32 cleanup functions can be registered. When the registration is successful, Py_AtExit() returns 0; on failure, it returns -1. The cleanup function registered last is called first. Each cleanup function will be called at most once. Since Python's internal finalization will have completed before the cleanup function, no Python APIs should be called by func."

And that is exactly what the Pygame exit function, registered in base.c, does,
it makes Python API calls.

Fixed in revision 1916

Note: Pygame's quit mechanism could stand some reworking at a future date.

Created attachment 2
Patch against SVN.

The DisplayModes tutorial contains a small typo.

fixed in svn 1088

This issue is in the surflock.c, not surface.c. I diagnosed it in 1.8.1, but a quick look at subversion shows that the relevant code has not changed.

The PySurface_LockBy function is leaking a weakref.ref each time a surface is locked. The weak reference is created on line 82 of surflock.c, and then is appended to the list on line 90. PyList_Append does not steal the reference, and so the reference count remains incremented even when PySurface_LockBy returns, causing a memory leak.

The solution is to add Py_DECREF(ref) as line 91 of surflock.c, making the function read:

static int
PySurface_LockBy (PyObject* surfobj, PyObject* lockobj)
{
    PyObject *ref;
    PySurfaceObject* surf = (PySurfaceObject*) surfobj;

    if (!surf->locklist)
    {
        surf->locklist = PyList_New (0);
        if (!surf->locklist)
            return 0;
    }
    ref = PyWeakref_NewRef (lockobj, NULL);
    if (!ref)
        return 0;
    if (ref == Py_None)
    {
        Py_DECREF (ref);
        return 0;
    }
    PyList_Append (surf->locklist, ref);
    Py_DECREF(ref);
    
    if (surf->subsurface)
        PySurface_Prep (surfobj);
    if (SDL_LockSurface (surf->surf) == -1)
    {
        PyErr_SetString (PyExc_RuntimeError, "error locking surface");
        return 0;
    }
    return 1;
}

Thanks Tom!

Committed revision 2259.

I'm reporting this on behalf of a friend of mine who is helping me bug test a game. He installed Python 3.1 and Pygame 1.9.1 on his Windows XP machine but any Pygame scripts will crash. He tried installing and reinstalling Pygame but to no avail.

Here's the error he gets:

File "C:\Python31\lib\site-packages\pygame\__init__.py", line 95, in <module>
from pygame.base import *

ImportError: DLL load failed: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

When looking at the code I noticed that the '__repr__' method of the 'DirtySprite' class uses the 'self.__g' attribute. The problem is that this attribute does not exist for the 'DirtySprite' class. It is a member of the 'Sprite' class but is not easily accessed by subclasses.

It is very easy to reproduce the error. Just start Python (any recent version will do):
>>> import pygame
>>> sp = pygame.sprite.DirtySprite()
>>> repr(sp)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python2.5/site-packages/pygame/sprite.py", line 213, in __repr__
    return "<%s DirtySprite(in %d groups)>" % (self.__class__.__name__, len(self.__g))
AttributeError: 'DirtySprite' object has no attribute '_DirtySprite__g'


A simple fix is to replace 'len(self.__g)' with 'len(self.groups())'.

committed 1441, thanks Hakan!

Created attachment 20
patch to fix compilation errors when X11 not installed

Environment: Linux from Scratch 6.4, SDL 1.2.13, pygame-1.8.1release, *NO* X11.

Symptom: compilation errors in display.c and event.c, for example

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -D_REENTRANT -I/usr/X11R6/include -I/usr/include/SDL -I/usr/include/python2.6 -c src/display.c -o build/temp.linux-i686-2.6/src/display.o
src/display.c: In function 'get_wm_info':
src/display.c:325: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:329: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:333: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:337: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:341: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:345: error: 'SDL_SysWMinfo' has no member named 'info'

Solution: use SDL's SDL_VIDEO_DRIVER_X11 symbol instead of !DISABLE_X11 (patch attached).

There are 3 references to DISABLE_X11: display.c, event.c, and scrap.c.  The patch fixes all 3 but I haven't tested scrap.c because I haven't included scrap.

Rene, you use Linux right? can you confirm the patch?

Committed revision 2504.

cheers!

If I enable OpenGL on my display, teh evebnt system starts behaving differntly.  The following code prints all the events I am interrested in if i do not enable OpenGL.  If I enable it however, events from the touchscreen and stylus are not reaching the event queue.  

Note that this also happens for the simulated mouse events that windows generates for these input devices. When I dont enable OpenGL, and just get the normal mouse events (no fancy windows touchwindow, or using pymt.SYWMEVENT), everything is fine.  If I enable OpenGL however, mouse events are not generated when I use touch or stylus (although they move/controll the system mouse cursor) 

I am using pygame 1.9.1 with Python 2.6.2 on Windows 7.


import pygame
import ctypes

#if I uncomment this line, the window does not produce teh same events
#without it it works just fine!!
#display_flag = pygame.OPENGL

pygame.display.quit()
pygame.display.init()
pygame.display.set_mode((320, 240) display_flag)
pygame.event.set_allowed(pygame.SYSWMEVENT)

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

while True:
    for event in pygame.event.get():
        if event.type == pygame.SYSWMEVENT:
            print event

Created attachment 5
test case

originally from Will McGugan

see attached test case files (if you change sample_bits to 16, you can see the panning works as expected)

Added a work around in subversion r1143.

I'm 99% sure this is a bug in SDL_mixer.

Need to report it to the SDL bug tracker.

has this been submitted to SDL_mixer?

The bug has been reported to SDL.

Still not fixed as of rev. 4211 (Mon Dec 8 00:27:32 2008 UTC).

Created attachment 3
Script that causes the error described above

The attached script will cause a segfault. It creates a Surface called "screen" and gets the pixels2d array for that surface. Calling "del array" to delete the surface array causes the error to disappear, so the error may be a result of trying to free read-only memory during pygame.quit(). SVN revision 1119.

Marcus committed a fix in rev. 1120 - please confirm and close if it's fixed for you

For normal work with sound and mixer class i need use event system but in my system not have video.

Now i modify VIDEO_INIT_CHECK() macros in src/pygame.h for disable exception and my program good work.

I believe that this is not the correct logic of the pygame.

Created attachment 23
Callback function

Need provide Mix_HookMusicFinished callback to pygame for not event work with pygame.mixer.

I post patch but him segfault. :(

Sometimes we need to store a surface image into a string instead of a filename. I tested with StringIO and it worked:

import StringIO
fd = StringIO.StringIO()
pygame.image.save(surface, fd)
print len(fd.getvalue()) 
# 1334

However, since we have no real filename, we cannot set the file format. That's why I propose to add a third optional argument that forces the function to use a given format:

pygame.image.save(Surface, filename, format="TGA"): return None

Example programs fonty.py which come with pygame (pygame-1.9.1release/examples/fonty.py in file pygame-*release.tar.gz) crash with error message:
*** glibc detected *** python: double free or corruption
right after the line “screen.blit(ren, (10, 40 + size[1]))” while executing “font.set_underline(0)”.

Observed on pygame versions 1.8.1 and 1.9.1. Python version 2.6.2-r1, Freetype version  2.3.9-r1, SDL version 1.2.13-r1, SDL-TTF version 2.0.9, Gentoo Linux x86-64.

Created attachment 26
Program output after a crash

Created attachment 27
Output of "strace python fonty.py"

The documentation says that pygame.cursors.load_xbm has a default seconed argument of None.  Not only is this not so, but the method will crash if given None as a second argument, since it will then call None.readlines().  I'm afraid I don't know enough about cursors to offer a patch, although is seems like setting the default to None and moving everything that relates to the mask inside an "if mask is not None:" guard might be all it takes.

Saul, could you please provide a test case of some sort where you would want to call load_xbm without a mask argument?

It would be essential for me to be able to confirm correct behavior, as I don't know anything about xbm cursor files and how they are used. I can certainly code it to avoid an exception, but that's not sufficient - I need to code it to behave correctly.

If we can't find a way to confirm that calling load_xbm without a mask argument behaves correctly and is useful, then this bug will probably instead get resolved by changing the documentation.

I just came across this bug when trying to make my own custom cursor. Here's what I've discovered.

load_xbm takes two arguments, which are files, or filelike objects. The first file is the data corresponding to the black pixels in the cursor, the second file (or maskfile) corresponds to the white pixels. All other pixels are transparent.

Perhaps you want a cursor which is all black and has no white (this wouldn't be a very good cursor as it might get obscured). In that case you might not want to pass an additional maskfile.

In any case the documentation is wrong as a maskfile of None causes an error. Also it states that maskfile is a keyword argument, which it is not.

I would suggest changing the documentation to say that the maskfile argument is a mandatory argument, as cursors with only black pixels should be avoided, but would still be possible by passing a maskfile with no bits set.

Updated the documentation for this.

Committed revision 2268.


cheers!

Created attachment 35
Result of attached code.

Something to do with Snow Leopard? Maybe this should be passed upstream to the SDL-guys but I was baffled.

Drawing over black background, a white line is drawn in yellow.

Very easy to reproduce:
import pygame
screen = pygame.display.set_mode( (200, 200), 0, 32 )
pygame.draw.line( screen, (255, 255, 255), (0,0), (100, 100) )
pygame.draw.aaline( screen, (255, 255, 255), (0,100), (100, 200) )
pygame.display.update()


I've attached what this produces.

It is impossible to install pygame on my Mac OS X from the packages provided on the page http://pygame.org/download.shtml

I tried the three packages : 
 * pygame-1.9.1release-py2.6-macosx10.5.zip 10.3MB
 * pygame-1.9.1release-py2.5-macosx10.5.zip 10.3MB
 * pygame-1.9.1release-py2.4-macosx10.5.zip 10.3MB

And they all give me the following error : (sorry for the french)

 * Vous ne pouvez pas installer pygame 1.9.1release sur ce volume. pygame requires System Python 2.4 to install.
 * Vous ne pouvez pas installer pygame 1.9.1release sur ce volume. pygame requires System Python 2.5 to install.
 * Vous ne pouvez pas installer pygame 1.9.1release sur ce volume. pygame requires System Python 2.6 to install.

I use Mac OS 10.5.8 on a MacBook Pro with a 2.2 GHz Intel Core 2 Duo CPU, 2 Gb of RAM and 500 Gb of hard drive space. There is a Python that is installed with Mac OS X. 

I installed a few MacPorts Python packages though, and it might be the reason : 

python24 @2.4.6 (lang)
    An interpreted, object-oriented programming language
python25 @2.5.4 (lang)
    An interpreted, object-oriented programming language

But when I issue "which python" in a Terminal, it is the System Python that is listed, I think.

buzz:twisted aalex$ python -V
Python 2.5.1
buzz:twisted aalex$ which python
/usr/bin/python

This is fixed once I have installed http://www.python.org/ftp/python/2.5/python-2.5-macosx.dmg

This should be documented.

Created attachment 13
Test program that reproduces blit_array() bug.

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. The test program is attached.

Traceback (most recent call last):
  File "array_bug.py", line 6, in <module>
    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'

Fixed in SVN revision 1851.

The expected behavior for saving a file to a folder that doesn't exist is to raise a pygame.error . This does happen when I attempt to save in .tga format, however, with .jpg, it causes a segmentation fault. I can save .jpg files to folders that do exist. Here is what I ran in my interpreter to show this:
----
Python 2.5.1 (r251:54863, May  4 2007, 16:52:23) 
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygame
>>> pygame.init()
(6, 0)
>>> pygame.ver
'1.8.0release'
>>> pygame.image.get_extended()
1
>>> surf = pygame.Surface((100,100))
>>> pygame.image.save(surf, 'surf.jpg')
>>> pygame.image.save(surf, 'this/folder/doesnt/exist/test.tga')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
pygame.error: Couldn't open this/folder/doesnt/exist/test.tga
>>> pygame.image.save(surf, 'this/folder/doesnt/exist/test.jpg')
Fatal Python error: (pygame parachute) Segmentation Fault
Aborted
----
A suitable example script, then, would be:
----
#!/usr/bin/env python

import pygame
pygame.init()
surf = pygame.Surface((100,100))
pygame.image.save(surf, 'this/folder/doesnt/exist/test.jpg')
print "You made it!"
----

I left most of these admin-type values alone. I don't expect myself to be able to judge how bad the developers think this problem is, and I don't know what 'P5' or 'P4' is. Anyway, I hope I was as thorough as possible.

Created attachment 11
Test case as shown in bug report

fixed rev. 1248 - the crash was happening on any jpeg or png save error, actually, thanks for catching it

I'm using Pygame 1.9 with Python 3.1. The inconsistency with color input is slightly irritating. For example, Pygame.Color() accepts a variety of different input types. It accepts HTML style colors, tuples of integers, and hexadecimals. This is nice, but other parts of Pygame code don't use this. For example, Surface.fill() only accepts a tuple or a Color instance. I can't use the hexadecimal styles. I myself often make the mistake of using the wrong style of color and need to look up the documentation. I think consistency is extremely important for any software, especially a library for an elegant language like Python.

FrozenPUZZLE source code <http://up.servut.us/dl/8830> is unavailable. It should be removed or new source code link added.

This bug tracker is for problems with the source code of the pygame software. For problems with the pygame.org website/wiki/gamelist you should contact Phil Hassey. His contact info is at the bottom of every page at pygame.org

PNG and JPEG are installed and available via macports but are not detected by the installer because the current config_darwin.py only looks in /usr/local whereas macports uses /opt/local.

Patch adds additional paths for macports headers and libraries.

Created attachment 7
Patch to add macports paths

committed 1151. Peter, please confirm it works for you now and close bug if it does.

All good. One step closer to making pygame a little easier on mac.

In my pygame application I use a number of user-defined events to pass objects around the different components. These objects turn out to be relatively large sometimes. Every now and then, my application terminated with a segmentation fault but only when logging was active. The reason for this is the event_str function in src/event.c that returns the Event object's representation, e.g for printing it to stdout. It reserves a fixed length (1024) for the string representation which can overflow easily.

The following code illustrates the problem quite well:

import pygame
print pygame.event.Event(pygame.USEREVENT, data=range(1000))

>>> import pygame
>>> s = pygame.Surface.__new__(pygame.Surface)
>>> ss = s.subsurface((0, 0, 0, 0))
Fatal Python error: (pygame parachute) Segmentation Fault
Aborted

import pygame, unicodedata

pygame.init()
pygame.display.set_mode((150, 150))

print "ESC to quit"
print "Euro sign should be", hex(ord(u'\N{EURO SIGN}'))

while True:
	evt = pygame.event.wait()
	if evt.type == pygame.KEYDOWN:
		if evt.key == pygame.K_ESCAPE:
			break
		elif evt.unicode:
			print "%s (%s)" % (hex(ord(evt.unicode)),
				unicodedata.name(evt.unicode, "NO NAME"))

--
If you run this script and type a Euro sign, you can see that pygame gives its unicode value as 0x80 (An unnamed Unicode 'control' character /sometimes/ rendered with a Euro sign) instead of 0x20AC (Unicode "EURO SIGN").

I don't have a euro sign on my keyboard to test this.

I tried the example code on my workstation. 0x20AC (Unicode "EURO SIGN") was printed to the console as expected when I pressed RightAlt + E.

OS: Windows XP Professional (32-bit)
Keyboard service: French (France)
Python: 2.4
pygame: 1.9.2pre-svn2952

I also tried running the script and it gave the correct output: 0x20AC (Unicode "EURO SIGN")

OS: Ubuntu 10.04
Python: 2.6.5
Pygame: 1.9.1

Tested on 1.9.1 and svn-3193, both produces the correct result.

The code for the euro sign is 0x20AC for me as expected.
I have a hungarian keyboard, the combination is AltGr-U.

Created attachment 28
Example test script

When saving an image in png format the channels seem to be reversed. I attached
a script, on Windows they produce the same image, on OSX/powerpc they produce
the attached images,

Created attachment 29
PNG test image produced on MacOS powerpc

Created attachment 30
TGA test image produced on MacOS powerpc - this is how it should look like.

Python version : 3.1
pygame version : 1.91

pygame.mixer.Channel.play(Sound)

crashes with system error.

the same code works with python 2.4 so this could be python bug. I am not sure.

I am reporting just in case and let you guys to see where the actual bug is.

Thanks.

Pygame 1.9.0a0 rev 1749
Python 2.6.1
Windows XP

The test\mask_test.py unit test crashed with a Pygame parachute.

The problem has been traced to the test_from_threshold method. It crashed for all pixel sizes, 16, 24 and 32.

Possible fix in SVN rev. 1750
Passes for Python 2.5; needs Python 2.6 test.

Fixed in revision 1750

This method doesn't work with unicode symbols in os path.
For example:
audiofile = u'D:/Work/Projects/Programming/iTutor/src/iTutor/dictionaries/Казахо - Русский/3.mp3'
pygame.mixer.music.load(audiofile)

return error:
pygame.error: Couldn't read from 'D:/Work/Projects/Programming/iTutor/src/iTutor/dictionaries/Казахо - Русский/3.mp3'

if i'm delete 'Казахо - Русский/' from audiofile variable then method working normally.

When playing a midi in "looped" mode,
Pygame's mixer crashes on Mac OS X
Either loops=-1 or loops > 0 causes this.


1   com.apple.audio.CoreAudio      	0x91476d9a IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 274
2   com.apple.audio.CoreAudio      	0x91476b21 HP_IOThread::PerformIO(AudioTimeStamp const&) + 1299
3   com.apple.audio.CoreAudio      	0x91474f49 HP_IOThread::WorkLoop() + 953
4   com.apple.audio.CoreAudio      	0x91474b8b HP_IOThread::ThreadEntry(HP_IOThread*) + 17
5   com.apple.audio.CoreAudio      	0x91469171 CAPThread::Entry(CAPThread*) + 93
6   libSystem.B.dylib              	0x90024227 _pthread_body + 84

Travis - can you please attach a test case? a midi file and python script?

Confirmed it crashes on osx.

wget http://209.197.86.65/19841988/rock/beatles/ISawHerStandingThere.mid
wget http://rene.f0o.com/~rene/stuff/midi.py

python midi.py ISawHerStandingThere.mid

This bug has been submitted to sdl.

> python setup.py install --root=i1

WARNING, No "Setup" File Exists, Running "config.py"
Using UNIX configuration...

Hunting dependencies...
sh: sdl-config: not found
WARNING: "sdl-config" failed!
sh: smpeg-config: not found
WARNING: "smpeg-config" failed!
Unable to run "sdl-config". Please make sure a development version of SDL is installed.
> echo $?
0
> 

***

I am automatically building the packages in PyPI for some reason; and relying on the exit code of setup.py to see if a build failed or not. Your package (pygame) is the only aberration I've come across. 

Try using "sys.exit(1)" or "raise SystemExit, 'Unable to run ....'"

Created attachment 24
Code demonstrating the leak and the image used.

When using the following pygame.transform functions: scale(), smoothscale() and flip(), memory leaks occur.

Scaling a texture a hundred times per frame consumes a LOT of memory, rendering me unable to use such functions in my game.

I've attached a rar with the code that causes this and the image used.

Operating System: Windows XP SP3
Python version: 2.6.1
Pygame 1.8.1 (the package available at the download section)

With pygame 1.9.0rc1, and python2.5.2 on OSX I can not reproduce this.

Maybe it is a windows, or python2.6 specific bug, or perhaps it has been fixed.

Are you able to try this out with a new pygame?

Binaries here:
  http://thorbrian.com/pygame/builds.php

I have been able to bypass this in my game by reusing the same surface, not creating a new temporary one for each loop iteration.

I've tested this in 2.5.2 so it's not only in 2.6.

I'll try the new pygame version when I get some spare time.

Created attachment 25
Leak 'workaround' and another leak case

In this .rar there is a 'workaround' for the leak and a sligthly different test case in which leaking also occurs.

Tested with the original configuration.

Traceback (most recent call last):
  File "C:\dpf\AssemblyLine-0.4\run_game.py", line 13, in <module>
    main.main()
  File "C:\dpf\AssemblyLine-0.4\Game\Code\main.py", line 19, in main
    display = pygame.display.set_mode(settings.screen_size, settings.flags)
pygame.error: No available video device

all pygame dependencies installed

Hi,

looks possibly related to this bug report:
http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/423f1d7f3e909c38

Are you able to confirm which version of windows you're on?  


cu,

(In reply to comment #1)
> Hi,
> looks possibly related to this bug report:
> http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/423f1d7f3e909c38
> Are you able to confirm which version of windows you're on?  
> cu,

Hi cu,

I'm having the same issue on an XP machine.  When I execute
pygame.display.init() in the shell, I receive (5,1) rather than (6,0)
and when I try to execute pygame.display.set_mode I receive
pygame.error: No available video device.

Is there a way to determine what module is failing in the init() call?

tu,

Pygame XP