Re: [android-developers] Re: Canvas performance for games
Thanks, two very useful posts. I've watched both videos, and I think they're essential viewing for any Android game developer. One of the first things the book says in the chapter introducing OpenGL is that Canvas isn't fast enough for anything with much more to render than Mr Nom. I should have realised that before I started coding :-/. I'm still not sure of the best way to do the rendering. The game I'm currently writing, Bombz, has 20x15 cells rendered as 32x32 pixel tiles, but I want to reuse the engine for games with at least 32x32 cells and larger tiles, with 4-way scrolling. To support scrolling I think redrawing the whole screen on every frame is the best, if not the only, way. These games are a bit different from Replica Island because the gameplay can alter the type of tile in each cell in real time. For Bombz I still have two options: make a texture atlas of the whole level, and update tiles within the texture when necessary. But that's more difficult with separate rendering and game logic threads and I think the atlas would be far too big on the games with larger scrolling levels. So I think the best way is to have each loop of the rendering thread iterate through the visible cells and render each tile as a textured quad (I think that's right, I've barely scratched the surface of OpenGL yet). Agreed? On Mon, 30 Apr 2012 17:21:20 -0700 Miguel Morales therevolti...@gmail.com wrote: 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.rat...@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. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Canvas performance for games
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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
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.rat...@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+unsubscr...@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
