Hi Lenard,

But are there any situations where one MUST have 3 elements colors only? If
not, then just fill in a reasonable default value for times when there isn't
an alpha value for the picture.

-Tyler

On Wed, Jun 17, 2009 at 9:31 AM, Lenard Lindstrom <[email protected]> wrote:

> Hi Tyler,
>
> Well, one wants 4 element colors when working with per-pixel-alpha
> surfaces.
>
> Lenard
>
>
> Tyler Laing wrote:
>
>> Why don't we just fill in a full value of 255 for all the cases where it
>> returns 3 values? If we make every call return four values, and warn about
>> this in the documentation, it becomes very consistent.
>>
>> -Tyler
>>
>> On Tue, Jun 16, 2009 at 11:52 PM, Lenard Lindstrom <[email protected]<mailto:
>> [email protected]>> wrote:
>>
>>    René Dudfield wrote:
>>
>>        On Wed, Jun 17, 2009 at 4:29 PM, Lenard
>>        Lindstrom<[email protected] <mailto:[email protected]>> wrote:
>>
>>            René Dudfield wrote:
>>
>>                Hi,
>>
>>                one issue with the new Color type is unpacking to
>>                r,g,b or r,g,b,a.
>>
>>                In some places Color is assumed to return (r,g,b) and
>>                others
>>                (r,g,b,a), and now many things return a Color rather
>>                than a tuple.
>>
>>                So I want to change Color to unpack to r,g,b,a or r,g,b.
>>
>>                r,g,b = pygame.Color(1,2,3,4)
>>                r,g,b,a = pygame.Color(1,2,3,4)
>>
>>                Anyone have an idea how this can work?  Either in C or
>>                python?
>>
>>                This is to keep backwards compatibility.
>>
>>
>>                cheers,
>>
>>
>>            Hi René,
>>
>>            Are there cases where this is breaking code? For the most
>>            part I believe
>>            Pygame functions returned 4-tuples. So Color is just
>>            pretty much a drop-in
>>            replacement. If a program is using tuples to declare color
>>            values then the
>>            size is already known and unpacking is not a problem. It is
>>            Surface.get_palette and get_palette_at, which originally
>>            returned 3-tuples,
>>            where we run into problems. So here are the choices I see.
>>            One, just accept
>>            that the new get_palette and get_palette_at will break
>>            things, just as any
>>            program that tries to use a color return value as a
>>            dictionary key will now
>>            break. How many programs actually use color palettes
>>            anyway? Two, give Color
>>            a size property. If alpha is set None it becomes length 3.
>>            But then how does
>>            one represent this internally without adding another field
>>            to the Color C
>>            structure? Declare the color component values as C ints?
>>            Three, create a new
>>            Color subtype of length 3 having a fixed alpha of 255. I'm
>>            not happy with
>>            any of the choices but prefer three. Any other ideas?
>>
>>            Lenard
>>
>>
>>
>>
>>        hi,
>>
>>        yeah for example in solarwolf:
>>         File "solarwolf-1.5/code/gamemenu.py", line 70, in
>>        load_game_resources
>>           pal = [(g,g,b) for (r,g,b) in origpal]
>>
>>         File "solarwolf-1.5/code/objshot.py", line 28, in
>>        load_game_resources
>>           for (r,g,b) in origpal]
>>
>>
>>        hrmm.  I think a 3 element Color subtype might be the way to go.
>>        Maybe we don't even need a subtype, but just a length property
>>        that
>>        can be 1,2,3, or 4?  As you say get_palette(_at) could return
>>        len 3
>>        Colors.
>>
>>        If it could unpack to 3, or 4 depending on the number of
>>        elements on
>>        the left, I think I'd prefer that though.
>>
>>
>>
>>
>>    Hi,
>>
>>    Well yes, but now you are have something that is basically an
>>    integer array, including the additional overhead.
>>
>>
>


-- 
Visit my blog at http://oddco.ca/zeroth/zblog

Reply via email to