One part of my code looks like this:
public void goToMainMenu() {
Assets.LoadMenuTexutres();
Assets.unloadGameTexutres();
game.setScreen(new MainMenuScreen(game));
}
It works but when I call the method I get around .5 sec delay (because of loading Textures is heavy in OpenGL) and then I get to the MainMenuScreen but all the animation get choppy for around .3 seconds. Why do I get this choppy lag after I load assets/Textures and how do I prevent it?
Cheers!
You can use built-in AssetManager
My guess is that your delays are because of:
All the loading of textures
All the unloading of textures, and then having the garbage collector run on the now free Bitmap objects
To avoid this delay from spoiling the user experience, I suggest you move the loading and unloading into an AsyncTask, and show a ProgressDialog saying "Loading..." or something.
Related
I have ViewSwitcher with two ImageView. It has crossfade animation (as first appears, the other disappears). It is Done using AlphaAnimation, and
viewSwitcher.setInAnimation(inAlphaAnimation);
viewSwitcher.setOutAnimation(fadeAlphaAnimation);
Is very smooth and nice. But I wanted to make gif from it and so, I took screenshots from a layout to "catch frames" and created a gif from it. It is all good. But I need the animation itself to be like a gif with a frame rate, so it won't be smooth. Is it possible to heave such effect?
Thank you.
you can improve anim using hardware layers to app
http://blog.danlew.net/2015/10/20/using-hardware-layers-to-improve-animation-performance/
Hope this helps..
I searched around more and found this:
https://developer.android.com/guide/topics/graphics/prop-animation.html
Frame refresh delay: You can specify how often to refresh frames of
your animation. The default is set to refresh every 10 ms, but the
speed in which your application can refresh frames is ultimately
dependent on how busy the system is overall and how fast the system
can service the underlying timer.
I found this method that sets frame rate to all animations:
ValueAnimator.setFrameDelay(long frameDelay);
Hope this will help others)
What is the most efficient way to sleep in libGDX. In Windows there is a way to tell an application to wait for a signal from the OS to continue so that the program doesn't have to spin for a certain amount of time. Does anyone know what this is called? But more specifically does an efficient way to do this exist in libGDX or Java? I am looking to make my application have as low footprint as possible.
You can set non-continuous rendering so it only draws OpenGL frames when you explicitly request them. This could save a lot of battery if your game occasionally has a completely static screen. Call this, and the graphics will freeze:
Gdx.graphics.setContinuousRendering(false);
While in this mode, render() is only called when you call Gdx.graphics.requestRendering();. So you can put something like this right at the end of your render() method:
boolean shouldRender = (!animationsAreComplete || userJustTouchedScreen);
if (shouldRender) Gdx.graphics.requestRendering();
You can turn continous rendering back on at any time.
I am trying to make an OpenGL game which has say 3 stages: Welcome, Battle and Armor. Each stage has different logic and works with different textures.
When is the best time to load those textures, all in the beginning, or load the ones that are used by each stage when it is activated. If so, should I then delete them when switching to another stage?
If the second method is best, how can I show static splash screen (image) while loading the textures per each stage?
Well, loading texture (especially from the sd card) can take time. The reason to load them before you need them is to avoid having a loading screen between stages. If the player will often switch between stages, and your texture are not so big, you might want to load them at startup (giving the pain of waiting for the game to load only once, even if it would be longer). You have to balance your choice between the memory that is available for you, and how much you want to piss the player by interrupting him in his playing experience.
You could also distract the player by displaying a scoreboard at the end of a stage to show him how good he's just been, instead of a loading bar.
If you can anticipate when the player will soon switch to another stage, you can try to stream the texture in background a little before, but it's a lot more complicated to do (well, especially on a mobile platform), so you'd need to do some research for that.
I think you should load them only if they are needed for that stage. Why waste memory by loading textures on your Video RAM if the player may not make it to the next stage?
You can show a dialog which is custom to your needs and dismiss it when you are ready. I don't have any samples right now.
I am developing a game on android.Like tower defense.
I am using surface view.I am using some image as bitmap.(Spritesheets, tilesets, buttons, backgrounds,efects vs.)
Now images are nearly 5-6 mb.And i get this error when i run my game:
Bitmap size exceeds VM budget
19464192-byte external allocation too large for this process.
I call images like that
BitmapFactory.decodeResource(res, id)
and i put it to array.
I can't scale images.I am using all of them.
I tried that
options.inPurgeable=true;
and it work but the image is loading very slowly.I load a spritesheet with that and when it is loading, i get very very low fps.
What can I do?
I've had this problem too; there's really no solution other than to reduce the number/size of bitmaps that you have loaded at once. Some older Android devices only allocate 16MB to the heap for your whole application, and bitmaps are stored in memory uncompressed once you load them, so it's not hard to exceed 16MB with large backgrounds, etc. (An 854x480, 32-bit bitmap is about 1.6MB uncompressed.)
In my game I was able to get around it by only loading bitmaps that I was going to use in the current level (e.g. I have a single Bitmap object for the background that gets reloaded from resources each time it changes, rather than maintaining multiple Bitmaps in memory. I just maintain an int that tracks which resource I have loaded currently.)
Your sprite sheet is huge, so I think you're right that you'll need to reduce the size of your animations. Alternatively, loading from resources is decently fast, so you might be able to get away with doing something like only loading the animation strip for the character's current direction, and have him pause slightly when he turns while you replace it with the new animation strip. That might get complicated though.
Also, I highly recommend testing your app on the emulator with a VM heap set to 16mb, to make sure you've fixed the problem for all devices. (The emulator usually defaults to 24mb, so it's easy for that to go untested and generate some 1-star reviews after release.)
I am not a game dev however I would like to think I know Android enough.
Loading images of the size is almost certain to throw errors. Why are the images that file size?
There is an example at http://p-xr.com/android-tutorial-how-to-paint-animate-loop-and-remove-a-sprite/. If you notice he has an explosion sprite of only ~200Kb. Even a more detailed image would not take much more file space.
OK some suggestions:
Are you loading all your spritesheets onto a single sheet or is
each spritesheet in a seperate file? If they are all on one I would
split them up.
Lower the resolution of the images, an Android device is portable
and some only have a low resolution screen. For example the HTC
Wildfire has a resolution of 240x320 (LDPI device) and is quite a
common device. You have not stated the image dimensions so we can't be sure if this is practical.
Finally; I am not a game programmer but I found this tutorial (part of the same series) quite enlightening - http://p-xr.com/android-tutorial-2d-canvas-graphics/. I wonder if you are applying a pattern that is not appropriate for Android, however without code I cannot say.
Right something a little off topic but worth noting...
People under estimate the power of the View. While there is a certain amount of logic to using a SurfaceView, the standard View will do quite a lot on its own. A SurfaceView more often than not requires an underlying thread to run (that you will have to setup yourself) in order to make it work. A View however calls onDraw(), which can be utilized in a variety of ways including the postinvalidate() method (see What does postInvalidate() do?).
In any case it might be worth checking out this tutorial http://mindtherobot.com/blog/272/android-custom-ui-making-a-vintage-thermometer/. Personally, it was an excellent example of a custom View and what you can do with them. I rewrote a few sections and made a pocket watch app.
I have created my own canvas that has been extended from the JPanel, however I have noticed that w/ the content and so forth, that all of the sudden my FPS took a hit. I am following the swing rules from Filthy Rich Clients, by using paintComponent, creating a clip area, only redrawing what has been changed, and so forth. I have the FPS set to a constant 50 FPS, and I notice that sometimes my FPS will jump down to 31/32 FPS and go back up to 50 and so forth. While running my program it's only using about 25MB of RAM and 0 of my CPU, even when rendering. I also have OpenGL set.
Note: I have NO images, this is strictly using the shapes in Graphics.
Is there a major performance hit by drawing everything on a JPanel? Should I be extending a different component (I keep seeing Canvas component)? How "smart" is it to build a game such as tetris (or any of the other retro games) in JPanel?
It's a possibility that this is a timer issue, as I just added 100 additional painting calls and the FPS still does the 50 32/31 thing.
After much investigation I have found that the issue is not the JPanel at all. As a matter of fact, the issue is with the Timer in java. It's not 100% accurate, which has resulted in the FPS being way off. My solution to fixing this was reading this: koonsolo.com/news/dewitters-gameloop
I realise that you've found an issue with the Timer class, however I have another comment for you, which you may find useful:
You've not mentioned whether you're using the double-buffer technique. If you're not, then you may notice a FPS improvement.
Just in case you're not familiar with the technique, it involves creating a separate panel buffer, redraw your scene on this buffer, then switch this buffer with the one on the screen, etc.