I too would like to try apedroid but I cant find it to download?
please :-)
--~--~-~--~~~---~--~~
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@googlegrou
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 wrote:
> I have thrown together a quick example of theAPEPhysi
:) 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 star
I was saying in terms of the other physics engines we have tested,
15fps for 30+ objects is a lot more acceptable than 1-2fps! But yes of
course if you were to create a game which relied heavily on a physics
engine it would be less than ideal ;)
On Apr 3, 4:31 pm, Stoyan Damov wrote:
> On Fri, A
On Fri, Apr 3, 2009 at 6:24 PM, mscwd01 wrote:
>
> I have thrown together a quick example of the APE Physics 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.
>
:( 15 fps? IMO it's not that accepta
I have thrown together a quick example of the APE Physics 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, is
APE's lack of simulating ro
+ googol
On Fri, Apr 3, 2009 at 1:43 PM, Mariano Kamp 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.
>
>
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
reg
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 wrote:
> Anton, thanks. Very interesting.
> On Fri, Apr 3, 2009 at 2:24 AM, Anton wrote:
>
Anton, thanks. Very interesting.
On Fri, Apr 3, 2009 at 2:24 AM, Anton wrote:
>
>Check out
> http://android-developers.blogspot.com/2009/02/track-memory-allocations.html
>
>Romain Guy points out in this post that the android garbage
> collector cannot optimize small short lived objects.
Check out
http://android-developers.blogspot.com/2009/02/track-memory-allocations.html
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
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 wrote:
>
>Shaun, thanks for checking it out. Yah, I agr
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 ove
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 scen
On Wed, Apr 1, 2009 at 8:10 PM, lkelemen wrote:
> Link is working now. I've put
> System.exit(0);
> to the Activity's onStop and the performance looks stable now.
Er, that is very wrong. It sounds like you aren't properly cleaning things
up when the activity goes away, perhaps leaving a runnin
Hi,
Link is working now. I've put
System.exit(0);
to the Activity's onStop and the performance looks stable now.
The state of the physics world is not preserved when you push home and
long push home and swithch back to the app.
What do you think:
Would using a Vector pool in class CollisionResolv
I'm curious too! :)
On Apr 1, 9:25 pm, mscwd01 wrote:
> I have some good news too, I have successfully ported APE
> (http://www.cove.org/ape/) to Android and have a simulation of 50 objects
> running extremely smoothly.
>
> Considering I have only spent an hour or so converting everything to
>
Yes, I'd love to see the results of that.
-Anton
On Apr 1, 6:25 pm, mscwd01 wrote:
> I have some good news too, I have successfully ported APE
> (http://www.cove.org/ape/) to Android and have a simulation of 50 objects
> running extremely smoothly.
>
> Considering I have only spent an
I have some good news too, I have successfully ported APE (http://
www.cove.org/ape/) to Android and have a simulation of 50 objects
running extremely smoothly.
Considering I have only spent an hour or so converting everything to
Android and making minimal optimisations this is really good news
i
About open-sourcing it:
Thanks! That would be great and i'll be happy to do some work on it to
make it even better (if i *can* do this; you already did a great job).
Let us know when your api is ready to be put on open-source. :-)
On Apr 1, 8:48 pm, Anton wrote:
> I've done some more profi
Awesome.
It is visually much smoother than your first version. Three thumbs up!
On Apr 1, 8:48 pm, Anton wrote:
> I've done some more profile based hand optimization and I now have
> it running superfast. :) I've put the new version in the same
> location as the previous one. I still had
I've done some more profile based hand optimization and I now have
it running superfast. :) I've put the new version in the same
location as the previous one. I still had some floating point code
that was slowing me down. The difference between floating point and
fixed point is not to be u
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 wrote:
> Hello everyone,
>
> I was also dis
Hello everyone,
I was also disappointed with jbox2d's performance so I checked APE
(Actionscript Physics Engine) from http://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
It does look smooth on the G1. The use of accelerometers is quite cool.
Good job on minimizing the GC jitters. The screen has horrible ghosting with
green to grey transitions, however, which mars the smooth framerate a bit.
Red balls would probably reduce that.
-Daniel Sargeant
On Wed, Apr 1, 20
Two thumbs up!
It's fast, not superfast, but there are quite a number of balls in the
pit. I'm impressed.
If this code could get into the native system, into the firmware...
On Apr 1, 2:44 am, Anton wrote:
> OK, for anyone interested in my simple physics demo, check out:
>
> http://www.a
I'm quite interested as well.
On Wed, Apr 1, 2009 at 3:04 PM, mscwd01 wrote:
>
> Thanks for the demo Anton,
>
> It certainly runs much smoother than the Phys2D and JBox2D engines I
> have tried and you have more objects being simulated - so you must
> have done something right ;)
>
> I would exp
Thanks for the demo Anton,
It certainly runs much smoother than the Phys2D and JBox2D engines I
have tried and you have more objects being simulated - so you must
have done something right ;)
I would expect it to run 2-3 times faster on an actual device too from
what I have read.
Once you have
OK, for anyone interested in my simple physics demo, check out:
http://www.antonstoys.com/android/BallPit.apk
It's pretty basic, but it shows that you can do some amount of
physics on the G-phone at a reasonable rate. And as always, there are
many improvements to be made. :)
-
I'll definitely post the app tonight for you guys to check out (at
work now). I am an embedded systems programmer by trade. But I do
physics toys for fun and am just getting into Java/Android
optimizations. I will point out that optimizing for Java and
optimizing for Android are very differ
seems that gc is a problem, just one of them at least, so can we please have
a c++ sdk?
On Tue, Mar 31, 2009 at 9:26 PM, shaun 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 sys
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 s
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 woul
Right. The single biggest issue is GC. I guess if vectors and all
other objects, which are frequently created, get pulled out of an
object pool, and reused (that's quite tricky though, because of the
explicit "returnToPool" call) all engines will shine. In several
places, temporary/scratch objects
On Mar 31, 6:49 am, "admin.androidsl...@googlemail.com"
wrote:
> Not tried but if you can provide us with some example source code or
> put something on the market, I'm sure we could take a look.
Perhaps putting it on a website rather than the Market would be best.
The market already has plenty
I am the author of simpull.
Sorry guys for the demo being out of whack for Simpull to the Core.
The version of PulpCore that I integrated simpull with 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 engi
I'll try and wrap my Phys2D & JBox2D examples into a .apk sometime.
I'm very busy at the moment though so it may be later in the week by
the time I get to do it. I'll provide a link in this thread if I get
to do it.
Other than that, i'll have to wait until the HTC Magic is released
soon ;)
On Ma
Not tried but if you can provide us with some example source code or
put something on the market, I'm sure we could take a look.
G1 performance is significantly faster than emulator, but there are
limitations.
Particularly with garbage collection and memory allocation on code
that gets run conti
Oh I forgot to re-ask...
"Has anyone tested Phys2D or JBox2D on an actual device to see if they
run better than on the emulator?
I have a feeling the performance will better on a G1 than the emulator
for some reason!
On Mar 31, 12:51 pm, mscwd01 wrote:
> I did take a look at Simpull, however t
I did take a look at Simpull, however the demo application failed to
run as it relied on some library which wasn't supplied or referenced
to - I just got annoyed after spending two days failing to get Phys2D
and JBox2D to work in Android and didn't bother trying to work out the
problems!
I might
where's the demo? I tried the see it in action link (
http://simpull2core.sourceforge.net/) and it shows some code
On Tue, Mar 31, 2009 at 2:19 AM, Anton wrote:
>
>That's what I did. :) Firefox 3.0.8. I just tried it again and
> had the same thing happen. I'll give it another go when I ge
That's what I did. :) Firefox 3.0.8. I just tried it again and
had the same thing happen. I'll give it another go when I get home
and have my development machine at my disposal.
By the way, nice name. :) Always good to meet a fellow Anton.
-Anton
On Mar 30, 4:01 pm, Streets Of
Try the demo on firefox. It works really well.
On Mar 30, 5:59 pm, Anton wrote:
> Could be good. I tried to check out the demo but it crashed my
> browser. :) I'm sure that's not really indicative of the engine, and
> more of my browser's stability. I did look through the code and found
Could be good. I tried to check out the demo but it crashed my
browser. :) I'm sure that's not really indicative of the engine, and
more of my browser's stability. I did look through the code and found
that it does a lot of memory allocation in it's inner loops (Verlet
update step in parti
I wonder how well this one works on Android:
http://code.google.com/p/simpull/
-- Anton Spaans
On Mar 30, 4:58 pm, Anton wrote:
> I have a simple 2D physics engine written and running. It uses
> the now famous Jacobson physics tricks (Verlet integration and hard
> constraints). I can m
I have a simple 2D physics engine written and running. It uses
the now famous Jacobson physics tricks (Verlet integration and hard
constraints). I can manage 40 balls on the screen, with fill n^2
interaction between balls. I am working on spatial data structure
optimizations now to improve
46 matches
Mail list logo
