Develop Reference

Animation ist only smooth when ontouchevent is called

i'm making my first 2d sidescroller game using a surfaceview and a canvas to draw things on (a lot of primitives put in different path objects).
my game loop uses fixed timesteps with linear interpolation. i don't create any objects during the game. i've been improving my code for 3 weeks now, but my animation is still not all the time smooth. it's ok, but every few seconds there are a lot of little hicks for about 1 or 2 seconds.
what i recognized is when i move my player (this means touching the screen), the little hicks disappear for as long as i touch the screen and move my player.
this means as long as ontouchevent of the surfaceview is called, the animation is smooth.
i dont understand this and i want a smooth animation. can somebody help me?

This sounds like a known issue on certain devices. See e.g.:
Android SurfaceView slows if no touch events occur
Animation glitches while rendering on SurfaceView
Android thread performance/priority on Galaxy Note 2 when screen is touched/released
The problem is that the system is aggressively reducing clock speeds to save power when it doesn't detect interaction with the user. (Qualcomm in particular seems fond of this.) The workaround is to drop frames when necessary. See this article on game loops, and a Choreographer-based trick demonstrated in Grafika's "record GL app" activity (in doFrame()).

libGDX game acting slow

I have a game, and when I get to the GameScreen, it gets extremely slow fairly quickly. On the GameScreen, if I just do nothing and watch, and the FPS drops to under 10 and stays there in around 30 seconds. I've been looking around my code, and I think I've narrowed it down to a section, but it makes no sense to me why it's not working, or how to fix it.
start_button = new TextButton("Start", Resources.getSkin());
start_button.setWidth(75);
start_button.setHeight(25);
start_button.setX(FRUSTUM_WIDTH / 10);
start_button.setY(FRUSTUM_HEIGHT / 4);
...
stage.addActor(start_button);
stage.addActor(pause_button);
stage.addActor(reset_button);
stage.addActor(platform_button);
In my GameScreen's render method, I call a method, and in that method I created four textbuttons. The section of code that seems to be the problem is the last four lines when I add the buttons to the stage. If I comment out those lines, the game works fine and the FPS is constantly 60. If I only comment out three of the lines, and add one button to the stage, the FPS will still drop to under 10, but it takes longer and eventually spikes back up to 60.
Why are those lines slowing down the game?

If you are doing all this in your Gamescreen's render method then this is your mistake.
because every time you are creating new button and adding it to the stage which is definately not good.
Every time you add something to stage its list increases and if depending on how frequent your render method is called the list increases and so is the time to process that list.
Dont forget about the garbage collector because lots of objects are being made and when garbage collector will be called your fps will definately decrease.

How does Android manage their Animations not to stutter?

Android's API 15 Animation class contain this:
public boolean getTransformation(long currentTime, Transformation outTransformation) {
... code ...
}
The method calculate the delta time and send it to an Interpolator which in turn based on the time the Animation has run, returns a value which in turn is applied to the Transformation.
When I build my own custom Views I use the post(Runnable) method and then call my logic update, invalidate and then post(Runnable) again if some condition is not met. The logic call takes 1 ms, the overriden onDraw(Canvas) also takes 1 ms. What is bugging me is the invalidate() call which often make my delta time go up to values above 40 (40 ms is 25 frames per second) and it is not advisable to get values higher than that. Using delta time to calculate where to draw the next frame often stutters and is not possible. I have to not use delta time and rely on how fast the phone can update the view individually, making it go faster and slower on different phones which is not a good idea.
SurfaceViews are something I cannot work with because their structure are not in cohesion with other Views (mostly Z depth problems).
Now to my question, how did Android solve the Animations? They do not stutter and they use delta time. Somewhere they must have some magic but I cannot seem to find where. Any help is very much appreciated.

Android: self written RotationAnimation for speedometer - performance?

I'm a step further with my speedometer, but I'm not that satisfied with my "solution".
I created my own View for displaying my Speedometer. The View extends ImageView and displays the speedometer (without the needle). When the speed is going to be updated, the needle will rotate to the current angle and the View invalidates. Now my problem is, that the needle kind of "jumps" (p.e. from 50km/h to 100km/h). Now I'd like to draw a smooth Animation over that.
A RotationAnimation rotates my whole speedometer, this is why I decided to write a new Thread which animates the needle with 30FPS and therefore calls invalidate() 30times per second. That works, but I allways have that additional Thread in the Background. When I later have more instruments than the speedometer, there are lots more Threads. Now my first Question: How performant is my solution? How many threads could be handled per Application?
My second idea is to use a SurfaceView for the needle, where I could use a RotationAnimation. But I'm not sure, whether it is possible, to show the current speed on a digital Display while the needle rotates. (p.e.: the needle animates from 50km/h to 100km/h, so it is important, that the speed on the digital display is always the same, the needle points at, and not that it always shows 50, until the needle reaches the 100, and then the digital display jumps instantly to 100).
I hope you could help me with some nice tips.
Help would be greatly appreceated

you could try to implement the Observer/Observable pattern in combination with a presenter. your "current speed" caluclation logic would update the "view-model" object which implements the observable pattern and is registered on the presenter(observer). now with every update the presenter is notified and it invalidates/repaints your view. On top you could add a"cooldown" to the presenter which prevents updates to be propagated more often than x times per second.
that would scale to whatever amount of signals and pipe all logic through your presenter class.

Timed Triggers and Animation

Can you please help me answer the following questions?
How do people usually implement a timed event in games?
Example: You reach some point in time and something happens like a new wave of enemies appears or something similar.
What is the best way to make sprite animations?
Example: Explosions in an android game.

1) Every time round your game loop you will want to record the elapsed time (or delta time.) This means you could keep track of the time past since the game start and the time it took to execute one iteration of your loop (the latter is good for time based movement.)
2) Depends really, I'm assuming this is 2D so I personally use sprite maps (google it) and then after x seconds I will change the image that is being rendered to the next on in the animation sequence. Animation sequences normally consist of "frames" and after x seconds have passed then move to the next frame

1 - Each frame/cycle of your game, record the time, then get the difference between the previous cycle's and the current cycle's time. This is how much time has elapsed since the last frame/cycle. Objects can then have timers that subtract the elapsed time each cycle, and do things when their timers are <= 0.
2 - My preference for game development is flixel, which does a lot of the dirty work for you. If you want to use pixel images instead of vector graphics, you should take a look at flixel. It has a framework that makes working with images and spritesheet animations a breeze. At the very least you can figure out how flixel handles them and write your own methods based on what you learned. If you want vector graphics, however, you'll need some other solution.