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.
