[pygame] 1.9.2 alpha 0 crash on Windows
Hi, I'm testing http://pygame.org/ftp/pygame-1.9.2a0.win32-py3.2.msi for Windows. It's seriously broken. It crashes with the parachute 15-30 seconds in to the program, especially when I switch apps to or away from it. I'm using Windows XP Home with current SP's and updates. Is there a separate mailing list for bugs? Thanks.
Re: [pygame] Possible to detect collision with an image?
In that example, you need to detect a collision with any one of two triangles or a circle, excluding the other two. That could be a useful function; it's not on the wiki. Is that enough information? Or, there are some strategies for only checking collisions with nearby objects, if you need an optimization, that are on the wiki. Are they adequate? On Fri, Oct 7, 2011 at 4:51 PM, Florian Krause wrote: > Well, you could make the background of the image transparent and then > create a mask fro the pygame surface. This one can be checked for > collisions. > > Florian > > > > On Fri, Oct 7, 2011 at 11:44 PM, Alec Bennett wrote: >> I'm using an image with transparency as a Sprite. The image has an irregular >> shape: >> >> http://sinkingsensation.com/stuff/shape.png >> >> I'd like to detect collisions with it. >> >> My current strategy is to draw a polygon (pygame.draw.polygon) behind the >> image. That works, but its difficult to make the polygon accurately reflect >> the image, and I need to make a lot of them. >> >> So I'm wondering if there's some way to detect collisions with the image >> itself? >> >> Or maybe there's some clever way to draw a polygon based on an image? >> >> I don't need pixel-by-pixel accuracy, anything close would work. >> >> >> >> > > > > -- > www.fladd.de - fladd.de: Homepage of Florian Krause > blog.fladd.de - fladd's Blog: Blog of Florian Krause > intermezzo.fladd.de - Intermezzo: Music by Florian Krause and Giacomo Novembre >
Re: [pygame] rendering anti-alias in argument color with transparency
On Fri, Aug 26, 2011 at 12:11 PM, Lenard Lindstrom wrote: > On 26/08/11 04:25 AM, Aaron Brady wrote: >> >> I'd like to know if anti-aliased objects, in particular the edges of >> lines and fonts, can be rendered using transparency instead of >> directly blended colors. Specifically, can the function calls draw 4- >> tuples of ( r, g, b ) specified in the arguments, plus + ( a, ), the >> proportion of intensity determined by the drawing algorithm? >> >> > Hi, > > Font.render returns a per-pixel alpha surface with transparency if no > background color is given. > > Lenard Lindstrom > > I stand corrected on that count. Perhaps we could use the same strategy on the rest of the drawing methods, namely return a new Surface for every primitive rendered.
Re: [pygame] Re: rendering anti-alias in argument color with transparency
On Fri, Aug 26, 2011 at 7:41 AM, René Dudfield wrote: > Hey, > > Can you try doing a fill to your surface first? > > > I guess it's likely a bug in the drawing code. > > Here is the wrapper source for the circle function... > > https://bitbucket.org/pygame/pygame/src/427a9ac7bd91/src/gfxdraw.c#cl-404 > > and here is the C code... > > https://bitbucket.org/pygame/pygame/src/427a9ac7bd91/src/SDL_gfx/SDL_gfxPrimitives.c > > > > > On Fri, Aug 26, 2011 at 2:15 PM, Aaron Brady wrote: >> >> On Aug 26, 6:34 am, René Dudfield wrote: >> [snip] >> > > I'd like to know if anti-aliased objects, in particular the edges of >> > > lines and fonts, can be rendered using transparency instead of >> > > directly blended colors. Specifically, can the function calls draw 4- >> > > tuples of ( r, g, b ) specified in the arguments, plus + ( a, ), the >> > > proportion of intensity determined by the drawing algorithm? >> > >> > > The trick can of course be accomplished with 'numpy', the numerics >> > > package, but it is a heavyweight solution, in particular complicated >> > > and distracting, where programmer time is scarce; and slower, where >> > > run-time environment CPU time is scarce. >> > >> > Hey, >> > >> > have you tried out the gfxdraw package? That's got some antialiased >> > drawing >> > functions. >> >> Hi, thanks for the fast reply. >> >> Yes, the 'bezier_motion' screenshot used the bezier method in >> gfxdraw. I wouldn't mind seeing a filled pie, though. I used an >> approximation to accomplish it. >> >> http://home.comcast.net/~castironpi-misc/draggable_pie.1311632054.png >> >> Regarding the anti-aliasing, I ran this code: >> >> >>> import pygame >> >>> pygame.init( ) >> (6, 0) >> >>> scr= pygame.display.set_mode(( 640,480 ) ) >> >>> surf= pygame.Surface((400,400)).convert_alpha( ) >> >>> import pygame.gfxdraw >> >>> pygame.draw.aaline(surf,(0,255,0),(50,100),(150,350)) >> >> >>> pygame.gfxdraw.aacircle(surf,200,250,50,(0,0,255)) >> >>> surf.get_at((52,103)) # on the line >> (0, 102, 0, 0) >> >>> surf.get_at((194,200)) # on the circle >> (0, 0, 162, 103) >> >>> surf.get_at((109,247)) # on the line >> (0, 254, 0, 0) >> >> # part 2, continued >> >>> surf.fill((0,0,0,0)) >> >> >>> pygame.draw.aaline(surf,(0,255,0,255),(50,100),(150,350)) >> >> >>> pygame.gfxdraw.aacircle(surf,200,250,50,(0,0,255,255)) >> >>> surf.get_at((52,103)) >> (0, 102, 0, 102) >> >>> surf.get_at((194,200)) >> (0, 0, 162, 103) >> >>> surf.get_at((109,247)) >> (0, 254, 0, 254) >> >> As you can see, I tried both length-3 and length-4 tuples for the >> color argument. In these examples, the results I want would be: >> >> >>> surf.get_at((52,103)) >> (0, 255, 0, 102) >> >>> surf.get_at((194,200)) >> (0, 0, 255, 103) # or (0, 0, 255, 162), unclear >> >>> surf.get_at((109,247)) >> (0, 255, 0, 254) >> >> Does this help to clarify? > Can you try doing a fill to your surface first? That was the purpose of the part 2 (continued) section. It had different results but not the expected results. Looking in 'int _putPixelAlpha': https://bitbucket.org/pygame/pygame/src/427a9ac7bd91/src/SDL_gfx/SDL_gfxPrimitives.c#cl-399 R = ((dc & Rmask) + (color & Rmask) - (dc & Rmask)) >> Rshift) * alpha >> 8) << Rshift)) & Rmask; It is probably a pretty fundamental call, so I'm hesitant to conclude that it is the culprit. However, it's not obvious that the colors should be multiplied by the alpha, as well as the alpha set, in 32-bit mode.
[pygame] Re: rendering anti-alias in argument color with transparency
On Aug 26, 6:34 am, René Dudfield wrote: [snip] > > I'd like to know if anti-aliased objects, in particular the edges of > > lines and fonts, can be rendered using transparency instead of > > directly blended colors. Specifically, can the function calls draw 4- > > tuples of ( r, g, b ) specified in the arguments, plus + ( a, ), the > > proportion of intensity determined by the drawing algorithm? > > > The trick can of course be accomplished with 'numpy', the numerics > > package, but it is a heavyweight solution, in particular complicated > > and distracting, where programmer time is scarce; and slower, where > > run-time environment CPU time is scarce. > > Hey, > > have you tried out the gfxdraw package? That's got some antialiased drawing > functions. Hi, thanks for the fast reply. Yes, the 'bezier_motion' screenshot used the bezier method in gfxdraw. I wouldn't mind seeing a filled pie, though. I used an approximation to accomplish it. http://home.comcast.net/~castironpi-misc/draggable_pie.1311632054.png Regarding the anti-aliasing, I ran this code: >>> import pygame >>> pygame.init( ) (6, 0) >>> scr= pygame.display.set_mode(( 640,480 ) ) >>> surf= pygame.Surface((400,400)).convert_alpha( ) >>> import pygame.gfxdraw >>> pygame.draw.aaline(surf,(0,255,0),(50,100),(150,350)) >>> pygame.gfxdraw.aacircle(surf,200,250,50,(0,0,255)) >>> surf.get_at((52,103)) # on the line (0, 102, 0, 0) >>> surf.get_at((194,200)) # on the circle (0, 0, 162, 103) >>> surf.get_at((109,247)) # on the line (0, 254, 0, 0) # part 2, continued >>> surf.fill((0,0,0,0)) >>> pygame.draw.aaline(surf,(0,255,0,255),(50,100),(150,350)) >>> pygame.gfxdraw.aacircle(surf,200,250,50,(0,0,255,255)) >>> surf.get_at((52,103)) (0, 102, 0, 102) >>> surf.get_at((194,200)) (0, 0, 162, 103) >>> surf.get_at((109,247)) (0, 254, 0, 254) As you can see, I tried both length-3 and length-4 tuples for the color argument. In these examples, the results I want would be: >>> surf.get_at((52,103)) (0, 255, 0, 102) >>> surf.get_at((194,200)) (0, 0, 255, 103) # or (0, 0, 255, 162), unclear >>> surf.get_at((109,247)) (0, 255, 0, 254) Does this help to clarify?
[pygame] rendering anti-alias in argument color with transparency
Hello, I've done a lot of pygame. http://home.comcast.net/~castironpi-misc/pathfinding.1314246907.png http://home.comcast.net/~castironpi-misc/raster.1313242414.png http://home.comcast.net/~castironpi-misc/bezier_motion.1291142199.png And some including C extensions. http://home.comcast.net/~castironpi-misc/draw.1311647621.png I'd like to know if anti-aliased objects, in particular the edges of lines and fonts, can be rendered using transparency instead of directly blended colors. Specifically, can the function calls draw 4- tuples of ( r, g, b ) specified in the arguments, plus + ( a, ), the proportion of intensity determined by the drawing algorithm? The trick can of course be accomplished with 'numpy', the numerics package, but it is a heavyweight solution, in particular complicated and distracting, where programmer time is scarce; and slower, where run-time environment CPU time is scarce.
Re: [pygame] draw.line bounding box bug when width>1
On Sun, Oct 11, 2009 at 1:07 PM, Luke Paireepinart wrote: > > > On Sat, Oct 10, 2009 at 10:57 PM, Aaron Brady wrote: >> >> Hello, >> New to the list. >> I have a bug! Nice 'n' easy repro steps below. > > Just FYI, > http://catb.org/~esr/faqs/smart-questions.html#id382249 Ah I see. Too informal and hasty. For the record, I like these parts of this link: "...claim you have found a bug, you'll be impugning their competence, which may offend..." and "...it is best to write as though you assume you are doing something wrong, even if you are privately pretty sure..." Is it appropriate to share what I'm pleased with? > This bug was already addressed in a DOC post in 2005, > http://www.pygame.org/docs/ref/draw.html#pygame.draw.line > I'm not really sure why no one included the patch. I attempted 'inflate', but didn't account for the width. I just tried a range of constants.
[pygame] draw.line bounding box bug when width>1
Hello, New to the list. I have a bug! Nice 'n' easy repro steps below. The bounding box returned by draw.line is the wrong size when width>1. For single occurrence: import pygame pygame.init( ) print pygame.version.ver s= pygame.Surface( ( 20, 20 ) ) rec= pygame.draw.line( s, ( 255,0,0 ), ( 10, 16 ), ( 7, 0 ), 2 ) s.fill( ( 0, 0, 0 ), rec ) print s.get_at( ( 7, 0 ) ) Since the rectangle returned by 'draw' was filled with 0, 'get_at' should return 0. It doesn't. It returns green. I am using WinXP with 1.9.1release-svn2575 and Python2.5. Repro code with random coordinates below: import random as ran import numpy as num s.fill( ( 0, 0, 0 ) ) while 1: x1= ran.randint( 0, 20 ) x2= ran.randint( 0, 20 ) y1= ran.randint( 0, 20 ) y2= ran.randint( 0, 20 ) wid= ran.randint( 1, 2 ) rec= pygame.draw.line( s, ( 255,0,0 ), ( x1, y1 ), ( x2, y2 ), wid ) sorig= pygame.surfarray.array2d( s ) s.fill( ( 0, 0, 0 ), rec ) sa= pygame.surfarray.pixels2d( s ) if num.any( sa ): assert wid> 1 print x1, y1, x2, y2, wid for x, y in zip( *sa.nonzero( ) ): print x, y, s.get_at( ( x, y ) ) sa[ x, y ]= 2 print num.where( sorig, 1, 0 ) s.fill( 1, rec ) print sa print s.fill( ( 0, 0, 0 ) ) Observe that 'wid' is always>1, so the return is correct when wid=1. When 'sa' is printed, it contains '1' throughout the area of the bounding box that 'draw.line' returns. It contains '2' where the pixels of the draw command placed the line.
