[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 siebenhundertz...@gmail.com 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 wrybr...@gmail.com 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
[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.
[pygame] Re: rendering anti-alias in argument color with transparency
On Aug 26, 6:34 am, René Dudfield ren...@gmail.com 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)) rect(50, 100, 102, 252) 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)) rect(0, 0, 400, 400) pygame.draw.aaline(surf,(0,255,0,255),(50,100),(150,350)) rect(50, 100, 102, 252) 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?
Re: [pygame] rendering anti-alias in argument color with transparency
On Fri, Aug 26, 2011 at 12:11 PM, Lenard Lindstrom le...@telus.net 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] draw.line bounding box bug when width1
On Sun, Oct 11, 2009 at 1:07 PM, Luke Paireepinart rabidpoob...@gmail.com wrote: On Sat, Oct 10, 2009 at 10:57 PM, Aaron Brady castiro...@gmail.com 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 width1
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 width1. 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 always1, 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.