Re: [pygame] Re: rendering anti-alias in argument color with transparency

[Aaron Brady <castironpi@xxxxxxxxx>]

On Fri, Aug 26, 2011 at 7:41 AM, René Dudfield <renesd@xxxxxxxxx> 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 <castironpi@xxxxxxxxx> wrote:
>>
>> On Aug 26, 6:34 am, René Dudfield <ren...@xxxxxxxxx> 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?

> 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.