Archive

Posts Tagged ‘performance’

Fast Game Mathematics

April 2nd, 2011 7 comments

As for myself, I never had anything to do with game programming. I’m a normal J2EE Developer / Architect in my “real” life, working for a big IT-Company here in Germany. If you are entering game programming you have to learn to throw some common java habits overboard. Besides the “Aiming for Performance” Arcticle ” down below, there are some more technical issues that can speed up your game. A good starting point is a wiki article about fast square roots (Link). The thing with the square roots is especially interesting if you are going 3D.

Another aspect is the Math factor.

int result = inputInt / 2;
int result2 = inputInt >> 1;

If you have some division by the power of 2, then you can simple shift the bits. In my TestCase this is like 8x faster than the standard division. Another useful approach are Data Tables, when you don’t need exact values. If you are calculating angles with Math.tan() or something similar, you might want to consider to pre calculate the angles your need for your game. In my case the rotation of arrows in 10 degree steps. So the only thing you have to to is to divide the cathetus and search for a Number in the table. In my case 5x times faster that Java Math.

Performance in 2D Canvas App / Game on Android

December 4th, 2010 3 comments

While I was reviewing a lot of game-code and examples, I learned a lot by mistake. Before you are running in similar problems i have summed up some information that might be interesting.

Common Advices:

  • Strings are bad. Because as you might know Strings are immutable. So if you have Methods like setText(“foo”) in combination with a frame-drawing Method you might ask yourself why the Garbage Collector is Running all the Time and Cleaning up thousands of Objects.
  • String-Objects are not the only Objects that accidentally allocated at run-time. You should aim for a Zero-Garbage-Collection Approach. I know that you might have to break some rules that may be strange, but if you are aiming for a animated Game on a Canvas Surface, you won’t be happy with the GC running while animations taking place.
  • Stop Allocating stuff. ArrayLists, Hashmaps, are Bad. Enumerations are bad, Collections in general are bad. Mostly because they are implicitly allocation memory by making shadow copies of themselves, or other strange stuff you don’t want happening at run-time.
  • You will read a lot about multi-threading Games. This might be true for OpenGL Games, because while the GPU is flushing the graphics to the surface you can calculate your Game Objects in parallel. For a 2D Canvas Game this is not mandatory because Canvas is a CPU based drawing and you won’t see any significant benefit by Multi-threading.
  • Furthermore you can tune the Bitmaps you are Loading. In general you have to preload all your Bitmaps up in front. By default this is done in the ARGB-8888 Color Mode (32 bit). If you need a Alpha Channel you might be faster if you load the Bitmaps in 16 bit with Alpha (ARGB-4444), or the fastest way in RGB 565 (without Alpha). Your can do that with Options like this.
    private static BitmapFactory.Options sBitmapOptions    = new BitmapFactory.Options();
    sBitmapOptions.inPreferredConfig = Bitmap.Config.RGB_565;
  • Sounds: Preload everything and use the OGG Format with lowest possible settings. If you are having Files > 100kb you will run into OutOfHeadMemory Exceptions.
  • Math: If you are using Math.random() or Math.sqrt() frequently you should consider some other ways to calculate those equations. There are some other Implementations that are much faster than the standard Math tools provided by Java. (e.g google for “Fast Square Root Java”)
  • Because of the Garbage Collector you should re-implement your own Fixed-Sized-Array to avoid Collection Lists.
  • Generic Iterating is bad. Like the fancy for(int Moo: mooList) looks sexy, it creates a Iterator at Runtime that leads to : *tusch* Garbage Collection.
  • You should 100% be sure that you never ever create a Object at Runtime. This can be tricky . In my Case i want to serialize some of my Game Data and realized that Matrix() is not Serializable. Solution : Pass a static Matrix to the Method.
  • Method calls are more expensive than simply referencing the public value.
  • Method calls that Return Values should be avoided. Better provide the Method with a Reference that you want to work on. So Instead of
    public ReturnObject solveThis(123, 32);
    // better
    public void solveThis(123, 32, myObjectRef);
  • Ask yourself honestly how often you need to “update” something. Like a Score. You don’t have to update the Score 40 times / Second.
  • Filter Touch Events. If you have a Application that has to react to a push , maybe consider only to catch the UP Event. Flooding a Surface View Thread with hundreds of touch Events is not a good Idea. If you have to trace every move, you can Thread.sleep(xy) the Touch Method to prevent Flooding of Values.
  • It’s always hard to cover all possible Devices / Display Resolutions. In a Game you have to preload stuff, so you should initialize a Display Strategy first. Then load the appropriate images.

If you need more informations on certain points, or you have some good other ideads let me know.

Greets