:) That's great to hear. I know how these things go, so I assumed
that it was being worked on. I also understand the complexities of
bringing out an NDK. But personally, that's high on my list of
desired features. Even one that can't link against any external
libraries would be a good start as it would allow for solid physics
engines and scene graph engines to be constructed. Not to mention the
benefit of C/C++'s lower level type system, which would allow for the
construction of fast, memory efficient math classes. :)
Thanks for your efforts and support,
Anton
On Apr 3, 2:29 am, Romain Guy <romain...@google.com> wrote:
> We're aware of the shortcomings of the current garbage collector and
> believe me, it's one of the things we'd really love to see improved as
> soon as possible :)
>
> On Fri, Apr 3, 2009 at 2:04 AM, Mariano Kamp <mariano.k...@gmail.com> wrote:
> > Anton, thanks. Very interesting.
> > On Fri, Apr 3, 2009 at 2:24 AM, Anton <socialhac...@gmail.com> wrote:
>
> >> Check out
> >>http://android-developers.blogspot.com/2009/02/track-memory-allocatio...
>
> >> Romain Guy points out in this post that the android garbage
> >> collector cannot optimize small short lived objects. These are
> >> exactly the sort of objects that could be created in a physics engine
> >> when it needs to generate dynamic collision constraints. A good
> >> solution in this case is to use a pool of constraint objects because
> >> they are all going to be the same size/object. The best solution in
> >> my mind would be for the compiler to do escape analysis on the objects
> >> and stack allocate them when it sees that they will never escape the
> >> function. I have been told that the Java byte code can't reference an
> >> object on the stack. It's possible that the Dalvik byte code can, I
> >> don't know.
>
> >> I don't have a reference for this, but I assume that Dalvik's
> >> inability to optimize small short lived object comes from the fact
> >> that it uses a mark and sweep GC. On all of my profiling, I see the
> >> GC take at least 100ms to run. For a game that means you miss from
> >> three to 10 frames of animation and it makes for a pretty noticeable
> >> hick up. And I don't think it's my application that is causing the
> >> garbage collector to fire. Unless the OpenGL ES calls do some memory
> >> allocation, which is entirely possible. I realize that any background
> >> task could move to the run queue and take some time away from my
> >> engine, it just happens to be the garbage collector most of the
> >> time. :)
>
> >> So the result is that the Garbage collector is problematic for me
> >> in two ways. First, it's not optimized to deal with the sort of small
> >> objects that tend to make for good encapsulations of mathematical
> >> types (like Fixed point number classes or Vector or Matrix classes).
> >> And secondly it takes a long time to run when it does garbage collect,
> >> resulting in dropped frames.
>
> >> -Anton
>
> >> On Apr 2, 3:32 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
> >> > It's maybe a bit off topic, but how do you know that Android's gc is
> >> > rudimentary? Have you got a link handy?
> >> > I only found
> >> > this:http://developer.android.com/guide/practices/design/performance.html
>
> >> > On Thu, Apr 2, 2009 at 11:59 PM, Anton <socialhac...@gmail.com> wrote:
>
> >> > > Shaun, thanks for checking it out. Yah, I agree that the real
> >> > > complexity of a physics engine comes from joints and contact
> >> > > constraints. The constraints in my demo are simple minimum distance
> >> > > constraints. I have a 2D rigid body physics engine that I'm thinking
> >> > > more and more about porting over to Android as well. This demo was
> >> > > more of a calibration for myself to see how much computation I can do,
> >> > > and what optimizations lead to the largest improvements. I'll
> >> > > probably turn it into a fun toy for the Market and then look into
> >> > > rewriting my rigid body engine for Android.
>
> >> > > Reading through Simpull I noticed that you allocate a new Vector3f
> >> > > in your Verlet update routine. I think that will be a killer on the
> >> > > Android platform because of it's rudimentary garbage collector and
> >> > > limited RAM. My solution was to allocate an array of fixed point
> >> > > numbers, four per ball. Effectively a vector pool that didn't require
> >> > > any management because the number of balls never changed.
>
> >> > > On Apr 2, 6:31 am, shaun <shashepp...@gmail.com> wrote:
> >> > > > I took a look at Anton's demo on a G1 device, and I was glad to see
> >> > > > the integration of accelerometer as it really added value. I assume
> >> > > > the calculations for collision detection and response are fairly
> >> > > > basic, which allows for that performance.
>
> >> > > > Simpull will also provide good performance for a scene of that
> >> > > > nature
> >> > > > (all verlet, no joints). At least I believe it will. The point
> >> > > > where
> >> > > > simpull becomes slow is when a more complex scene is in play with
> >> > > > 10s
> >> > > > of objects with many joints connecting some of them. Since the
> >> > > > engine
> >> > > > is all verlet and no rigid body dynamics, joints are one way to
> >> > > > acheive a similar result, but with a very bad performance hit due to
> >> > > > all the new temporary objects and new calculations.
>
> >> > > > I would be super impressed to see a demo like Anton's with rigid
> >> > > > body
> >> > > > dynamics involved with at least some rectangles, if not other
> >> > > > polygons
> >> > > > and perhaps a joint or two. That is where the performance degrades
> >> > > > quickly in my experience.
>
> >> > > > On Apr 1, 2:45 pm, mscwd01 <mscw...@gmail.com> wrote:
>
> >> > > > > Thanks Lajos for pointing APE out, I hadn't heard of it until now.
>
> >> > > > > Unfortunately your link to your Android port is broken, can you
> >> > > > > mend
> >> > > > > it as I dont fancy spending another hour porting another library
> >> > > > > to
> >> > > > > Android :D
>
> >> > > > > Thanks
>
> >> > > > > On Mar 31, 9:50 pm, lkelemen <tridc...@gmail.com> wrote:
>
> >> > > > > > Hello everyone,
>
> >> > > > > > I was also disappointed with jbox2d's performance so I checked
> >> > > > > > APE
> >> > > > > > (Actionscript Physics Engine) fromhttp://www.cove.org/ape/.
> >> > > > > > It was converted to java (http://www.cove.org/ape/java_ape.zip)
> >> > > > > > so I
> >> > > > > > started to convert the java version to Android.
>
> >> > > > > > The performance is quite OK for 10-20 objects at the first start
> >> > > > > > of
> >> > > > > > the app but if you exit with the back key and restart it form
> >> > > > > > the
> >> > > > > > installed copy
> >> > > > > > (either in the emulator or on the dev phone) then it gets slower
> >> > > > > > and
> >> > > > > > slower with each start. If you restart it from the emulator (by
> >> > > > > > reinstalling it) then it is faster again.
> >> > > > > > Neither the pressed keys are not working (probably it is because
> >> > > > > > of
> >> > > my
> >> > > > > > poor Android programming knowledge).
>
> >> > > > > > Here is a zipped Android project of it. Please experiment with
> >> > > > > > it and
> >> > > > > > send results to here i.e. is it slow for you also after
> >> > > > > > re-re-re-..
> >> > > > > > staring?www.kotiposti.net/lkelemen/android/testape2d.zip
>
> >> > > > > > thanks
> >> > > > > > Lajos Kelemen
>
> >> > > > > > On Mar 31, 9:26 pm, shaun <shashepp...@gmail.com> wrote:
>
> >> > > > > > > I started going down the path of Object pooling. It seemed
> >> > > > > > > the
> >> > > only
> >> > > > > > > solution when taking an existing engine and making work on a
> >> > > resource
> >> > > > > > > constrained system like Android on a phone. Determining the
> >> > > strategy
> >> > > > > > > for returning objects to the pool proved quite tough for me.
> >> > > > > > > I
> >> > > have
> >> > > > > > > no doubt there are some experts on embedded systems
> >> > > > > > > programming
> >> > > with
> >> > > > > > > tons of experience with object pooling. We just would be too
> >> > > > > > > lucky
> >> > > if
> >> > > > > > > that person(s) was also experienced with Java, physics engines
> >> > > > > > > and
> >> > > had
> >> > > > > > > a passion for open source and games! Is that too much to ask?
> >> > > LOL!!
>
> >> > > > > > > On Mar 31, 12:17 pm, mscwd01 <mscw...@gmail.com> wrote:
>
> >> > > > > > > > Thanks for your feedback Shaun, I too unfortunately think a
> >> > > bespoke
> >> > > > > > > > engine will need to be written for Android, which is a real
> >> > > > > > > > pity
> >> > > as
> >> > > > > > > > the iPhone has several physics engines which can easily
> >> > > > > > > > handle
> >> > > > > > > > hundreds of objects.
>
> >> > > > > > > > Having said that Anton (2nd reply) has said he has an engine
> >> > > running,
> >> > > > > > > > it would be nice to see a demo of this if that'd be
> >> > > > > > > > possible?
>
> >> > > > > > > > Clark, i'd definately host any .apk's on my own site, I
> >> > > > > > > > wouldn't
> >> > > put
> >> > > > > > > > it on the marketplace if it wasn't a "finished" app - do
> >> > > > > > > > people
> >> > > > > > > > actually do that?!
>
> >> > > > > > > > I think i'll stay away from developing games with physics
> >> > > > > > > > for the
> >> > > time
> >> > > > > > > > being and concentrate on something else, I cant see it being
> >> > > feasible
> >> > > > > > > > to include it any time soon which is a real pity.
>
> >> > > > > > > > On Mar 31, 3:28 pm, shaun <shashepp...@gmail.com> wrote:
>
> >> > > > > > > > > I am the author ofsimpull.
>
> >> > > > > > > > > Sorry guys for the demo being out of whack forSimpullto
> >> > > > > > > > > the
> >> > > Core.
> >> > > > > > > > > The version of PulpCore that I integratedsimpullwith did
> >> > > > > > > > > not
> >> > > support
> >> > > > > > > > > Chrome, but you should be able to see it in IE, FF Safari.
> >> > > > > > > > > It
> >> > > is nice
> >> > > > > > > > > to take a look at that demo to get a feel for what the
> >> > > > > > > > > engine
> >> > > is
> >> > > > > > > > > capable of, but the performance does not translate over to
> >> > > > > > > > > the
> >> > > fixed
> >> > > > > > > > > point branch/version ofsimpullwhen running on Android.
>
> >> > > > > > > > > I ran tests on both the emulator and the actual device and
> >> > > there was a
> >> > > > > > > > > significant increase in performance because of the fixed
> >> > > > > > > > > point
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
