Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago @Adam, how many concurrency issues did you notice in the code? Starting a game
and deciding which game engine to use - concurrency issues are a bit worrisome.Original comment by mar...@gmail.com on 5 Sep 2011 at 12:57
GoogleCodeExporter
commented
9 years ago @markww, There are quite a few. Some of them have been fixed in this commit:
http://code.google.com/p/andengine/source/detail?r=8866cde61cf59ce189fa129453d25
ebe0fa438f5
But there are more concurrency issues in there... Some related to the Engine
class, modifiers and entities in the engine. We have fixed most of these issues
by extending the Engine class and adding custom locks, but there is more in
there...
Some of these are very hard to trigger...
We still have a few random crashes related to this that we have not looked into
yet.
AndEngine is still a good choice though :).Original comment by adam.waldenberg@gmail.com on 5 Sep 2011 at 9:20
GoogleCodeExporter
commented
9 years ago Hi Adam,
Thanks for the update, do you know if the other concurrency issues are being
worked on?
Related - will builds of the project as jars (in the download section) no
longer be supported? I thought I downloaded precompiled jars from there in
April, don't see anything in the downloads sections anymore. Would be nice if
official jar snapshots were made whenever bug fixes were submitted.
ThanksOriginal comment by mar...@gmail.com on 5 Sep 2011 at 2:05
GoogleCodeExporter
commented
9 years ago Errors like this are also caused by the way Entity iterates through its
children.
In particular, it caches the number of children before starting. This means
that if a child removes itself during its onUpdate function, the cached value
will now be too high and the iteration will go out of bounds.
In my experience, it is quite common to want to remove a child when a modifier
finishes. However, the listener's onModifierFinished function is called during
onUpdate, so doing so causes an exception. The same applies to update handlers.
I can't think of an efficient solution for this, but an inefficient solution is
to recheck the array size after updating each child. (Actually, I also added
synchronized blocks in the methods that change the array and try/catch blocks
in a couple other places, so you might have to do all of those to get the
benefit.)Original comment by player3...@gmail.com on 8 Sep 2011 at 7:51
GoogleCodeExporter
commented
9 years ago @markww, No idea :). And as far as I know there are no precompiled snapshots.
@player3.14, We added a lock in a custom Engine class to fix all these issues
and simply override onDrawFrame in Engine. Then it's just a matter of
synchronizing against the lock in the right methods in our extended
Scene/Entity classes.
It has worked so far... But I have a feeling we will run into something sooner
or later that will force us to modify the AndEngine code ;).Original comment by adam.waldenberg@gmail.com on 11 Sep 2011 at 10:23
Original issue reported on code.google.com by
adam.waldenberg@gmail.comon 17 Jul 2011 at 5:14