Develop Reference

Android runOnUiThread and performance

My Android App is an Open GL ES 2.0 App. For one particular scene, I am overlaying a few textViews on top of my GL Surfaceview along with the some OpenGL textured quads.
I need one of my textViews to 'flash' - I'm targeting Gingerbread, therefore, I can't use animations, so I've created a method which does this:
public void flashText(){
if(myText.getVisibility()==View.VISIBLE)
myText.setVisibility(View.GONE);
else
myText.setVisibility(View.VISIBLE);
}
Then, from my OpenGL thread, I do the following:
void updateLogic(
if (System.currentTimeMillis()>(flashTimer+250)){
flashTimer=System.currentTimeMillis();
activity.runOnUiThread(new Runnable() {
#Override
public void run() {
activity.flashText();
}
});
}
}
The above method (updateLogic) is called 60 times a second. The timer is set to 250ms, so I get a 'flashing' animation 4 times a second, - or 4 times a second, FlashText is called via runOnUiThread.
This does work, however, it affects the animation of my openGL objects enough for it to be a problem.
My question is, is there a better way to do this? (because the method I'm using is clearly not efficient enough).

how to create loading screen in libgdx?

I have a GameScreen class that renders my game.
but before starting to render the game, it needs to reading files and initializing that is time consuming.
So I need to show/render another Screen class called LoadingScreen in order to spending some time and concurrently read my files and do initializing process for my GameScreen, and after initializing completed changing the screen by calling setScreen(gameScreen).
I need to use thread for making this concurrent work, now the problem is that if I use a thread to read files and initializing; When switching to the GameScreen the openGl gives me this error:
javax.media.opengl.GLException: Error: no OpenGL buffer object appears to be bound to target 0x8892
at com.sun.opengl.impl.GLBufferSizeTracker.setBufferSize(GLBufferSizeTracker.java:118)
I am aware of not both of threads use the graphic resources simultaneously.
I have found that the problem causes with Meshes. Initializing a Mesh in initializer thread and rendering in main thread causes this error. But I don't know how to solve it.
Do you have any ideas to solve this problem?

As suggested in the comments, the AssetManager is the way to load most libGDX resources (audio, textures, etc) asynchronously while showing a splash or loading screen.
For other operations, running them in a background thread (or using one of the other Android or Java background task execution facilities) should be sufficient. To invoke libGDX routines like setScreen or others that need to be executed on the libGDX render thread, use Gdx.app.postRunnable, like this:
Gdx.app.postRunnable(new Runnable() {
#Override
public void run() {
// Do something on the main thread
myGame.setScreen(postSplashGameScreen);
}
});
Depending on the visibility of myGame and postSplashGameScreen it may be easier to construct the Runnable in a different context and then pass it over to the background thread to post when its done.

My workouround is using Actions in my loading screen method:
#Override
public void show() {
stage.addAction(Actions.sequence(Actions.delay(0.5f), action_loading_assets_and_other_stuff, Actions.delay(0.5f), action_setScreen));
}
Actions.delay(0.5f) makes the magic - game not freezing

The action delay did it for me, too. I just sequence a delayaction with 0.2f and a runnable action on the stage in the loading screens show() method. Now the loading screens render method is called a few time while while the 0.2 sec delay which draws the screen and i can proceed stuff in the runnable action.

Graphics Choppy

I was trying to make an into transition to my game by having two bitmaps slide apart, like a garage door opening from the middle and half sliding downwards and half upwards. Anyway, when I do it, it looks really choppy and the frame rate seems unstable/unreliable. Here's how I'm doing it.
public class TFView extends View{
...
public void startlevel(Canvas c){
long l =(SystemClock.currentThreadTimeMillis()-starttime)/3;//*(height/500);
if(l<1000){
c.drawBitmap(metalbottom,0,height/2+l,p);
c.drawBitmap(metaltop,0,0-l,p);}
}
public void endlevel(Canvas c){
long l =(SystemClock.currentThreadTimeMillis()-failtime)/3;
if(l>=height/2){
c.drawBitmap(metaltop, 0, 0, p);
c.drawBitmap(metalbottom, 0,height/2 , p);
}
else{
c.drawBitmap(metalbottom,0,-height/2+l,p);
c.drawBitmap(metaltop,0,height-l,p);}
}}
and i set the times for when I want to open/close the doors respectively. So what do you think I should change to make it a more smooth transition? Would converting it to surfaceview help?

I had the same problem. I know what you mean with "choppy". The animation speed is NOT consistent even though you have a time based animation i.e. you are using
SystemClock.currentThreadTimeMillis()
The choppiness is caused by currentThreadTimeMillis(). It "returns milliseconds running in the current thread". That is, when you use currentThreadTimeMillis() "time" only elapses when the current thread is RUNNING. But your renderer thread is NOT ALWAYS running - as you would expect in a multitasking environment. Thus every time the thread is not running your animation is also not "running" (time is not elapsing).
Solution: Use
SystemClock.elapsedRealtime()

I have to admit I'm not the best when it comes to animation in Android but I thought I'd contribute.
From your explanation, could you use TranslateAnimation? Your animation would then be very smooth.
As far as I'm aware, if the animations Android provides are not sufficient you should be drawing your graphics in a separate thread, implementing SurfaceView.
This may help or take a look at the Lunar Lander example.

Android OpenGL lag every x frame

I am developer of Android game.
I have create an GLSurfaceView and draw something in OnDrawFrame(GL10 gl)
like below
void OnDrawFrame(GL10 gl)
{
frame_limit_wait();
game_logic();
draw_game();
}
Everything is good, but onething is strange, when drawing n-frame(Occur at GC_EXPLICIT/paused 92ms) will cause game a bit pause, in appplication it's ok, but not in a smooth game.
Original game I was use SurfaceView and Thread update works and smooth.
If add a line below draw_game() like 'system.gc()' it seems work but I feel a bit slow.
Compare to another game engine, my game endinge is running slow.
How to resolve the latency problem ?
Edit : I have solved the issue.
Just initial native Float Buffer once, and use put and position(0) to modify the Buffer content.

The garbage collector is running and holding up your frame. I would recommend taking a close look at the code that executes in the functions frame_limit_wait(), game_logic(), and draw_game() and do everything possible to prevent initializing new objects.
The most common techniques for this include:
use fields instead of local variables
use for(int i; i < x; i++) instead of for(variable : list)
making sure no extra processing is done while drawing frames.
If that still doesn't work then you can try offloading some processing to a separate thread or consider using the NDK and writing native code. With C++ you don't have to worry about the GC at all. However both of these methods will complicate your code quite a bit.

Try running your game_logic(),draw_game() code in a separate thread so that when its waiting in frame_limit_wait() , GC can be serviced in a better way.
I mean instead of using the main thread try running your rendering/update code in seperate thread.

Preventing "flickering" when calling Drawable.draw()

I have a little experimentation app (essentially a very cut-down version of the LunarLander demo in the Android SDK), with a single SurfaceView. I have a Drawable "sprite" which I periodically draw into the SurfaceView's Canvas object in different locations, without attempting to erase the previous image. Thus:
private class MyThread extends Thread {
SurfaceHolder holder; // Initialised in ctor (acquired via getHolder())
Drawable sprite; // Initialised in ctor
Rect bounds; // Initialised in ctor
...
#Override
public void run() {
while (true) {
Canvas c = holder.lockCanvas();
synchronized (bounds) {
sprite.setBounds(bounds);
}
sprite.draw(c);
holder.unlockCanvasAndPost(c);
}
}
/**
* Periodically called from activity thread
*/
public void updatePos(int dx, int dy) {
synchronized (bounds) {
bounds.offset(dx, dy);
}
}
}
Running in the emulator, what I'm seeing is that after a few updates have occurred, several old "copies" of the image begin to flicker, i.e. appearing and disappearing. I initially assumed that perhaps I was misunderstanding the semantics of a Canvas, and that it somehow maintains "layers", and that I was thrashing it to death. However, I then discovered that I only get this effect if I try to update faster than roughly every 200 ms. So my next best theory is that this is perhaps an artifact of the emulator not being able to keep up, and tearing the display. (I don't have a physical device to test on, yet.)
Is either of these theories correct?
Note: I don't actually want to do this in practice (i.e. draw hundreds of overlaid copies of the same thing). However, I would like to understand why this is happening.
Environment:
Eclipse 3.6.1 (Helios) on Windows 7
JDK 6
Android SDK Tools r9
App is targetting Android 2.3.1
Tangential question:
My run() method is essentially a stripped-down version of how the LunarLander example works (with all the excess logic removed). I don't quite understand why this isn't going to saturate the CPU, as there seems to be nothing to prevent it running at full pelt. Can anyone clarify this?

Ok, I've butchered Lunar Lander in a similar way to you, and having seen the flickering I can tell you that what you are seeing is a simple artefact of the double-buffering mechanism that every Surface has.
When you draw anything on a Canvas attached to a Surface, you are drawing to the 'back' buffer (the invisible one). And when you unlockCanvasAndPost() you are swapping the buffers over... what you drew suddenly becomes visible as the "back" buffer becomes the "front", and vice versa. And so your next frame of drawing is done to the old "front" buffer...
The point is that you always draw to seperate buffers on alternate frames. I guess there's an implicit assumption in graphics architecture that you're always going to be writing every pixel.
Having understood this, I think the real question is why doesn't it flicker on hardware? Having worked on graphics drivers in years gone by, I can guess at the reasons but hesitate to speculate too far. Hopefully the above will be sufficient to satisfy your curiousity about this rendering artefact. :-)

You need to clear the previous position of the sprite, as well as the new position. This is what the View system does automatically. However, if you use a Surface directly and do not redraw every pixel (either with an opaque color or using a SRC blending mode) you must clear the content of the buffer yourself. Note that you can pass a dirty rectangle to lockCanvas() and it will do the union for you of the previous dirty rectangle and the one you are passing (this is the mechanism used by the UI toolkit.) It will also set the clip rect of the Canvas to be the union of these two rectangles.
As for your second question, unlockAndPost() will do a vsync, so you will never draw at more than ~60fps (most devices that I've seen have a display refresh rate set around 55Hz.)