Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault (pygame parachute) on blit #19

Closed
illume opened this issue Aug 22, 2011 · 0 comments
Closed

Segfault (pygame parachute) on blit #19

illume opened this issue Aug 22, 2011 · 0 comments
Labels
bug Surface pygame.Surface

Comments

@illume
Copy link
Member

illume commented Aug 22, 2011

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.


@illume illume added trivial bug Surface pygame.Surface labels Mar 26, 2017
@illume illume closed this as completed Mar 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Surface pygame.Surface
Projects
None yet
Development

No branches or pull requests

1 participant