You have to consider also the rate in which the gravity sensor gets queried … that rate is also lower, so I cannot tell you exactly if it feels lagy because of the FPS or because of the query rate of the sensor.
I remember when using the vibrator for example (where you tell the duration of vibration) there is a “minimum value” depended on the speed of the phone, so a 10 milli does longer vibrate than on the S3.
To answer your question I would have to play the game on the S3 first to see how it feels on a proper phone personally I am not able to play it on the (slower) “Galaxy 3” because it does react too slow, it’s nearly impossible to steer the rocket.
Will try it later on S3 to give you a better answer
On S3 it works well, as far as comments go. If it comes for sensor values as far as I remember they shouldn’t trigger any issues, as the sensor itself get refresh quite frequently (more than it takes to render the scene). The only issue on the Galaxy 3 can be low frame rate, which could be resulted by many factors which I’m most probably not able to overcome. I’ve blocked Galaxy 3 from Google Play store, as most probably there is a frame rate issue, still I would like to have it confirmed Thanks
As I said, it just looks and feel too slow, that is true for nearly every animation you have in the game - if I had to guess, I would say, you coded your game frame rate dependend - which is bad.
In my case I use time based animation rendering - so the movement is always equal, except, that on slower phones, more frames are skipped, but in the end it just to not look and feel laggy.
So you should built in a timestep based algorithm to do your calculations, I am pretty sure, when this is done, your game will run much smoother on low-spec phones. By the way, that’s an all time best practice, because max framerate will differ on various devices. There are devices out there which have a framerate limit 0f 30-40 - you should not rely on getting any specific framerate at all.
[hr]
Not sure, if you already did it that way, but here is an example of what I mean. First of all measure every movement in unit/second.
so your rocket makes 10 pixels / second, it will mean that:
float move = 10 * deltatime (deltatime is seconds since last frame)
that way, the rocket will move the exact same distance no matter which framerate counts. If someone moves the phone for steering, you should also use a degree/second value to do the movement.
It will feel much smoother in the end and shouldn’t lag
Also because your steering will rely heavily on a responsive phone - try to optimize whereever possible. Make a head trace to see if the GC is working heavily, do not use Collections on volatile objects (make your own chained lists) - the goal is to spare as much “new” as possible … Garbage Collection is your biggest foe on android
You’ve made such an effort to write it all down I will write my comments inlined…
Do you really think that I wrote all the game (in Java for heavens sake), made the all graphics, music etc and made my physics frame rate dependent?
To be more precise, not a degree value (in form of a scalar value), but rather the rotation vector.
I know that too;) I’m using pooling pattern wherever I can (such as particles systems etc).
Just check the game on your s3 you’ll see it’s buttery smooth. For some time I’ve been working on my game on my friends Galaxy S where the frame rate was more than what I’d expected (it could manage more than 30fps). As I said before the game is entirely written in Java (virtual functions nearly everywhere, happy me) and I’m also using some shader tricks to make fire more natural. So if the game is not working properly on the older phones, yes this is what to be expected. If there is no GPU on the board the emulation will kick in probably significantly reducing the game speed. So as I said, check it out on your S3… Still… this device is so powerful you could run anything on it (even the worst game in the history of the universe… I wonder what it could be). Therefore it will not justify my developers skills (for heavens sake why did I wrote it in Java…)
Cheers
in the end, the one or other reader may find all that information helpful so it is not without reason xD
I was just wondering, because I use the Galaxy 3 to optimize my own games - it will always lag a bit on that phone, but normaly it is playable (more or less) … could just be, that for me it is unusual because I didn’t know the game xD But well, I do not use shaders and stay low level, so that may have some impact (especially on older phones)
I didn’t want to justify your skills, it’s a well made game, just wrote done syme tipps, someone will have use for it
Also there is some time, when devs need to abondon older devices. It is still the S2 the most used phone, followed by the galaxy ace, Galaxy S and Galaxy Mini (samsug rules the world) - I also have a Ace, which is far more capable than the Galaxy 3 xD
Yeah, I know what you mean, I’m doing my performance testing on Galaxy Mini and checking the game on my friends/family phones whenever I can. Oh Android
I don’t suppose there is any way to do such tests for audio ?
Android has weak audio - with inconsistent behavior by manufacturers - a number of Samsung phones (lower spec ones) have odd behavior not seen in the high end versions.
For example is it well known that the API gives wrong feedback - i.e. will say a sample rate will work when it doesn’t (and it will freeze up the audio system on some phones) and so on.
personally I am not able to play it on the (slower) “Galaxy 3” because it does react too slow, it’s nearly impossible to steer the rocket.
Thanks
I will write my comments inlined…