CODEWITHSUNDEEP
javaandroidopengl-esopengl-es-2.0
Lapo
Lapo

Reputation: 992

Smooth movement Opengl ES 2.0

I'm building a very simple "game" for Android using Opengl ES 2.0. The gameplay consists in a moving point which accelerates or decelerates based on user input. Of course the space covered by the point in a single frame depends on the amount of time elapsed from last frame, so to calculate this space i multiply the speed of the point and this amount of time.

I also have a camera which moves according to my point, but I flip x and y axis in order to make the camera follow the point.

My problem is that the point (and the camera) doesn't move smoothly. By the way I don't get why, since FPS are always 60 or at least 55 (I check them through an external app).

If I use always the same amount of time between a frame and the next all is smooth.

By the way, in order to understand what is wrong I built a very simple FPS counter and I log FPS (or elapsed time) through Log.d. Here I noticed that values vary between 45 and 80 FPS. Now, I think that if I could lock this value to a maximum of 60 (which is most smartphones screen refresh rate), then the movement would be way more smooth. So my question is: how can I avoid my app draws a frame before 0.0166 seconds elapsed from last frame?

Thanks for reading and sorry for my english!

Upvotes: 0

Views: 364

Answers (1)

solidpixel
solidpixel

Reputation: 12084

Here I noticed that values vary between 45 and 80 FPS.

The graphics subsystem will return a buffer to the application as soon as one is available, so with triple buffering the frame time measured on the CPU can be a little unpredictable as the application is not running tightly locked with the compositor and CPU time can move about due to CPU frequency changes.

In general the display update will be capped at 60 FPS but because your animation is based on the elapsed frame time you are seeing on at the API level (which is decoupled from the actual display update) you are animating each frame as if it were 45 FPS or 80 FPS which isn't what actually appears on screen.

If you know you are close to 60 FPS, I'd try something like averaging the elapsed time over the last 3 frames, and using that timestep as your animation update rate. This should remove most of the jitter caused by buffer skid, at the expense of a little latency to reacting to large workload changes.

Upvotes: 1

Related Questions