Optimization of AndEngine game

I am using java + AndEngine in my game.

During the game i have some freezes, i looked for the information and found some steps how to optimize game performance:

  • How to finish every activity on the stack except the first in Android
  • Import project with no .project file
  • How to customize listview using baseadapter
  • Accessibility function implementation problems in Android
  • Using an empty keystore password used to be possible?
  • Difference between CMake and NDK build in android studio project
    1. Avoid GC (garbage collector) to be
      called in main action in the game:
      a)don’t create objects while gaming;
      b)don’t create unnecessary objects;
    2. Optimize code that repeats very
      often

    I followed these steps, but never the less i have some freezes during the gameplay.

    Now i am creating and loading all of the textures before the game started and don’t unload them, is it a bad idea ? How can i optimize the game proccess ?
    Maybe i have to make free all of the possible memory before main activity and then reload them after each level ?

  • How to write build time stamp into apk
  • jQuery's ajax function does not work in Android PhoneGap application
  • Facebook key hash does not match any stored key hashes
  • Android: Dx trouble writing output: already prepared
  • Android Google SignIn not working in debug mode: GoogleSignInResult is false
  • Android. Scrolling 2 listviews together
  • 6 Solutions collect form web for “Optimization of AndEngine game”

    1. Reduce texture sizes.
    2. Reduce texture switches (aka try to use spritesheets, so that the texture needs to be changed as few as possible)
    3. Use lower quality textures (RGBA4444 or RGB565 instead of RGBA8888)..
    4. Call setIgnoreUpdate where the entity doesn’t need updates.
    5. Use SpriteBatches if possible.

    FYI:
    The next version of AndEngine (coming mid december) sports GLES2 so you have a lot more possibilities to improve performance with custom Shaders and Entities.

    Also it will execute the startup pipeline (onLoadEngine/onLoadResources/onLoadScene/onLoadComplete) on the first frame of the GL-Thread, instead of blocking, on the UI-Thread (directly in onCreate).

    Also it allows you to easily offload the stages of the pipeline into Threads, without breaking the pipeline as a whole. There will be a very simple to implement subclass of BaseGameActivity that shows a determinate ProgressDialog while the stages of the pipeline are executed. Entities will pop in the as they are attached to the scene.

    In general this means, the actual loadingtimes are reduced, and more importantly, the felt loadingtimes are reducedsignificantly! Creating a loading-screen is trivially easy, as opposed to the pain it was before.

    You can increase performance using AndEngine: Using the Object Pool
    http://c0deattack.wordpress.com/2011/01/06/andengine-using-the-object-pool/

    You’re probably going to need to post some more specific information about your game but one suggestion is to make sure you are re-using sprites and objects. For example if your game has any type of object that is repeatedly generates (random flying enemies, bullets, repetetive background elements) try to think about the maximum amount of that object that you will need on the screen at one time and then create that many before game play starts, loading and resetting them as you need.

    For instance my game uses enemies that “randomly” fly in from the top of the screen. At first I was making a new enemy with each call but now I have an ArrayList that contains only 6 enemies in total which get reused and moved around hundreds of times each. This resulted in a HUGE performance gain for me, especially in longer game sessions. This is related to the GC optimization but something that you might not have though about optimizing before.

    The importance of profiling your code first before making preemptive optimizations cannot be overstated. It makes little sense to optimize all the sprites etc. if you are GPU bound (this is unlikely but as you are using GLES2.0 and the programmable pipeline, and as we don’t know how you have written the GLSL code, it’s possible).

    There are a few tools you can use for profiling, as there are different things to profile for.

    For memory profiling, you can use the DDMS and traceview to check memory allocation and how often over a specific time period the GC is being called. This SO question has details:

    How can I profile my Android app?

    Regarding the oft run code, you can always time it yourself and write the results out to the log file. Its a little labor intensive, but you probably already know where your own code is potentially slow.

    The approach I’m using is to load all needed textures before the level starts. When you go to the next level, you should unload only the textures of the objects that are not needed in the next level. Others, like scoreboard or main background should not be loaded. And of course you need to unload all your textures in your activity’s onStop.
    It’s true, that firstly you should optimize the looping code, for example, you should not access any resources during a loop, try to fetch them all before you start a loop.

    This Will definetly improve your game performance: keep the default theme from rendering all the time. Here is a tutorialhttp://www.andengine.org/forums/tutorials/andengine-performance-tip-of-the-day-t810.html

    Android Babe is a Google Android Fan, All about Android Phones, Android Wear, Android Dev and Android Games Apps and so on.