pygame-community / pygame-ce Goto Github PK
View Code? Open in Web Editor NEW🐍🎮 pygame - Community Edition is a FOSS Python library for multimedia applications (like games). Built on top of the excellent SDL library.
Home Page: https://pyga.me
🐍🎮 pygame - Community Edition is a FOSS Python library for multimedia applications (like games). Built on top of the excellent SDL library.
Home Page: https://pyga.me
Originally reported by: Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom)
The Surface.subsurface method fails to check if the surface is alive. The result is a Pygame parachute.
>>> import pygame
>>> s = pygame.Surface.__new__(pygame.Surface)
>>> ss = s.subsurface((0, 0, 0, 0))
Fatal Python error: (pygame parachute) Segmentation Fault
Aborted
Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):
The problem: in ^^surf_subsurface()^^, ^^surf->format^^ is assigned to ^^format^^ before ^^surf^^ is checked if ^^NULL^^.
Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):
Fixed <<changeset 38cdc3d7302a>>.
Case closed.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Markos Gogoulos, 2008-08-06 23:57:53 -0700
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
== Lenard Lindstrom, 2009-01-29 18:47:39 -0800
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).
== Lenard Lindstrom, 2009-02-06 21:49:29 -0800
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.
== Lenard Lindstrom, 2009-02-08 11:16:55 -0800
Fixed in revision 1916
Note: Pygame's quit mechanism could stand some reworking at a future date.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Nick Welch, 2008-11-21 01:36:44 -0800
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.
== Nick Welch, 2008-11-21 01:40:46 -0800
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().
== Nick Welch, 2008-11-21 01:48:55 -0800
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?
== Lenard Lindstrom, 2009-02-12 12:50:07 -0800
More relevant, it is consistent with Surface.copy.
Added in revision 1924.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Joshua, 2010-05-04 20:59:38 -0700
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/34/dodger.py| dodger.py]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Reported to SDL bug tracker:
http://bugzilla.libsdl.org/show_bug.cgi?id=934
The work around is to loop manually in your main loop by checking if get_busy() is false, and if so play the music again.
Original comment by Anonymous:
FYI, this is fixed for the next SDL_mixer release.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Vasiliy, 2009-09-01 11:32:23 -0700
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.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
This works with oggs and wavs on OSX.
I assume this is another smpeg error. Or perhaps a windows related error.
== Needs testing on windows.
Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):
According to the Python 2.7 //sys.getfilesystemencoding()// docs no encoding is done to the file path. So the UTF-16 Python string is just passed through. I don't know what encoding Windows uses, thought.
Original comment by Anonymous:
I think this might be a bytes/unicode misunderstanding:
I've tested this only on linux, on an utf8 filesystem, but
pygame.mixer.music.load('')
worked, whereas
pygame.mixer.music.load(u'')
didn't., but
pygame.mixer.music.load(u''.encode('utf8'))
again did.
Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):
My plan is to wrap pygame.mixer.music.load and pygame.mixer.music.queue with a function that uses Python's built-in open function to open Unicode paths.
Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):
Issue # 247 was marked as a duplicate of this issue.
Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):
Actually, the .encode('utf8') trick from Anonymous works on Windows for music.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
I've found the relevant source in music.c
, and it's using RWopsEncodeFilePath
to turn a unicode path into a bytes path. This is OK on Unix systems where paths are bytes, but Windows paths are unicode (handled as UTF-16). The 'filesystem encoding' on Windows is 'mbcs'
, which refers to the current system codepage. However, the typical default codepages (e.g. cp1252 for Western European languages) cannot represent all characters that might be in a path, so encoding a path is lossy. The right fix would be to open files using the unicode/wchar path on Windows.
I haven't tested this, but it looks like it should be possible to work around this by opening the file object in Python first:
with open(path) as f:
pygame.mixer.music.load(f)
I think Python's open function uses unicode paths on Windows.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== James Pettit, 2008-02-16 19:29:03 -0800
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
== illume, 2008-02-27 19:48:53 -0800
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.
== Lenard Lindstrom, 2009-01-29 18:12:01 -0800
Done in revision 1893.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: svn (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Victor Freire, 2009-06-14 13:52:40 -0700
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)
Attachments:
[[http://www.pygame.org/old_bug_attachments/24/leaktest.rar| leaktest.rar]]
== illume, 2009-06-28 21:44:16 -0700
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
== Victor Freire, 2009-06-30 18:30:25 -0700
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.
== Victor Freire, 2009-06-30 18:45:11 -0700
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/25/Leaktests.rar| Leaktests.rar]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
The test appears to use pygame.transform.scale when it leaks.
I made this test case from the one given. Then testsed it on OSX, and it does not leak memory. The memory stays between 20MB and 22MB according to activity monitor.
== Stand alone test case (needs testing in windows XP (or windows Vista/7).
import pygame, pygame.examples, time, os
pygame.init()
main_dir = os.path.split(os.path.abspath(pygame.examples.__file__))[0]
data_dir = os.path.join(main_dir, 'data')
image_path = os.path.join(data_dir, "arraydemo.bmp")
screen = pygame.display.set_mode((640, 480), 0, 32)
slice_h = 40
test_tile = pygame.image.load(image_path).convert()
slicescaled = pygame.Surface((1, slice_h))
going = True
while going:
going = pygame.QUIT not in [e.type for e in pygame.event.get()]
screen.fill((0, 0, 0)) # clear screen
for x in xrange(100):
texoffset = x
slicepiece = pygame.Surface((1, 128))
slicepiece.blit(test_tile, (0,0), (texoffset, 0, 1, 128))
pygame.transform.scale(slicepiece, (1, slice_h), slicescaled)
screen.blit(slicescaled, (x, 10))
pygame.display.flip()
pygame.time.wait(10)
pygame.quit()
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Tested by two people, one on windows 7 and another on XP. No memory leak now.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== John M, 2010-05-17 20:46:06 -0700
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/35/aalineBug.png| aalineBug.png]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Here is an easier to run example, that also shows the problem is to do with the screen surface and the draw routine.
import pygame
from pygame.locals import *
pygame.init()
screen = pygame.display.set_mode( (200, 200), 0, 32 )
surf = screen
print "screen info", surf.get_masks(), surf.get_shifts(), surf.get_pitch(), surf.get_losses()
surf = pygame.Surface( (200,200), 0, 32)
print "surface info", surf.get_masks(), surf.get_shifts(), surf.get_pitch(), surf.get_losses()
surf.fill((0,0,0,255))
pygame.draw.line( surf, (255, 255, 255), (0,0), (100, 100) )
pygame.draw.aaline( surf, (255, 255, 255), (0,100), (100, 200) )
screen.blit(surf, (0,0))
going = True
while going:
events = pygame.event.get()
if QUIT in [e.type for e in events]:
going = False
pygame.display.update()
On OSX Lion 64bit python it prints:
screen info (65280, 16711680, 4278190080, 0) (8, 16, 24, 0) 800 (0, 0, 0, 8)
surface info (16711680, 65280, 255, 0) (16, 8, 0, 0) 800 (0, 0, 0, 8)
So we can see that the screen surface, and a normal software surface is laid out differently. So there must be an issue with the draw.aaline method and this type of memory layout.
The example above shows a work around, of blitting to a normal surface and then blitting that surface to the screen. This works as expected and gives a white line, not a yellow one.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Seems fixed in the repository.
I'm getting the same problem with version 1.9.3.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Lorenz Quack, 2008-03-08 07:45:03 -0800
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/6/display.diff| display.diff]]
== Thorbrian, 2008-03-09 14:57:00 -0700
marcus modified to support either width or height being 0 with the other arg non-zero, and committed rev. 1150
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: svn (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Thomas Hansen, 2009-11-20 21:12:38 -0800
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
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
This is an SDL issue, or pymt issue. I'm guessing pymt needs to be modified to work with SDL opengl windows.
Closing.
Please reopen if you are still interested.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== John, 2010-05-25 20:25:21 -0700
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.
== Marco Chieppa, 2010-07-01 08:01:17 -0700
Created attachment 36
proposed patch font render for enable background=None
based on revision 2827
Attachments:
[[http://www.pygame.org/old_bug_attachments/36/pygame_font.c_patch| pygame_font.c_patch]]
== Marco Chieppa, 2010-07-01 16:32:41 -0700
Created attachment 37
test for attachment 36
Attachments:
[[http://www.pygame.org/old_bug_attachments/37/font_test2.py| font_test2.py]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Font.render can set backgound to None. Fixes # 49.
Thanks John and Marco Chieppa!
Original comment by Sami Loone (Bitbucket: dryatu, GitHub: dryatu):
This bug still occurs in pygame-1.9.2a0.win32-py2.7
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Thorbrian, 2008-05-23 03:47:18 -0700
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
== Thorbrian, 2008-05-23 03:47:59 -0700
Created attachment 10
a test script to play with mouse and fullscreen settings
Attachments:
[[http://www.pygame.org/old_bug_attachments/10/test_buffer.py| test_buffer.py]]
== illume, 2008-05-26 16:37:19 -0700
Hi,
I think this bug should be reported to SDL and synergy bug trackers.
cu,
== Thorbrian, 2008-05-26 18:06:14 -0700
link to synergy bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1973818&group_id=59275&atid=490467
== Thorbrian, 2008-05-26 21:25:46 -0700
link to SDL bug:
http://bugzilla.libsdl.org/show_bug.cgi?id=590
== illume, 2009-05-27 00:58:35 -0700
No activity from either synergy or sdl at their respective given bug report links.
2009-05-27
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Closing as wontfix. It is a synergy bug according to the SDL bug tracker.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== John, 2010-05-09 21:11:41 -0700
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.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Marking as an enhancement proposal.
It would be nice to be able to do things like this:
surf.fill('black')
surf.fill('# FFEECCF0')
I've often wanted this feature myself, and others have suggested it before.
This needs some thought, and a lot of testing to see what side effects this could have. Also, we need to decide on scheduling if this is a much wanted feature or not, and how much work it would take to implement/test.
Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):
This request would take significant refactoring, particularly in pygame.base and pygame.color and pygame.pixelarray. The simplest approach is to add '' and '# ' handling to _RGBAFromColorObj. Then anything in Pygame that accepts a color value would also take a string. It would also mean
# !python
pixel_array[...] = 'black'
would be allowed. I recall some objection to that, but if it is not a problem I can tackle this issue.
Lenard
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== James Pettit, 2008-02-17 13:49:18 -0800
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/3/segfault.py| segfault.py]]
== Thorbrian, 2008-02-18 13:46:11 -0800
Marcus committed a fix in rev. 1120 - please confirm and close if it's fixed for you
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: svn (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Aaron Gallagher, 2008-04-25 23:33:51 -0700
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.
== Aaron Gallagher, 2008-04-26 14:46:03 -0700
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/9/pygametest.zip| pygametest.zip]]
== illume, 2008-05-02 16:10:53 -0700
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,
== Aaron Gallagher, 2008-05-02 16:38:00 -0700
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.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Jens Rantil, 2008-01-25 10:24:59 -0800
Created attachment 2
Patch against SVN.
The DisplayModes tutorial contains a small typo.
Attachments:
[[http://www.pygame.org/old_bug_attachments/2/DisplayModes.html.diff| DisplayModes.html.diff]]
== Thorbrian, 2008-01-25 23:30:12 -0800
fixed in svn 1088
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: svn (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Peter Enzerink, 2008-03-08 21:31:35 -0800
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.
== Peter Enzerink, 2008-03-08 21:32:30 -0800
Created attachment 7
Patch to add macports paths
Attachments:
[[http://www.pygame.org/old_bug_attachments/7/macports.diff| macports.diff]]
== Thorbrian, 2008-03-09 20:24:54 -0700
committed 1151. Peter, please confirm it works for you now and close bug if it does.
== Peter Enzerink, 2008-03-09 21:48:53 -0700
All good. One step closer to making pygame a little easier on mac.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== , 2008-10-10 22:05:31 -0700
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.
== James Paige, 2008-10-15 08:34:04 -0700
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=
== illume, 2009-05-26 02:03:43 -0700
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,
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Jens Restemeier, 2009-09-08 12:09:36 -0700
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,
Attachments:
[[http://www.pygame.org/old_bug_attachments/28/pngtest.py| pngtest.py]]
== Jens Restemeier, 2009-09-08 12:10:43 -0700
Created attachment 29
PNG test image produced on MacOS powerpc
Attachments:
[[http://www.pygame.org/old_bug_attachments/29/test.png| test.png]]
== Jens Restemeier, 2009-09-08 12:11:31 -0700
Created attachment 30
TGA test image produced on MacOS powerpc - this is how it should look like.
Attachments:
[[http://www.pygame.org/old_bug_attachments/30/test.tga| test.tga]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Thanks Jens.
Here is the test code inline the comment to make it easier to see.
import pygame, os
from pygame.locals import *
# Set SDL to use the dummy NULL video driver,
# so it doesn't need a windowing system.
os.environ["SDL_VIDEODRIVER"] = "dummy"
if True:
# Some platforms need to init the display for some parts of pygame.
import pygame.display
pygame.display.init()
screen = pygame.display.set_mode((1,1))
def main():
test = pygame.Surface((256, 256), flags=SRCALPHA, depth=32)
for y in xrange(256):
for x in xrange(256):
test.set_at((x, y), (x,y,(x + y) % 256, (((x ^ y) >> 4) & 1) * 127 + 128))
for ext in ["tga", "png", "bmp", "jpg"]:
pygame.image.save(test, "test.%s" % ext)
if __name__ == "__main__":
main()
It seems the set_at() call does some bit fiddling, which I'm weary of.
Also need to confirm this fails on PPC, which I don't have access too test on.
The test could be changed to read the lossless formats like tga, png and bmp to make sure they read back the colours correctly. Then this could be used as a unit test easily.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Fixed SDL_BIG_ENDIAN bug for png write. Fixes and closes # 39
Original comment by Olivier Pirson (Bitbucket: OPiMedia, GitHub: OPiMedia):
I have the same problem (save PNG reverse channels) with this configuration:
It's ok with:
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Merged in OPiMedia/pygame (pull request # 30)
Bug fix: Red and green channels inversion on AMD 64 (see issue # 39).
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Bug fix: Red and green channels inversion on AMD 64 (see issue # 39).
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Merged in OPiMedia/pygame (pull request # 30)
Bug fix: Red and green channels inversion on AMD 64 (see issue # 39).
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== 3TATUK, 2009-04-25 01:59:13 -0700
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)
== 3TATUK, 2009-04-25 01:59:50 -0700
Created attachment 21
colors lost
Attachments:
[[http://www.pygame.org/old_bug_attachments/21/example.py| example.py]]
== 3TATUK, 2009-04-25 02:45:35 -0700
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
== 3TATUK, 2009-04-25 02:46:22 -0700
Created attachment 22
hackish workaround
Attachments:
[[http://www.pygame.org/old_bug_attachments/22/example2.py| example2.py]]
== Thorbrian, 2009-04-26 12:21:47 -0700
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.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== OsamaK, 2008-10-02 19:37:41 -0700
FrozenPUZZLE source code <http://up.servut.us/dl/8830> is unavailable. It should be removed or new source code link added.
== James Paige, 2008-10-03 10:03:36 -0700
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
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Lenard Lindstrom, 2008-12-16 19:09:42 -0800
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.
== Lenard Lindstrom, 2008-12-16 20:26:49 -0800
Possible fix in SVN rev. 1750
Passes for Python 2.5; needs Python 2.6 test.
== Lenard Lindstrom, 2008-12-23 16:28:24 -0800
Fixed in revision 1750
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: svn (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== , 2010-07-27 00:48:14 -0700
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))
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
This is fixed in tip.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Saul Spatz, 2008-06-29 12:01:01 -0700
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.
== Thorbrian, 2008-06-29 22:32:25 -0700
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.
== Thomas Ibbotson, 2009-03-26 04:44:53 -0700
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.
== illume, 2009-05-27 00:40:58 -0700
Updated the documentation for this.
Committed revision 2268.
cheers!
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== James Paige, 2008-12-10 12:13:22 -0800
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
Attachments:
[[http://www.pygame.org/old_bug_attachments/14/test.py| test.py]]
== James Paige, 2008-12-10 12:14:28 -0800
Created attachment 15
kitten.jpg used by the test script
Attachments:
[[http://www.pygame.org/old_bug_attachments/15/kitten.jpg| kitten.jpg]]
== James Paige, 2008-12-10 12:14:54 -0800
Created attachment 16
alpha_corner.png used by the test script
Attachments:
[[http://www.pygame.org/old_bug_attachments/16/alpha_corner.png| alpha_corner.png]]
== James Paige, 2008-12-10 12:15:20 -0800
Created attachment 17
The entire test in a zip file
Attachments:
[[http://www.pygame.org/old_bug_attachments/17/alphatest.zip| alphatest.zip]]
== James Paige, 2008-12-11 08:23:19 -0800
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()
== Lenard Lindstrom, 2009-02-11 22:35:41 -0800
I believe rev. 1923 fixes this bug. However, it should be verified on a Mac.
== James Paige, 2009-02-12 11:24:32 -0800
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.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== saehoon, 2009-09-05 01:10:23 -0700
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.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Needs testing with python 3.2. python 3.1 is considered obsolete by python.org and by us.
pygame.mixer.Channel.play(Sound) is not a correct way to call the method. However, maybe that was just short hand.
Here is a test case:
import pygame, pygame.examples, time, os
pygame.init()
main_dir = os.path.split(os.path.abspath(pygame.examples.__file__))[0]
data_dir = os.path.join(main_dir, 'data')
a_sound = pygame.mixer.Sound(os.path.join(data_dir, "whiff.wav"))
c = pygame.mixer.Channel(1);
c.play(a_sound)
time.sleep(3)
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Has been tested on windows. So marking as invalid.
Please reopen if you can supply a complete test case showing the problem.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== John Krukoff, 2008-03-05 13:25:30 -0800
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.
== Thorbrian, 2008-03-05 14:54:58 -0800
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
== Thorbrian, 2008-04-14 17:13:51 -0700
1.8 has been released, and has this problem fixed in it.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Thorbrian, 2008-02-22 21:23:50 -0800
originally reported by inahe to the mailing list.
attached is a script that reproduces the problem.
== Thorbrian, 2008-02-22 21:24:35 -0800
Created attachment 4
Test case
Attachments:
[[http://www.pygame.org/old_bug_attachments/4/CursorColorSwap.py| CursorColorSwap.py]]
== illume, 2009-05-27 00:56:50 -0700
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
== Chaitanya Talnikar, 2010-03-29 05:32:01 -0700
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.
== Chaitanya Talnikar, 2010-03-29 05:44:41 -0700
Created attachment 32
Patch for cursors.py
Attachments:
[[http://www.pygame.org/old_bug_attachments/32/cursors.patch| cursors.patch]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
cursors.compile got black and white mixed up for making cursors.
Thanks to Chaitanya Talnikar for the patch.
Fixes # 8
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: svn (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Ed Blake, 2008-08-01 11:44:03 -0700
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.
== Thorbrian, 2008-08-02 21:34:40 -0700
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).
== Lenard Lindstrom, 2009-01-29 16:35:57 -0800
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.
== Lenard Lindstrom, 2009-02-13 17:49:40 -0800
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/19/test.py| test.py]]
== Lenard Lindstrom, 2009-02-13 18:06:03 -0800
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.
== Lenard Lindstrom, 2009-02-22 22:14:03 -0800
colorkey self blit support finished in rev 1953.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Nick Irvine, 2008-04-11 04:52:11 -0700
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/8/imageext.c| imageext.c]]
== Nick Irvine, 2008-04-11 04:53:28 -0700
By the way, this is one of my first patches ever, so comments on the way I've submitted it are welcome.
== Thorbrian, 2008-04-12 13:58:26 -0700
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)
== Nick Irvine, 2008-04-13 02:13:53 -0700
I actually did create a diff, but attached the wrong file. D'oh!
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Håkan Johansson, 2008-06-30 02:52:10 -0700
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())'.
== Thorbrian, 2008-07-01 01:43:42 -0700
committed 1441, thanks Hakan!
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== , 2009-11-22 22:59:45 -0800
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/31/error.txt| error.txt]]
== , 2009-11-22 23:02:18 -0800
png works fine by the way.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Hello,
yeah, png files or jpeg files should be used.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== A.C.Heron, 2009-08-13 15:28:22 -0700
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.
== A.C.Heron, 2009-08-13 15:33:06 -0700
Created attachment 26
Program output after a crash
Attachments:
[[http://www.pygame.org/old_bug_attachments/26/fonty-output.txt| fonty-output.txt]]
== A.C.Heron, 2009-08-13 15:34:31 -0700
Created attachment 27
Output of "strace python fonty.py"
Attachments:
[[http://www.pygame.org/old_bug_attachments/27/fonty-strace.txt| fonty-strace.txt]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Hi,
this needs testing by a gentoo user.
python -m pygame.examples.fonty
Original comment by Anonymous:
Well, there seems to be some catch here.
My pygame is a bit out of date, as it's still 1.9.1, even though that version went out of the tree awhile ago.
However, if I take fonty.py straight out of the old tarball, I'm unable to reproduce the crash.
Though my system differs significantly from one in the original report:
x86, python-2.7.2-r2, freetype-2.4.6, llibsdl-1.2.14-r6, sdl-ttf-2.0.10.
Though I've seen the post on the mailing list from a user that could reproduce it.
However, pygame-1.9.2_pre3082, that's now in the tree, is a quite recent addition, so I should be able to reproduce, if it were still possible.
Given certain bug, glibc version might matter here - my tests are on 2.13-r4 (the revision will be significant here, if it's that bug).
Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):
This looks like the issue I had with [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594824|SDL_ttf 2.0.9 on Debian squeeze]]. It was fixed in [[http://hg.libsdl.org/SDL_ttf/rev/0f803b00e43b|SDL_ttf 2.0.10]].
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Can't reproduce. Looks like it's an old SDL_ttf bug like Lenard says... so closing.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== , 2009-04-15 21:42:14 -0700
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
== illume, 2009-05-27 00:44:41 -0700
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,
== Pygame XP, 2011-03-25 06:38:46 -0700
(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
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
import os
os.environ['SDL_VIDEODRIVER']='windib'
I think maybe we should finally switch to windib being the default even on XP. We could try some complicated scheme to try to init the display with directx first in a separate process and if that fails we try windib... but I guess that might be failure prone too.
Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):
The SDL Direct X driver is unreliable. 'windib' is the SDL default. How 'directx' behaves probably depends on which version of Direct X is installed. It would seem Microsoft has given up maintaining compatibility with Direct X 5.
Original comment by Anonymous:
Its a miracle! lol thanks illume for the code! I had issues getting my game working using the pygame library, and this fixed it!
Original comment by Anonymous:
**i was having the same problem too, can somebody help me out, i was working for a pygame project, a lil bit explanation for me to understand it well.. plzzzzz and thanks!!
Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):
I think it's time to make windib the default renderer for Windows XP. With that change, we'll be able to close this issue. In my opinion, the productivity losses due to directx renderer bugs outweigh the performance advantage of the directx renderer on some hardware.
Complicated try-directx-except-windib logic would not be a good idea because sometimes after the directx renderer fails, only a system reboot can restore the PC to proper working order.
http://article.gmane.org/gmane.comp.python.pygame/17527/match=%22system%20reboot%20cleared%22
This is how I think the renderer-choosing logic should work:
Windows 95/98/Me without DirectX 5 or greater → windib
Windows 95/98/Me with DirectX 5 or greater → directx
Windows NT/2000/XP/Vista/7/8... → windib
I'll implement the change if @illume doesn't object to my approach.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Sounds good to me :)
Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):
I have changed pygame/_ init _.py so that windib is the default video driver for almost all Windows users.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Lenard Lindstrom, 2008-10-22 13:31:06 -0700
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'
Attachments:
[[http://www.pygame.org/old_bug_attachments/13/array_bug.py| array_bug.py]]
== Lenard Lindstrom, 2009-01-22 01:28:17 -0800
Fixed in SVN revision 1851.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Robert A. Lerche, 2009-03-29 13:20:17 -0700
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/20/pygame-patch| pygame-patch]]
== Thorbrian, 2009-04-26 12:28:25 -0700
Rene, you use Linux right? can you confirm the patch?
== illume, 2009-07-12 23:36:47 -0700
Committed revision 2504.
cheers!
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Devin Jeanpierre, 2008-05-26 00:11:47 -0700
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.
== Devin Jeanpierre, 2008-05-26 00:13:36 -0700
Created attachment 11
Test case as shown in bug report
Attachments:
[[http://www.pygame.org/old_bug_attachments/11/pygametest.py| pygametest.py]]
== Thorbrian, 2008-05-26 12:23:02 -0700
fixed rev. 1248 - the crash was happening on any jpeg or png save error, actually, thanks for catching it
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Sridhar Ratnakumar, 2009-07-24 17:50:35 -0700
> 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 ....'"
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
The config system should probably exit with an error code if it can not find the required dependencies. I'm not sure what affect this would have on various build systems, since it is quite a change. However, I think it probably should be a hard fail if the dependencies can not be found.
I think this would make it easier on people to notice that they have forgotten to install a dependency.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Exit with status 1 if sdl-config missing
sys.exit() with a message == print the message and exit with code 1.
Raising SystemExit also works, but it only gives code 1 if it has a message.
Closes # 35
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Paul "TBBle" Hampson, 2008-08-31 06:23:39 -0700
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/12/msysdetect.patch| msysdetect.patch]]
== Lenard Lindstrom, 2008-08-31 20:45:18 -0700
Thanks for the report.
Fixed in SVN revision 1644
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== , 2009-04-14 12:31:07 -0700
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;
}
== illume, 2009-05-26 01:55:25 -0700
Thanks Tom!
Committed revision 2259.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Thorbrian, 2008-02-22 23:33:40 -0800
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)
Attachments:
[[http://www.pygame.org/old_bug_attachments/5/bouncey.zip| bouncey.zip]]
== illume, 2008-03-05 14:08:52 -0800
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.
== Thorbrian, 2008-03-16 22:39:06 -0700
has this been submitted to SDL_mixer?
== illume, 2008-05-02 16:18:56 -0700
The bug has been reported to SDL.
== Lenard Lindstrom, 2009-02-12 13:30:26 -0800
Still not fixed as of rev. 4211 (Mon Dec 8 00:27:32 2008 UTC).
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
This is an sdl_mixer bug that has been reported. Closing.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: svn (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== John, 2010-05-19 10:59:30 -0700
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.
Original comment by Anonymous:
Hi,
Same here!
I am using python 2.7 (from Enthought) on mac os x 10.7. While installation I did receive some of the warnings, such as
ld: warning: ignoring file build/temp.macosx-10.5-i386-2.7/src/mouse.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: ignoring file /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks//SDL.framework/SDL, missing required architecture x86_64 in file
simply because I am force building it for i386 arch configuration, which doesn't exist on Lion :(.
Any ways, after installation, importing pygame creates the following crash messages:
$ python
Enthought Python Distribution -- www.enthought.com
Version: 7.1-2 (64-bit)
Python 2.7.2 |EPD 7.1-2 (64-bit)| (default, Jul 27 2011, 14:50:45)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "packages", "demo" or "enthought" for more information.
>>> import pygame
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Frameworks/EPD64.framework/Versions/7.1/lib/python2.7/site-packages/pygame/__init__.py", line 95, in <module>
from pygame.base import *
ImportError: dlopen(/Library/Frameworks/EPD64.framework/Versions/7.1/lib/python2.7/site-packages/pygame/base.so, 2): Symbol not found: _SDL_EnableUNICODE
Referenced from: /Library/Frameworks/EPD64.framework/Versions/7.1/lib/python2.7/site-packages/pygame/base.so
Expected in: dynamic lookup
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Hi,
I think your error is slightly different. Your issue is likely because you are using an SDL that does not support Lion. Only the latest hg SDL supports Lion. There are some more changes due to be merged into SDL tip sometime this week or next.
I put up a build for the apple python2.7 that comes with Lion here: http://rene.f0o.com/~rene/stuff/pygame-1.9.2pre-py2.7-macosx10.7.mpkg.zip
It probably won't help with your build of python though.
Maybe by next week SDL will be in better shape on Lion, and they might release new binaries. If not I'll put some together with what they have.
Original comment by Anonymous:
Hi illime,
Thanks a lot :). The link to the pkg seems broken, though.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Hello,
there are some new OSX binaries listed on the pygame.org page.
http://pygame.org/download.shtml
There are also install instructions there if you use the homebrew package manager.
It would be good to know if any of them work for you?
cheers,
Original comment by Elena Williams (Bitbucket: elequ, GitHub: elequ):
Hi there!
I just had experienced this issue and can confirm the following behavior:
My pip installation of pygame installation worked but didn't fully support SDL:
Test results:
Framework SDL found
Framework SDL_ttf not found
Framework SDL_image not found
Framework SDL_mixer not found
So I reinstalled SDL 1.2.15 and PyGame 1.9.1 from source, now SDL support was complete:
Hunting dependencies...
Framework SDL found
Framework SDL_ttf found
Framework SDL_image found
Framework SDL_mixer found
It was at this point I experienced the following error:
# !python
Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
>>> import pygame
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Python/2.7/site-packages/pygame/__init__.py", line 95, in <module>
from pygame.base import *
ImportError: dlopen(/Library/Python/2.7/site-packages/pygame/base.so, 2): Symbol not found: _SDL_EnableUNICODE
Referenced from: /Library/Python/2.7/site-packages/pygame/base.so
Expected in: flat namespace
in /Library/Python/2.7/site-packages/pygame/base.so
I came across this post and installed the OSX binary posted above:
http://rene.f0o.com/~rene/stuff/pygame-1.9.2pre-py2.7-macosx10.7.mpkg.zip
It's now working correctly! Thank you!
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Closing this issue because it's got a bunch of unrelated errors in here.
There are other issues opened already because of the various problems listed in here.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Uriy Zhuravlev, 2009-05-30 09:16:49 -0700
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.
== Uriy Zhuravlev, 2009-05-30 12:53:37 -0700
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. :(
Attachments:
[[http://www.pygame.org/old_bug_attachments/23/pygame_music| pygame_music]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
You can set an environment variable as SDL_VIDEODRIVER=dummy which will make the system work if you don't have video on your system.
I'm not sure what the patch is, or if you need it any more. Sorry this bug took so long to answer. Please reopen bug if you are still interested in having the patch applied.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Robin Allen, 2008-01-17 01:57:02 -0800
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").
== illume, 2008-05-02 16:20:49 -0700
I don't have a euro sign on my keyboard to test this.
== jmm0, 2010-12-02 06:31:07 -0800
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
== Herman Chau, 2010-12-20 04:08:06 -0800
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
== Dávid Gábor Bodor, 2011-07-24 02:51:24 -0700
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.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Marking as resolved as no one else can reproduce this problem.
Please reopen the issue if the issue still exists. Also, if reopening please report information about OS version keyboard type, and as much other information you can think of.
thanks!
Originally reported by: Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom)
Posted to [email protected] by René Dudfield on Aug. 4, 2011:\
\
Subject: transition plan was Re: [pygame] contemplating move to bitbucket(and hg). what do you think?\
\
Hi,
\
I've started on a migration plan for bitbucket. If anyone has any feedback, please let me know :) \
\
They will be done in roughly the order written.\
\
\
** 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.
take changes from hg instead of svn.
** 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
on bitbucket
download page, and group them by OS.
** instructions on hg, and submitting patches. As well as writing
docs.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
hg repository migrated.
Started work on bugzilla bug migration tool.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Making the tool here:
https://bitbucket.org/illume/bugzilla_bitbucket/
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
The issues are migrated.
The following still need to be done:
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
The wiki has been converted a while ago.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
The buildbot part of this has moved to isssue # 111
TODO:
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
'download syncing to /ftp' has been given an issue in # 152
website generation from wiki has been given an issue in # 153
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Closing this. All of the tasks have either been done or have issues tracking them.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Arnau Sanchez, 2010-05-19 11:22:25 -0700
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
Related Docs: https://www.pygame.org/docs/ref/image.html# pygame.image.save
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
This is a good idea.
I've marked this as something for pygame 1.9.2.
Thanks!
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Travis Rose, 2008-01-26 07:51:04 -0800
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
== Thorbrian, 2008-01-26 19:18:55 -0800
Travis - can you please attach a test case? a midi file and python script?
== illume, 2008-02-04 21:33:46 -0800
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
== illume, 2008-05-02 16:27:37 -0700
This bug has been submitted to sdl.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Setting as wontfix, since it is an SDL bug, that has been reported.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Adam Williamson, 2008-12-12 17:33:48 -0800
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.
== James Paige, 2008-12-12 19:20:16 -0800
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/18/pygame-1.8.1release.tar.gz| pygame-1.8.1release.tar.gz]]
== Thorbrian, 2008-12-14 11:59:08 -0800
Rene, did you make the original tarball? Can you check out James' fixed version and upload it if it's good?
thanks!
== illume, 2009-05-25 15:16:14 -0700
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,
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== , 2010-03-31 04:33:04 -0700
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/33/TestMemoryLeak.py| TestMemoryLeak.py]]
== Jonathan Berry, 2010-05-28 09:49:35 -0700
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.
== Marco Lettere, 2010-12-03 03:44:53 -0800
Jpeg is stable as BMP.
PNG is causing memory leak also for me (AMD SMP 64 BIT - Ubuntu 10.04, pygame 1.9.1)
== Winston Ewert, 2011-02-14 12:01:50 -0800
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.
Attachments:
[[http://www.pygame.org/old_bug_attachments/38/png_leak.patch| png_leak.patch]]
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
Fixes # 43. Memory leak in pygame.image.save with png files,
in the imageext.c write_png function.
Thanks Winston Ewert for the patch.
Thanks Jonathan Berry, and Marco Lettere for work on the bug.
Original comment by Pehat (Bitbucket: Pehat, GitHub: Pehat):
Thank you for the fix, now it works properly.
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
== Alexandre Quessy, 2010-01-03 16:33:25 -0800
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
== Alexandre Quessy, 2010-01-03 19:34:16 -0800
This is fixed once I have installed http://www.python.org/ftp/python/2.5/python-2.5-macosx.dmg
This should be documented.
Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):
This has been documented on the download page now.
It would be nice to fix it in the installer too... but I think the download 'solves' the issue mostly.
Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):
Removing version: unspecified (automated comment)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.