Archive

Posts Tagged ‘android’

Android SoundPool Bug – still no fix

March 2nd, 2012 1 comment

I had to remove certain devices from the availability list in the Android Market to prevent “bad reviews”. The SoundPool Bug from June 2012 is still not fixed and has now around 100 Comments in the Bug Tracker from other Developers. So feel free to push this Bug for getting more Attention.

Meanwhile I’m thinking of rewriting the SoundPool myself and distribute a free SoundPool Library. I keep you posted.

Tower Defense Reviews

May 21st, 2011 9 comments

Recently i got my first review from a Swiss mobile online magazine. I think it’s a good read if you are familiar with reading German. You’ll find it here: pocket.ch Even though there are some complains about better graphics in the comments I think you’ll never get rid of people having different opinions about things. You’ll measured against everything out there, regardless if you single handed created every pixel and line of code in the game, or if you are a game company. Anyway, there are some things I’ll take care of in the next patch, like a small tutorial, or maybe a feedback button.

When it comes to the android market, the reviews are “ok” currently. There are some people off-voting you game in the market while barely playing more than 1 minute, or complaining why the full version is not free. Metaphorically translated to a real life situation you could sit in a bar and complaining to a waitress why you drink costs 4$ while you mother at home don’t charge you for anything 😉

 

Reviews:

Review (german) from AppyouAndroid: Rating 17/20  ( –> Link)

Review (german) from Pocket.ch: Rating 5/5 ( –> Link)

 

How does your developer notes look like ?

April 20th, 2011 No comments

Some “weeks” ago I bought some cork plates for my personal “wall of brain-damage”. Don’t know if you can comprehend this, but when it comes to game logic sometimes your brain can follow anymore. My workaround is to visualize things that are a little more complex, so i began to work with excel or small hand-drawings. After my recent Tower Defense game I will offer you my final boad status.

Especially interesting is the Diagram at the center / bottom of the picture. This is the “curve of difficulty” in the game…so the first 1-50 level are more or less casual, but after that it’s getting pretty messy

Tower Defense Game for Android

April 9th, 2011 1 comment

So the game is near completion an only a few days to the release. Take a look at the Game Page and let me know how you like it. Nearly 14.000 Lines of Code, over 400 unique created images / animations / sounds. This should at least last for yome hours of mayhem on your android device.




I just created a Facebook Page for all that may contribute rather on Facebook. I’m very interested in Feedback or Ideas how to improve the game, so doon’t hesitate in writing me a mail or contact me on Facebook.

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.

Resolution Breakdown on Android Displays

March 29th, 2011 1 comment

You’ll find a couple of “not that official” Numbers on Phone Specs across the Market. Following Diagram is a rough statistic snapshot over ~35.000 Devices End of 2010.

For my game this is a very valuable information, because to support 800×480 and 854×480 is not a big problem, but i should think of the time i have to invest to support 480×320.

EDIT:

Google itself now has a official Site where you can check overall statistics of the android market: see http://d.android.com/resources/dashboard/screens.html

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

Let the music play…

September 3rd, 2010 1 comment

While a game consists usually of more pieces than simple code, from my point of view music and sound effects are a big part of the fun.  By testing a lot of “successful” games, i noticed that the have mostly pretty poor sound effects or music.

The reason for this could be the more or less poor implementation of MediaPlayer Capabilities in Games. As Developer you will struggle in playing multiple sounds at once, or loops that run smooth. There are several things that currently look more like a “workaround” implementation-wise, like the SoundPool.

Whatever…here are some samples of background loops it created recently, enjoy:

Loop Choir
Loop Piano
Loop E-Bass

Tags: , , ,