The http://www.filedropper.com/apedroid link is down. Any other place I can download the code? Has anybody else had any luck optimizing Phys2D or Box2D with fixed numbers and less memory allocation?
Kyle On Apr 3, 8:24 am, mscwd01 <mscw...@gmail.com> wrote: > I have thrown together a quick example of theAPEPhysics engine > (www.cove.org/ape/) running on Android. > > As you can see, simulating 30 or so circles results in a solid 15fps, > which looks acceptable. > > The bad news, which I didn't realise before porting it to Android, > isAPE'slack of simulating rotation of bodies. I.e. if you simulate > boxes their x,y positions are calculated but they never rotate. I'm > pretty sure I haven't overlooked this feature but i'd be surprised if > it wasn't part of theAPEengine, maybe someone else could confirm > this? > > Anyway,APEis a lot nicer to use than JBox2D and is on a par with > Phys2D for ease of use. I just wish Phys2D performed well on Android > then all my problems would be solved! > > With all the attention this topic has brought I hope we can find a > solution in the not-to-distant future... > > Here's the Eclipse Project:http://www.filedropper.com/apedroid > When running 20 initial circles are created, you can create more by > clicking the down button. > Also you will find lots of commented out code, you can experiment with > this if you wish... > > On Apr 3, 12:35 pm, Stoyan Damov <stoyan.da...@gmail.com> wrote: > > > + googol > > > On Fri, Apr 3, 2009 at 1:43 PM, Mariano Kamp <mariano.k...@gmail.com> wrote: > > > Romain, > > > > I am sure you are, but as with the Cupcake issue from the other thread > > > with Al, it is not transparent at all. The road map > > > (http://source.android.com/roadmap) doesn't contain much and doesn't seem > > > up > > > to date. > > > > And don't get me started on the lack of transparency and predictability > > > regarding *all* things Android Market. > > > > Don't get me wrong though. This is not meant in any way as a personal > > > attack against you or in me laying the blame onto you. My point is that > > > the > > > communications sucks and that your, Dianne's and JBQ's life would be > > > easier > > > as well when someone offical from Google would put more effort into proper > > > communications. > > > > Cheers, > > > Mariano > > > > On Fri, Apr 3, 2009 at 10: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 pointingAPEout, 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. > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
