Re: [android-developers] Re: Canvas performance for games

I second the OpenGL route.  It's pretty much the only thing that'll give you the performance you want.  You may also want to check:

http://www.youtube.com/watch?v=U4Bk5rmIpic 

http://www.youtube.com/watch?v=7-62tRHLcHk

On Mon, Apr 30, 2012 at 4:54 PM, Adam Ratana <adam.ratana@gmail.com> wrote:

I think going with OpenGL is likely your best bet here.  Further in the book he will have the OpenGL implementation of the same.  There is also the excellent graphic library by the same, libgdx which you might also consider using.  Another place to look is the replica island source - a fully implemented 2d game, and also look for the "sprite method test" which compares different methods of drawing sprites.

You can indeed choose to only render parts of the screen that you consider dirty, which can also help with your performance, but likely you should be able to get the performance you want with just openGL, a texture atlas and drawing it all at once.

On Sunday, April 29, 2012 12:00:45 PM UTC-4, realh wrote:

I'm new to Android and Java, learning by porting a game I wrote years
ago <http://bombz.sourceforge.net>. Based on the book "Beginning Android
Games" by Mario Zechner, I'm using the technique of creating a fixed size
android.graphics.Bitmap (640x480) in RGB_565 format, rendering the game
tile by tile to its canvas with drawBitmap(bmp, srcRect, dstRect, 0),
then blitting the 640x480 bitmap to a SurfaceView's canvas, also using
drawBitmap().  AIUI drawBitmap() will scale if necessary, but I've only
tested with 1:1 scaling on an 800x480 device, leaving a gap on the side.
All the above is done in a separate thread, using a SurfaceHolder.

It's too slow, even without the debugger attached. The test device is a
ZTE Blade. The original ran at 50fps and looked nice and smooth. I'll
probably run the Android version a bit slower to compensate for
controller difficulties, but I'd like to keep the same amount of
movement per frame. I could halve the framerate and double the movement
per frame, but I think I'd struggle to reach even 20fps, and dropping
the rate further would make it unpleasantly jerky.

I've added some basic profiling and got some average times:

Game logic: < 1ms, fine, but still a lot to be implemented
Rendering the game tile by tile: 46ms, too slow
"Blit": 8ms, not too bad but would need improving to allow time for
        all the other stuff

The core of the stage that's too slow consists of rendering tiles. Each
tile is 32x32 pixels and the game world is made up of 20x15 of them.
There's one source pixmap, also RGB_565, containing all the tiles, and
the correct 32x32 portion for each tile is obtained by the srcRect.

I don't think I could significantly improve the logic of the loop that
does the tile rendering, but I could change the paradigm so that I only
render the tiles that have changed between frames. However, the draw the
whole world on each frame technique is nice and simple and used to work
even back in the days of Acorn computers with <100MHz ARMs, and I want
to progress to writing 4 way scrolling games, where the whole screen has
to be updated every frame. And even in this one I sometimes have to
update a whole load of tiles at once when there's a big explosion chain.

So I think it's just too slow to use Canvases and Bitmaps this way. Is
the answer to my problem to use OpenGL?

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

--
~ Jeremiah:9:23-24
Android 2D MMORPG: http://solrpg.com/, http://www.youtube.com/user/revoltingx

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en