[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] different behaviour of sprites (in group) with python 2.6 and 3.1 -- silly question?

After having written my previous posting I had the idea
that this strange behaviour could have something to do
with the (random) access of items in a dictionary ...

So I examined the sprite module - and indeed, the
Group class stores its sprites in a dictionary.

I  changed line 269 as follows:

       self.spritedict = collections.OrderedDict()  # {}

and in fact now the colored_balls as well as the mailpilot
work correctly. Of course I didn't test the consequences
of this changes extensively, but the docs say that it is safe
to replace an ordinary dict by an ordered one (except
that possibly a program is slowed down if it uses lots of
sprites.)

Additionally I found a remark in Andy Harris' fine book
concerning the ordering of sprite updates (p.301)
where he recommends (for instance) to use
the OrderedUpdates group. (This maintains ordering
via a list of keys.)

Apparently I was fooled by the, I suppose accidentally,
consistent behaviour of these programs with Python 2.6.

Regards,
Gregor


Gregor Lingl schrieb:

Hi,

I've observed that sprites in a group behave
strange with Python 3.1:
the order in which they are drawn is
(1) different from the order used by Python 2.6
(2) strangely I get also different orders when I start
     the script from the commandline in two different ways:

I append a script that I prepared for the purpose
of comparison:  colored_balls.py
(A similar script using gif-images shows the same strange
behaviour)

On my machine:

with python 2.6:  blue covers red covers green    (as expected)
with c:\mycode>colored_balls.py: (starts the script with python 3.1.2) 
    blue covers red covers green
but with c:\python31\python.exe colored-balls.py red covers green covers blue 

moreover logged in as a different user on the same machine I got
when starting the script from the commandline:

  green covers bolue covers red
of course this is an inadmissible situation - so one cannot use the sprite module 
with Python 3.1?

Any remarks?

Thanks, Gregor

P.S.: While Andy Harris' mail pilot from his "Game Programming"
rund (essentially) with python 3.1 it shows an erratic behaviour
which may be due to the bug demonstrated above.