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).
Related
I handle my onTouchEvent like this:
public boolean onTouchEvent(MotionEvent event)
{
queueEvent(new Runnable(){
public void run(){
mRenderer.onTouchEvent(event);
}
});
return true;
}
I have to queue the call into my GL Thread because I want to update most of the stuff only if the user touches and game related stuff changes.
However the queueEvent solution seems to be a bit slow. It takes 10-15ms between the onTouchEvent at the MainActivity and the onTouchEvent at my Renderer. Is it possible to achieve lower delays without passing the onTouchEvent directly?
If you think about it this way, 10-15 ms means that you will be able to draw the next frame from the current user input. At 60fps (android default), it's 16 ms between each frame. It has to synchronize the input with the renderer and it cannot interfere at any time. Of course, you could change values inside the renderer in a synchronized way, but still, it can be only drawn in the next frame, which might take about that much time too.
I've got a problem with creating gameloop for my first game. I've read a lot about it but still can't figure it out. It's based on OpenGL so I've used onDrawFrame as a game loop and it works fine on my phone. Problem is that onDrawFrame is refresh time depends on hardware so it runs way too fast on some devices. So what I want is adding a separate game loop that will refresh itself at constant period of time on all smartphones. (and onDrawFrame will only take care of graphics as it should)
As for now I have:
myGameRenderer class with all openGl stuff an onDrawFrame
myGLSurfaceView that supports touch events
myGameActivity
onDrawFrame activates myGameUpdate function that controls changing positions of all objects in game depending on info from myGLSurfaceView
I've tried with creating new Runnable but it doesn't seem to work, I can't figure out how to start that runnable and where i should place it (I've tried to place it in myGameRenderer class, but it didn't seem to work, nothing was moving:
private final Runnable mUpdateDisplay = new Runnable() {
#Override
public void run() {
update();
}};
private void update() {
//some update stuff blablabla
//some update stuff blablabla
mHandler.postDelayed(mUpdateDisplay,40); //to refresh at 25 fps
}
but I guess I don't get the idea of it - I mean I create this runnable.
I've tried to place it in onCreateSurface to start it but no effect.
So - is the generall idea ok? And how to start the loop? Where to place it? Or should I use any other way?
Ok it was simple - I was just missing r.run();
But as allways there's something. Now it works as i wanted - I mean frames doesn't depend on hardware, but everything is not as smooth as it was - and part of objects in 3d are flickering. Seems like some objects visibly are drawn faster, some later and it looks ugly.
So what am I doing wrong? Is there a better way?
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.
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.
I'm just trying to figure out the best approach for running a scolling background on an android device. The method I have so far.... its pretty laggy. I use threads, which I believe is not the best bet for android platforms
#Override
public void run() {
// Game Loop
while(runningThread){
//Scroll background down
bgY += 1;
try {
this.postInvalidate();
t.sleep(10);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
where postinvalidate in the onDraw function simply pushings the background image down
canvas.drawBitmap(backgroundImage, bgX, bgY, null);
Thanks in advance
UPDATE
I've identified the problem. And it is the fact that my player updates the same rate as the background scrolls (making it look choppy). from top to bottom. This is because both get drawn in the same function. I'm not really sure how to tackle this and would be grateful for any help. i.e so that player movement is handled separately from the map scrolling
Also how can I control the speed at which onDraw(canvas) get called?
Thanks in advance.
However, I have patched together a different run loop for anyone having the same problem. This is partially from the jetboy example on google.
Below is my inner class in my surfaceview
class MapThread extends Thread{
private Map map;
private SurfaceHolder holder;
private boolean run = false;
public MapThread(Map map, SurfaceHolder holder){
this.holder = holder;
this.map = map;
setRunning(true);
}
public void setRunning(boolean run){
this.run = run;
}
#Override
public void run(){
while(run){
try{
Canvas c = null;
try {
c = holder.lockCanvas(null);
synchronized (holder) {
map.onDraw(c);
}
} finally {
if (c != null) {
holder.unlockCanvasAndPost(c);
}
}
}
}
}
SOLUTION
https://gamedev.stackexchange.com/questions/8127/android-game-scrolling-background
Use the SurfaceView implementation draw on the screen. It allows you more control of what to draw and when.
The SurfaceView is a special subclass of View that offers a dedicated drawing surface within the View hierarchy. The aim is to offer this drawing surface to an application's secondary thread, so that the application isn't required to wait until the system's View hierarchy is ready to draw.
The basic design is to have a surfaceview that draws continuously in a while loop. Then add an if-statement whose condition is to be true if a timer thread tells you its time to draw. Say, every 30ms, draw the bitmap. This will give you about 33 fps.
Now you may also have another timer thread that tells you when to update the the bgX or bgY values. Say at every 60ms, it will set a boolean updateFlag = true; Then in your main thread, you have an if-statement check this flag, set it to false, and update your bgX and bgY values. By accurately controlling the timer and the bgX/bgY increments, you should be able to produce smooth animations.
It would be a good idea to look at the LunarLander source code provided by Google.
One thing to keep in mind is that sleep is very inaccurate. To work around this, you can keep track of exactly how much time passed during the sleep and update how much you move things accordingly.
Its not clear from you code, but you need to make sure that all of your UI updates happen in the UI thread.
You do need to do your timing outside of the UI thread, because otherwise the UI will never update. There are other methods of timing, like using a Handler that can be a little bit cleaner, but I think the overhead on them might be a bit much for what you are trying to do. I think a simple thread has the least amount of overhead.
I am using this method on the second level of my SpaceQuestAlpha game. This makes a seemless scroll.
I used the 2 lines below to set original position.
moony=0;
moon2y=-(heighty);
Then these lines increment both versions of the background image. One starts at 0 and one starts at negative screen height. Every time one of the images goes below the bottom of the screen it is moved up twice the height to move it back into position. I am using surface view with no latency issues.
moony+=5;
moon2y+=5;
if(moon2y>=heighty) {moon2y=moon2y-(heighty*2);}
canvas.drawBitmap(lavabackground, 0, moon2y, null);
if(moony>=heighty){moony=moony-(heighty*2);}
canvas.drawBitmap(lavabackground, 0, moony, null);