Performance? Tips?

Monkey Targets Forums/Android/Performance? Tips?

therevills(Posted 2011) [#1]
Anyone else getting bad performance with their Android games?

Ive just updated my Invaders game to have around 25 sprites on screen and its near enough killed it!

Any tips to increase performance


Xaron(Posted 2011) [#2]
I guess you have to avoid as much dynamic created content as possible. So any "New" will be a killer.


matt(Posted 2011) [#3]
We'd have to see your code in order to see where the bottlenecks are?


Supertino(Posted 2011) [#4]
Also what phone do you have, I have a wildfire and that is quite poor on any app. I'll upgrade to a Desire in a month when y contract is up.


BigAnd(Posted 2011) [#5]
You are not going to get massive fps on these devices. What I do on the iPhone is keep the fps to about 30 and see what sort of action I can get out of that. I am still finding my feet with Android and monkey so I am not getting the performance I was hoping for. I am sure this will change as we get to know how and when to do stuff with the language.

@therevills, can I ask, are you drawing the background image every frame and if so, what size is it?


therevills(Posted 2011) [#6]
So any "New" will be a killer.


That would suck so much if that was true! :(

We'd have to see your code in order to see where the bottlenecks are?


Have a look at Monkey Pong, that also has similar issues.

Also what phone do you have


LG Optimus One P500 - But Ive also tested on the Nexus One, the LG out performs it, which is strange since the LG has only 600Mhz CPU and the N1 has a 1Ghz CPU.

The Wildfire has a 500Mhz CPU, but also the screen res is smaller.


@therevills, can I ask, are you drawing the background image every frame and if so, what size is it?


Yes I am displaying it every frame - is there another way?
Ive tried different size backgrounds thinking it might be this, but its the same when I try 640x480 down to 320x480 - also tried 320x240.


BigAnd(Posted 2011) [#7]
On platforms like the Xbox its not good to create "new" objects all the time as it makes the garbage collector take a LOT of time, so it might be true on other platforms. Worth doing some tests.

Thanks for the background screen info. I was just thinking you might have been doing something like dirty rectangles or something else, just checking :)


therevills(Posted 2011) [#8]
Just been doing some testing:

With collisions disabled, 9 aliens, no asteroids and the player's ship (not shooting):

* DrawText on: 31-34 FPS
* DrawText off apart from the FPS Counter: 35-41 FPS

With just the player's ship:

* DrawText on: 50-55 FPS
* DrawText off apart from the FPS Counter: 53-58 FPS

With Collsions on, 9 aliens, asteroids and the player's ship (not shooting):

* DrawText on: 28-31FPS
* DrawText off apart from the FPS Counter: 35-37 FPS

I was going to add a tilemap to test game... but I dont think Ill bother now :(

And heres the source code:



degac(Posted 2011) [#9]
Why do you use SetColor?

Other questions:

when an object is removed from a list (ie: bullets, destroyed aliens...) they still lives around? I put in my code alien=NULL, bullet=NULL to be sure (I dont' really know if this is the *right* way do it or GC on different target acts in different way).

Have you tried to 'turn off' accel/touch to see how much cycles it costs?


therevills(Posted 2011) [#10]
>SetColor?

In case Monkey ever gets it for DrawImage :) I would like to make the player's ship flash red when hit.

>When an object is removed from a list...

Not sure, I'm just doing what I've done in the past using BlitzMax.

> I put in my code alien=NULL, bullet=NULL to be sure

Where do you put this code?

>Have your tried to 'turn off' accel/touch

Is there a command for this? How do you do it?


degac(Posted 2011) [#11]
About deleting object:
Once
list_bullets.Remove(e)
e=NULL

Of course I have a control If e<>NULL to check if the object exists in other loops.
I dont' know if is the 'correct' way to do it, but in my games I can have hundreds of bullets (mine and of the enemies) so somewhere this objects are...

Have your tried to 'turn off' accel/touch

No, I simply remarked the section #IF TARGET="android" to test it


therevills(Posted 2011) [#12]
Sorry degac, I was asking if you know how to turn off the accel/touch.

Even if you dont call the commands for accel/touch it seems like it is always polling for them (at least the touch command).

Check this post out:

http://www.monkeycoder.co.nz/Community/posts.php?topic=227


degac(Posted 2011) [#13]
Maybe it's possible to change mojo.android.java to 'skip' the touchEvent...
I'm not a java expert, but I think a 'global var' somewhere and a if (skip_touch==true) at the start should do the trick.

But here we need someone skilled... sorry :)




MikeHart(Posted 2011) [#14]
Like Xaron said. Pre allocate as much as possible and store it for later use. The dalvik GC is a nasty one. It can drag your framerate down very much.


degac(Posted 2011) [#15]
I'm reading this

From what I've understood create an object takes 1) time 2) involve a major work of GC (same for string for some reason...)

So one solution is to create a 'pool' of object onCreate method (an array?) with a field 'status=1/0' to understand if it is active or not (I dont' know if removing from a list or scanning an array of 100 elements has a cost or not).
I will try.


Beaker(Posted 2011) [#16]
Currently the Android mojo uses a canvas to draw with. The speed could be improved alot if it used OpenGL instead (particularly VBO buffers).


degac(Posted 2011) [#17]
I suppose Mark choosed the 'basic' canvas method because not-all Android devices support OpenGL (specially VBO).
And Canvas operation are CPU based (maybe I'm wrong or it depends on the AndroidOS version...)
After googling around I found that - practically - every games written for Android is OpenGL based... so a word from Mark about this could be interesting.


Samah(Posted 2011) [#18]
So, I messed around with the native mojo stuff (mojo.android.java) and managed get a significant performance boost.
Currently, every DrawImage call using an atlas rather than just a single frame will create a new Bitmap object to hold the source rectangle.
Android has a built-in drawBitmap call that will handle this for you without creating a new Bitmap. I've converted the code to use that call, and cached the rectangle objects, so that's at least one less new() per DrawImage. :)
Using some test code by therevills, I managed to get another 10fps back on my Nexus One, and over 20fps boost on his LG.
I've made some other minor tweaks that should help, but I won't bother posting those here just now.

Open mojo.android.java:

Find the line that says:
class gxtkGraphics{

Add this after it:
Rect srcRect = new Rect();
Rect destRect = new Rect();


Find these lines in the DrawSurface2() method:
Bitmap bitmap=Bitmap.createBitmap( surface.bitmap,srcx,srcy,srcw,srch ); 
canvas.drawBitmap( bitmap,x,y,bitmapPaint );

Replace them with these:
srcRect.left = srcx;
srcRect.top = srcy;
srcRect.right = srcx + srcw;
srcRect.bottom = srcy + srch;
destRect.left = (int)x;
destRect.top = (int)y;
destRect.right = destRect.left + srcw;
destRect.bottom = destRect.top + srch;
canvas.drawBitmap(surface.bitmap, srcRect, destRect, bitmapPaint);


Compile your app and enjoy!

@degac: In Java and many other OO languages, String is a class, not a primitive. Having said that, Dalvik should be reusing strings from the string pool whenever it can.


BigAnd(Posted 2011) [#19]
Good work Samah.

Its very good practice on Android (and iPhone) to keep as many graphics on one atlas as possible, everything if you can or split them up for say, menu and in game. So this is a great change and worthwhile doing.


degac(Posted 2011) [#20]
Holy crap!
My crappy-game is now 80-132 while before the max frame rate was 85-90!!!
Even on the emulator it runs from 14/16 to 27/29!

Big thanks!!!


therevills(Posted 2011) [#21]
Nice work Samah :)


marksibly(Posted 2011) [#22]
Hi,

Nice fix!

I wonder why I didn't notice that version of drawBitmap the first time around - I remember looking for it too.

However, everyone should be relieved to hear there is an opengl driver coming soon, and that if should be a LOT faster.


Jesse(Posted 2011) [#23]
awesome!


therevills(Posted 2011) [#24]
an opengl driver coming soon


Now this is awesome!! Any luck with the Touch slowness?


marksibly(Posted 2011) [#25]
Hi,

> Any luck with the Touch slowness?

Well, I couldn't duplicate it from your demo - firepaint didn't seem to slow down when I touched the display at all.

Also, there's not a lot I can do about it - I don't set 'touch rate' or 'enable touch' or anything, just process the touch events.

If anyone has any ideas I'm all ears though.


therevills(Posted 2011) [#26]
Ive added some more details on the bug thread:

http://www.monkeycoder.co.nz/Community/posts.php?topic=227


Tibit(Posted 2011) [#27]
an opengl driver coming soon

Awesome, I'll wait for this. Will probably solve every performance issue on Andriod atm! :)