When I apply force on the PC in the editor it behaves like I want it to, but on the android the force seems like its 90% weaker. I know the game isn’t going slow because I can tell from me moving the camera around the scene and it all runs smooth.
This is on a Asus transformer running honeycomb 3.1.
I would rather not start adding to my forces to work around this because that would force me to have to build everytime to test changes in my code.
It sounds more like a code issue then a device issue… personally. Post up some code 
Just from the sounds of things, it sounds like frame speed based issues. (500+frames per second on pc as opposed to the 40+frames per second on device) Just saying what it sounds like to me, but the code would have to be seen to know for sure. (Not certain I can really help as I don’t even have an android license, but this doesn’t sound like device code as much as just physics code.)
Might be worth checking what the fixed time step for the physics system is. It might be different on Android, if you are doing something inside the fixed time step like ‘addforce’ that might explain your problem.
I have the same the Sam physics performance on low end machines with low frame rate when compared to the 100fps machines I test on.
I think this is a frame step issue because lowering the mass of my objects resolved the problem, but I would have preferred not to do that. I add force in fixedupdate.
I would check the time step, but don’t know where to find that for the android settings.
What I’m doing to get around this is I have a check if its android remove 83.3333 percent mass from all rigidbodies in my scene.
Dude, you are doing physics in fixedupdate only with no deltatime, right? cos if you’re not, you’re using physics wrong. You don’t use them in update, only fixedupdate.
Soon as you run it on a different device it’ll change again. Move all physics code to fixedupdate.
My code is in fixedupdate.
Like I said in my earlier post, check what the fixed time step is. The problem is that you are calling addForce more frequesntly in the player than on the device due to the difference in the fixed time step. You should multiply your addForce by the delta:
Yeah for some reason I thought fixedupdate automatically took into account the fixedDeltaTime. I’ll make the changes to my code and add fixedDeltaTime to where I’m applying force.
Same results using Time.fixedDeltaTime. power is set outside of the script to 2500.
At first I had a loss in power when adding Time.fixedDeltaTime, so I thought well its probably because I wasn’t doing this correctly before so I need to adjust my power. I changed my power to a higher number 55000 and that gave me the original kick that I would experience before on the pc, but on the android its still 90% weaker.
Old line in fixedupdate:
rigidbodies["wheel"].AddForce (Vector3.up, Globals.power);
New Line in fixedupdate:
rigidbodies["wheel"].AddForce (Vector3.up, Globals.power * Time.fixedDeltaTime);
delta time will automatically use the correct time if it’s in fixed update or update, you don’t need to change it.
You shouldn’t have to use fixedDeltatime in fixedUpdate unless your framerate is unstable. If it’s going at a regular 25 or 30 fps, its not going to help you since fixedUpdate is called at regular intervals with a clear cap on it. It can help if you are heavily CPU bound though.
Yeah that’s what I thought, but I thought I would follow the advice from the other guys on this post. So should I not be multyplying by a Time.* or should I just lower the mass off my objects when running on the android?
When I said Time.* above I mean any time like Time.deltatime.
For those of you curious as to what was going on here. I figured it out as I went more deep into development for this and what I found was:
I was using a gui button to turn on a variable in my fixedupdate script. When the variable was triggered the force was added. What I did instead was in my fixedupdate script I am now checking if the user touched an area of the screen and avoiding the GUI button.
So if you use a GUI button to turn on a variable that would trigger the addition of force in fixedupdate theres lag. Now that I think of it I can see why it would because OnGUI is not called as often as FixedUpdate. 
You shouldn’t be using the horror that is ongui at all in ios as its such a performance hit. Same for android
Use quads instead, they are twice the speed at least. The gui overhaul in a future patch will fix it all.
Would quads work on every fixedupdate call? The reason why I ask is because if it doesn’t then it would only apply a 3rd of the power than what I’m currently getting in fixedupdate.
Wait are quads just to draw? If so are you saying get rid of all my OnGUI and draw everything using quads and my controls should remain in fixedupdate?
controls should be in update, and you use quads to draw buttons/text etc in update as well. fixedupdate is for time critical stuff like simulations, and physics / sound etc if physics use sound.
basically, the only loop that runs at its own separate timing is fixedupdate. normal game stuff, input and everything else should really go in update().
There’s plenty of interesting free libraries to help you draw quads like spritemanager 1 and (even easier) prime31’s gui system (also free).
I’ve rolled my own from scratch because I’m experienced and want to do it all my way, but it doesn’t mean those are bad solutions.
The unity gui stuff really is quite bad because it is called multiple times per frame and is a resource hog.
So what about when applying force? Right now I’m checking in fixedupdate if a key is pressed then applying force.
Should I be checking in update if the key is pressed then turn on a variable that would tell fixedupdate to apply force?
I’m trying to port this over to the android which is why I added the touch input check to fixedupdate.
the touch stuff sets variables instead in update.
the variables are checked in fixedupdate.
usually you will make an input manager, a function called once that gathers all input in one place and deals with that, and call the function from update, then in fixed update you just do your logic for the physics.