Re: [pygame] Introductions and question about transparency

[Jérôme Loisel <jerome@levinux.org>]

Hello again!

I am investigating as we discussed and writing this as I go. You'll know the 
results when I do... or just about. :-)

(Actually, I found a solution. Skip to ***SOLUTION*** if you're tired.)

Pete Shinners -- Lundi 21 Mai 2001 21:36:
> > I thought the same thing at first, so I decided to investigate. The Gimp
> > seems to believe the background is transparent (checkered pattern) and
> > displays some truly-white pixels in some tiles (ie arctic).
>
> ok, it sounds like it is time to investigate this image and SDL_image
> one step further.
>
>     img = pygame.image.load(tile_filename)  #no convert call
>     print 'COLORKEY:', img.get_colorkey()
>

I used the following code:
    bigtile_surface = pygame.image.load(tile_filename)
    print "COLORKEY:", bigtile_surface.get_colorkey()
    bigtile_surface = bigtile_surface.convert()
    print "COLORKEY:", bigtile_surface.get_colorkey()

And here are my results...

tiles.xpm:
COLORKEY: (255, 255, 255, 255)
COLORKEY: (248, 252, 248, 255)

tiles.gif:
COLORKEY: (255, 255, 255, 255)
COLORKEY: (248, 252, 248, 255)

tiles.png:
COLORKEY: None
COLORKEY: None

Something feels wrong with the tiles.png. I just tried re-opening and 
re-saving the file in Gimp, enabling or disabling "Save background color", 
with no changes in my result. Strange.

Okay, I just tried something which mostly worked: I manually set the colorkey 
for each tile, like you suggested, to the reported values before the 
convert().

    # tag is the tile name.
    # coords[tag] = [col, row]
    for tag in coords.keys():
        x, y = coords[tag][0] * dx, coords[tag][1] * dy
        tile = bigtile_surface.subsurface((x, y, dx, dy))
        tile.set_colorkey((255, 255, 255, 255))
        tiles[tag] = tile


***SOLUTION***

I just had a moment of lucidity. The problem, it seems, is not that convert() 
changes the colormap. It is just that the colormap does not carry over into 
the subsurfaces. I verified this by directly blitting bigtile_surface. I saw 
that the transparency was indeed working with the original surface.

I changed my code to the (more generic) following, and it works. (Whew!)

    # tag is the tile name.
    # coords[tag] = [col, row]
    colorkey = bigtile_surface.get_colorkey()
    for tag in coords.keys():
        x, y = coords[tag][0] * dx, coords[tag][1] * dy
        tile = bigtile_surface.subsurface((x, y, dx, dy))
        tile.set_colorkey((255, 255, 255, 255))
        tiles[tag] = tile

So this works flawlessly. But maybe it is not quite intuitive? Do you expect 
to change subsurface()'s behavior?

> > I would really like the image's transparency to work normally, but I did
> > try your advice. I learned a bit doing it too. :-) It did not work
> > immediately, but I remembered your docs and called set_colorkey on the
> > subsurfaces instead. That worked.
>
> doh, i was under the impression subsurfaces would inherit their parent
> surface flags when created, owell, guess again. i'll have too look into
> the pygame code on this one.

Funny, considering you wrote and documented it. :-)

> i'm guessing the real problem is that SDL_image is not using the colorkey
> from XPM files. and i'm hoping the reason it doesn't work with GIF/PNG is
> because gimp wasn't saving them correctly ?

Well, my final solution works with the original tiles.xpm.

Thanks very much for all your help. I'm subscribed now, and working on my 
game, so I'm not going anywhere. You'll hear from me again. :-)

PS: I'm attaching a heavily-cropped screenshot of the final effect. You can 
see how "darkness" tiles partly cover the mountains to show where vision 
ends. This required working transparency.

I would put up a full screenshot somewhere instead, but loisel.org (our 
server) is still down. The image weighs in at 5.6K, so I suppose it's not too 
rude for me to attach it?

-- 
Jérôme Loisel, étudiant et webmestre
Lévinux: GNU/Linux pour la communauté
http://www.levinux.org/

fse3_small.png