Layers with tiles that have alpha channel

5 views
Skip to first unread message

Sebastian Silva

unread,
Feb 10, 2014, 9:16:38 AM2/10/14
to gummw...@googlegroups.com
Hi Mr Gumm.
I'm enjoying working with your GummWorld2 library.
I am working with Tiled and some of the Liberated PIxel Cup assets in order to build a free game that hopefully will run well on the OLPC XO laptop (and any other computer).
I'm barely a beginner when it comes to pygame and so I haven't been able to figure out why the alpha channel on my initial project's tiles display as a solid grey color.
Please advise.
Greetings from Colombia,
Sebastian

bw

unread,
Feb 10, 2014, 2:48:27 PM2/10/14
to gummw...@googlegroups.com
Hi, Sebastian,

Welcome to pygame and Gummworld2. I can't answer for certain without
seeing the code, and probably running it. My initial guess is that there
is a pygame.surface.Surface.convert() happening somewhere which would
strip the alpha channel from the images.

If you are using the TiledMap class then the loader is
tiledmap._load_tiled_tmx_map(). But there are no convert() calls in there.

If you are using the collapse feature for a performance boost, then look
in basicmap.collapse_layer() where I do see a convert() call. The way it
is done looks okay to me, but it may be causing the unwanted side effect.

If you hit a wall and need more help, I may be able to assist better if
you post the project to an online source control repo that I can pull
from so that I can run your project.

Hope this helps.

Cheers,

Gumm
> --
> You received this message because you are subscribed to the Google
> Groups "Gummworld2" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to gummworld2+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Sebastian Silva

unread,
Feb 14, 2014, 12:07:40 PM2/14/14
to gummw...@googlegroups.com
Hello Gumm
Thanks for getting back to me so soon.
Regrettably I have an intermittent and slow Internet link so I could not
advance with this sooner.
I have managed to upload to github the very rough base I'm working on.
I think the issue is I started out from one of your examples (18.py,
because I found the fog effect quite interesting). But I guess I
should've started out with 07_tiled_map_with_renderer.py.
I will attempt to fix it myself, but any pointers are more than welcome.
The idea is to embed the game within a Renpy visual interactive story
(or somehow integrate the two).
This gives us main menu, story, intro, endings, etc.
Thank you a lot for your hard work.
Hopefully we'll make something fun with/for the kids.
Regards,
Sebastian
PS: The repo is at https://github.com/icarito/sunset-adventure


El 10/02/14 14:48, bw escribió:

bw

unread,
Feb 15, 2014, 3:37:36 AM2/15/14
to gummw...@googlegroups.com
Hi, Sebastian,

There appears to be something strange happening in either Tiled or
pytmxloader. I don't understand why it's happening, but I can give you a
workaround.

1. Find tmxreader.py.
2. Find TileMapParser._set_attributes().
3. Make the body of _set_attributes() look like this...

def _set_attributes(self, node, obj):
attrs = node.attributes
for attr_name in list(attrs.keys()):
# print attr_name,attrs.get(attr_name).nodeValue
if attr_name == 'trans':
continue
setattr(obj, attr_name, attrs.get(attr_name).nodeValue)
self._get_properties(node, obj)

This workaround discards the TMX map's "trans" XML-node value of 808080,
which was later causing tmxloader to set a colorkey in
TileMap.convert(). Setting the colorkey resulted in the grey.

Enjoy.

Gumm

Sebastian Silva

unread,
Feb 21, 2014, 1:20:19 PM2/21/14
to gummw...@googlegroups.com
Hi Gumm,
Thank you a lot for helping me debug the issue.
I decided to simply remove the "trans" property in the XML Tiled file so
that I can use the Gumm library unpatched.
This has allowed me to advance a lot in the development of our little
adventure (still not a full game, sorry).

Now I wonder, for map transitions, I was looking at 23_supermap.py in
examples dir, it seems that it should do what I want,
but doesn't seem to work. Maybe I'm missing something, or I can motivate
you to point me to figure out how the example
should work? I'm also planning to make map transitions on certain events
(character enters door...), but I guess it shouldn't
be too hard to figure that one out myself.

Another thing, in my code I fixed the keyboard input, sometimes if
changing direction too quickly, the character would
stop moving, I think this is because maybe one would press one key
before releasing the other, causing the approach in
the examples to not work correctly. I fixed the issue by processing
pygame.key.get_pressed() for both key_up and key_down
events (see
https://github.com/icarito/sunset-adventure/blob/master/game/runme.py#L361 )

I'm still having lots of fun and hopefully so will the children. I
tested the current version on an OLPC XO1.5 and performance
is quite decent.

Regards and thank you again,
Sebastian


El 15/02/14 03:37, bw escribió:

bw

unread,
Feb 21, 2014, 6:27:07 PM2/21/14
to gummw...@googlegroups.com

On 2/21/2014 10:20, Sebastian Silva wrote:
> Hi Gumm,
> Thank you a lot for helping me debug the issue.
> I decided to simply remove the "trans" property in the XML Tiled file
> so that I can use the Gumm library unpatched.
> This has allowed me to advance a lot in the development of our little
> adventure (still not a full game, sorry).
You're welcome. No need to say sorry. =) Now that you're past the trans
obstacle, the game seems to be coming along nicely.
> Now I wonder, for map transitions, I was looking at 23_supermap.py in
> examples dir, it seems that it should do what I want,
> but doesn't seem to work. Maybe I'm missing something, or I can
> motivate you to point me to figure out how the example
> should work? I'm also planning to make map transitions on certain
> events (character enters door...), but I guess it shouldn't
> be too hard to figure that one out myself.
Map transitions are a matter of taste. DR0ID made some beautiful level
transitions in our Pyweek events, but I have not gotten around to
integrating his Context class and transitions into Gummworld's Context.
I wouldn't expect you to want to work so hard at getting fancy, though.
:) But if you have some real guts, there is a zip of our Pyweek 13
Shroom Gobbler at http://code.google.com/p/multifac/. Earlier versions
of DR0ID's transitions are in Fort Izembo and Fractured Soul at the same
web site.

The Supermap class was interesting. I brainstormed an idea after a
discussion on pygame-users mailing list: how to solve a demand for huge
surfaces when SDL surfaces have a finite limit. Also including the
concern that huge maps are memory hogs, the supermap concept was
spawned. It keeps only the most immediate maps in memory. But it is not
something I have tried to use in a game yet. I'm sure there will be
significant problems to solve with regards to managing the model (list
of objects involved in game behavior) and storing/loading game state
when it is swapped to/from disk.

One strategy I've used well is to define a "level" as a Tiled map. The
player moves between levels by hitting a hot spot in the map, or
completing some game logic, or using a game menu. To do this, the use of
Context is most convenient. Engine is a subclass of Context just for
this purpose. If you're interested in this, study examples/20_context.py
and gamelib/gummworld2/context.py. Switching levels or map areas is just
a matter of managing the stack of Context objects.

On the Google code site there is a gw2_skeleton package that is also a
great (and fairly small) example of how to design a game's contexts, or
to use as a game framework. I made it to save myself time during Pyweek,
and it did save hours of work. You just plop it into a fresh gummworld2
directory and it works; just add code to flesh out your game--which is
the fun part, after all.

I hope these tips help. Feel free to shoot additional questions to the
group.
> Another thing, in my code I fixed the keyboard input, sometimes if
> changing direction too quickly, the character would
> stop moving, I think this is because maybe one would press one key
> before releasing the other, causing the approach in
> the examples to not work correctly. I fixed the issue by processing
> pygame.key.get_pressed() for both key_up and key_down
> events (see
> https://github.com/icarito/sunset-adventure/blob/master/game/runme.py#L361
> )
You're right, it is the order that the key events arrive. I've solved
this by using addition to accumulate key events. For example:

if key == K_RIGHT:
self.move_x += 1
elif key == K_LEFT:
self.move_x -= 1

Thus, if the player has opposing keys pressed they cancel out (zero)
until one is released.
> I'm still having lots of fun and hopefully so will the children. I
> tested the current version on an OLPC XO1.5 and performance
> is quite decent.
Ha. I'm delighted to hear of your experience on the lowly OLPC. :) I
look forward to watching your progress, and hope the kids get some joy
from our efforts.
Reply all
Reply to author
Forward
0 new messages