Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / physics differs in Android vs. Windows

Author
Message
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 21st Oct 2013 19:02
So I just ran some tests on an animation that uses physics and I'm getting quite different results on Android than I do on Windows. My object simply drops from off the screen and bounces toward the right of the screen. Works great in Windows, but on Android it behaves as if the object weighs 10x more.
Is this a known issue? If it is a framerate issue then how do you get around it?
Fortunately it is not that terrible, so I might just leave it, but it concerns me that there is such a huge difference and I worry that there will be even more of a difference on iOS.
Would love to hear from some folks who have set up physics in their game.
Also this is only for 2d sprites.
Thanks!

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Oct 2013 19:06
You should set the physics scale using setPhysicsScale(scale#). If you are scaling objects up for larger resolutions you'll need to scale the physics too (before you create any physics sprites).

Remember that if a sprite is 16 pixels wide on one device and 32 wide on another the physics will certainly react differently as it is effectively twice the size and 4 times the volume.

oct(31) = dec(25)
The Zoq2
15
Years of Service
User Offline
Joined: 4th Nov 2009
Location: Linköping, Sweden
Posted: 21st Oct 2013 19:08
It sounds like this is a matter of the physics scaling with resolution. I believe that 1 physics mass unit is the default mass for a 1x1 unit big square sprite. If the devices have diffirent resolutions and you are using a virtual esolution system, the mass of the objects will change

Say ONE stupid thing and it ends up as a forum signature forever. - Neuro Fuzzy
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 21st Oct 2013 19:08 Edited at: 21st Oct 2013 19:10
hmm, i know the physic system get inaccurate with less frames or wider time steps.
can you show your source code?

about virtual resolution, i believe 100%=100=100meter default scale.
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 21st Oct 2013 19:09
That's good to know!
Makes sense, but quite a difference!
On windows my resolution is something like 650x900 and on Android it is 800x1200... I'll try adjusting the scale to see if that works.
Thanks!

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 21st Oct 2013 19:17
Quote: "If the devices have diffirent resolutions and you are using a virtual esolution system, the mass of the objects will change"

I am not sure that is correct.

If you use the same virtual resolution for all devices, physics should (and does) work the same on the different devices. I have the same virtual resolution in my WIP and it works the same on all the devices, ranging from one with an actual resolution smaller than the one I am using to one that has 4 times the actual resolution.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 21st Oct 2013 19:18 Edited at: 21st Oct 2013 19:19
Here's a snip of the code... it has all of the physics settings, so you should get the idea



I'm working on a few other things at the moment so I might not get to try adjusting for scale until later, but thanks. I'll report back when I have the chance.

EDIT: I am not using virtual res. So I bet scaling is the issue, I didn't even know about it

Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 21st Oct 2013 21:50
Altering the scale doesn't seem to affect it very much.
Maybe it is something to do with framerate... which I'm not sure can be adjusted for in physics...

Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 21st Oct 2013 22:49 Edited at: 21st Oct 2013 22:53
just print(ScreenFPS()) in main loop, should be 40-60.
29 games
19
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 22nd Oct 2013 00:30
I was quite intrigued with this issue as I've only just started to play around with box2D (having never used a physics engine before) and have the opposite conclusion to you in that changing the size (thus mass of the sprite) has a huge impact.

I modified your code, boiling it down to a single sprite fb:



I was looking more at the way the sprite bounces, how many bounces, interval between bounces and the change to angular velocity after the first bounce etc and these are the results:

sprite size: 15
angular velocity after 1st bounce: 3.60
angular velocity after 2ns: 2.4

sprite size: 17
angular velocity after 1st bounce: 3.04
angular velocity after 2ns: 2.19

sprite size: 30
angular velocity after 1st bounce: 1.87
angular velocity after 2ns: 0.62

Just changing the size by 2 pixels in height and width, gives a huge change in the angular velocity after the first bounce. I also noticed a change in the y velocity immediately after the first bounce and the interval between bounces but didn't make a note of it. In a more complex system, with lots of things bouncing about, I would expect the outcome to be completely different.

I'm a bit of a novice at this and I don't really know how mass and size affect things in box2D, like: friction and restitution, "impact" forces during collision, angular momentum and the such. I've only experimented with springs and "shock absorbers" in box2D so far. I know how it all works in real life but some of the stuff in box2D has been simplified. For instance: in real life friction is the result of the interaction between two objects', their surface finish and any lubrication and is not something that is an attribute of a single object, the same is true of restitution and damping in the box2D sense isn't what I would consider damping in the sense of, for instance, car suspension (I.e. shock absorbers).

I'd be very careful of dismissing the difference in mass and size of the sprites. It could be affecting a lot of different things that effect the final outcome of the collisions and giving completely different results.

This may not solve your problem and was probably more instructive for me than anyone else with more experience of box2D but I thought I'd share anyway.

one of these days I'll come up with a better signature
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 22nd Oct 2013 05:31
Framerate was steady in the high 50s. I don't have any other stuff going on it the game. The bounce was a little better with the adjustment for pixel size. I'm just going to leave it at that... as long as it falls onto the screen I'm ok lol

Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 24th Oct 2013 21:19
So after more tests this seems to be related to sync rate...
Sometimes the FPS will drop to around 40 and I notice that is when the object falls the shortest distance...
How is it possible to compensate for this?

Funnell7
13
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 24th Oct 2013 21:38
Naphier, take a look at this thread;

http://forum.thegamecreators.com/?m=forum_view&t=204311&b=41

Although I got it to work on that small example, when I moved the changes to my game, it made it really jerky. Maybe you'll have more luck?? Let me know how you get on...
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 24th Oct 2013 21:46
Very cool. Thanks for pointing that out. I was under the false assumption that physics handled frame drops on it's own, but apparently not! I'll give that method that Paul pointed out a go - hopefully tonight.
Thanks again!

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 24th Oct 2013 21:53
Physics will move things based on the actual elapsed time, not the time you want it to be, when you use just the Sync() command (instead of playing with the components that make up the Sync() command).

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 27th Oct 2013 20:48
The step skipping helped perfectly!
Thanks again!!

Login to post a reply

Server time is: 2024-11-24 21:53:22
Your offset time is: 2024-11-24 21:53:22