@Kevin i wrote a small tutorial on android game dev which is available here http://www.androidpit.de/android/de/de/wiki/view/Spieleentwicklung_101. You can find the accompanying code here http://code.google.com/p/android-gamedev/. Currently there's only a german version of the tutorial, i'm working on the translation to english. The code itself of course uses english for naming stuff so you should be able to follow it. It shows how to play music/sound effects, use the accelerometer and touch screen, use assets to store your game resources and how to setup a proper game loop for a small Space Invaders clone. For more game dev related info i suggest you take a look at http://www.gamedev.net, http://www.flipcode.com and http://www.gamasutra.com. Especially gamedev.net has a load of articles on various topics ranging back to 1999, so a lot of it is usefull for game dev on android.
I would not reload parts of the map during runtime. I can easily cram a 512x512 tiles big map into ram for the racer i talked about above. It's actually two layers of tiles, one for the background and one for the foreground. That should be more than enough for any kind of tile based game (yes i remember bill gates famous quote...). However, you have to split up that map into smaller chunks, say 8x8 tiles each and figure out which chunks are currently visible on screen based on the location of the camera. You only want to render those. The same is true for objects in the game. This process is called culling and it is essential to keep things smooth. As tile-based games are most often 2D you can get away with simple forms of culling, i.e. you know the size of a tile chunk on screen in pixels and simply calculated the distance to the camera to figure out if it's visible. For more elaborate maps you might have to look into frustum culling which is a bit more involved. You can find information on all relevant techiques on the sites i mentioned above. The 24mb limit was not a show stopper for me yet. 512x512 tiles can be easily stored in 512x512 bytes in a byte array. This array keeps the information on which graphical tile is used at what position, e.g. a grass tile, a stone tile and so on. You just give each tile a number and store that number for each tile in the byte array. The graphical tiles themselves should be stored in a single texture atlas (another bunch of keywords you can google for). When you construct your OpenGL geometry you do so for each chunk (8x8 tiles). You basically create 2 triangles for each tile in a chunk that form a quad. You give that two triangles texture coordinates that map to the proper graphical tile in the texture atlas. Each graphical tile in the texture atlas should be given a number. That number is stored in the byte array mentioned above. Once you are done with creating all meshes (again, look that word up if you don't know it, it's basically the geometry for the tiles) you work out the culling of each tile chunk and only draw the meshes for the chunks that are visible. tada, tile-based map rendering is done :). There's a couple of tricks you can use to speed up the culling process, e.g. quadtree (which might be a bit of overkill here). Use your favorite search engine to find out more. @MrChaz, i can confirm the problem Robert has. No matter how much i sleep in the onTouch method, the slow down is always noticeable. Other games on the market also suffer from this problem. If you take a look at Radiant for example you will notice that the bullets slow down a tiny bit when you touch the screen. The system get's flooded with touch events on 1.5/1.6. Calling MotionEvent.recycle() at the end of the onTouch method helps at least with fixing the small memory leak that occurs as a MotionEvent instance with a float array is created each time the method is called. On 27 Jan., 09:41, Robert Green <[email protected]> wrote: > @Kevin - I've written lots about this and posted code to use. Check > out the following > links:http://www.rbgrn.net/content/54-getting-started-android-game-developmenthttp://www.rbgrn.net/content/215-light-racer-3d-development-journal > > @MrChaz > From my tests on 1.5 and 1.6, Thread.sleep() does not even come close > to adequately fixing the problem. I have tried ranges from 16-1000 > and touch'n'hold still causes my game to drop from 30FPS down to 15FPS > or lower on the G1. The game suffers no such problems on the Droid > and Nexus One. I've also taken out everything but the call to sleep > (so onTouchEvent ONLY sleeps and returns) and I STILL see that > slowdown, so it's not my handling code. Also, I bound keyboard keys > to do the same things and wouldn't you know, it works perfectly, thus > proving that it's simple low-level touch code sucking up the CPU and > killing my framerate. If you don't use a sleep, it's even worse but > even with one, games will suffer. The more CPU intense your game is, > the more the frame rate will drop from touching. Like I said, I > haven't experienced any issues with framerate drop on any 2.0/2.1 > device. Only on 1.5/1.6. > > My new game, a FPS, will be requiring 2.0. It runs in 1.5 but the > user experience is bad because of that touch bug. Also, I can take > advantage of multitouch and provide a better control system this way, > further enhancing user experience. I just hope that most or all of > the existing phones get upgraded at some point in the next 2 months. > > On Jan 27, 2:26 am, MrChaz <[email protected]> wrote: > > > @Kevin > > You might want to look at the rokon engine a good basis for doing a 2D > > game as it takes care of pretty much all the rendering work. > > > @Mario > > I was hoping to avoid using the build number as that is a temporary > > fix only. > > > @Ralf > > The accepted work around for the touch slow down issue is to put a > > Thread.sleep() in the event handler to stop it getting spammed with > > events. A delay for 16ms seems to work well for most people. > > > On Jan 27, 1:00 am, Kevin Duffey <[email protected]> wrote: > > > > Is there any good resources on tile based games.. like how to construct > > > the > > > game loop, keep it time based, update frames every 16ms or so while > > > calling > > > your physics, collision detection, movement, and redrawing routines in > > > that > > > time? I would love to develop some side scroller/top down tile based games > > > with sprites, and yet I can't seem to find a good place to start. I saw > > > this > > > one google IO presentation, forget the guys name, that said on each > > > iteration you pass the time delta and always keep it time based (as > > > opposed > > > to frame based I assume) and that while some basic puzzle games can get > > > away > > > with using a canvas (GLSurfaceView??), most games would require open GL to > > > some extent. As well, I am interesting in knowing how to play background > > > music and yet still play multiple sound FX on time with no delay so that > > > when something collides, a sound plays at that exact moment, not a 1/2 > > > second later. Is there any good resources on this? I don't need to make a > > > perfect game my first time out.. just something to play with. I am also > > > curious with regards to the 24MB ram limit per app, how you make larger > > > levels without any potential delay in the game play. As the game scrolls > > > one > > > way or another (especially a top down with a large map), how do you avoid > > > the GC while loading in new tiles for the map? One thought I had was the > > > game goes online to get a map, storing it on the SD card, so as to avoid > > > using precious on-board user/app ram. I've read from various posts from > > > some > > > of you about how you try to load everything in first, don't create any > > > objects during the game loop, etc, but it seems games on the iPhone are > > > quite impressive with smooth framerates, and I am aware that we're a bit > > > limited as of yet on Android, especially with regards to the NDK layer > > > being > > > able to update video/audio buffers (or maybe I have that wrong?). > > > > As well, how important will a JIT play into games being better perofmant > > > when we finally get a JIT (and anyone know when that might be by chance?). > > > Along the same lines, can someone correct me regarding the info I think I > > > have pulled from various posts about video/audio buffers/hardware access > > > in > > > the NDK layer? Do most of these opengl/"better" games require NDK C code > > > to > > > work well? Or are most of these games using pure Java code? I am thinking > > > like Robert Green's game, and the air plane landing game (which seems like > > > there are 5 or more on the market now of almost identical game..someone > > > lifted the original code I guess?). Are they using NDK and thus I gotta > > > get > > > into that lower level to make a viable game... or is it possible to do a > > > decent side scroll/top scroller game without going to that level. > > > > In a nutshell, I don't have the talent to build high end games like > > > Assassins Creed, NBA hoops, etc form iPhone. I am not that skilled. > > > However, > > > I would love to learn, but think starting with a basic side scroller game > > > with tiles and animted sprites is a great place to start. So, any > > > references/urls/tutorials anyone can point to with some details on the > > > whole > > > game loop, how to scroll/draw tiles, update animations of sprites so they > > > look fluid as they move, and how to mix music/sounds in there? > > > > Thank you. Loving this and other game posts btw. > > > > On Tue, Jan 26, 2010 at 4:20 PM, Mario Zechner > > > <[email protected]>wrote: > > > > > I'm not Robert but I can at least confirm that a depth buffer with 24 > > > > bit is optimal for the Droid. I can also confimg that the > > > > GLSufraceView choses that depth by default when you don't set your own > > > > EGLConfigChoser. > > > > > As a side note: from robert's and my experience achieving 60fps on the > > > > droid is near impossible for any sufficiently complex game. I don't > > > > know what the N1.sports as a gpu but I suspect it to be near the > > > > PowerVR in the droid,. Combined with the high res native resolution > > > > the results should be pretty similar for both the droid and the n1. > > > > > That being said, there shouldn't be any problems with touch events on > > > > devices running android >= 2.0 as they fixed the event flood problem > > > > in that version. I couldn't see any problem in my projects that make > > > > heavy use of the touch screen on my droid. There seems to be a small > > > > memory leak in the onTouch method if you don't call event.recycle > > > > before exiting the onTouch method. > > > > > Hth > > > > On 27 Jan., 00:27, Ralf Schneider <[email protected]> wrote. : > > > > > Thanks Robert! > > > > > > These are good news. > > > > > > Since you are testing on a Droid. > > > > > Can you confirm a 24 bit depth buffer is best for the DROID under all > > > > > circumstances or is this quote nonsens: > > > > > > """ > > > > > It seems that DEPTH_SIZE of 24 is optimum on the Droid. I was kind > > > > > thrown back a bit when I picked an EGLConfig with DEPTH_SIZE of 0 or > > > > > another value (16, etc.) and rendering of a simple cube was at 40FPS. > > > > > With an EGLConfig that has a DEPTH_SIZE of 24 the cube was rendering > > > > > at 60FPS. > > > > > """ > > > > > > It would be good news if a 0 bit depth buffer is not slower than a 24 > > > > > bit > > > > > depth buffer on the Droid... > > > > > ... and I can simply forget all the hassle with the Droid! > > > > > > Besides this: I have started doing my own benchmarking. > > > > > The biggest issue I have is: If I touch the screen (on the Nexus one) > > > > frame > > > > > rate goes down from 60 FPS to ca. 43 FPS. > > > > > > The problem is: I have to use the touch screen as an input device! > > > > > So I can completly forget smooth games running with constant 60FPS! > > > > > > Well, the good news is: Because I can never reach 60FPS on an Android > > > > > OS > > > > as > > > > > long as the user touches the screen, I can use more expensive > > > > computations > > > > > for the graphics. Users will never now what they miss, basically all > > > > games > > > > > using the touch sreen will run below 45 FPS. > > > > > It's sad, anyway. > > > > > > Regards, > > > > > Ralf > > > > > > This2010/1/26 Robert Green <[email protected]> > > > > > > > Ralf, > > > > > > > I am sure. I test on the Droid all the time. I use GLSurfaceView > > > > > > and > > > > > > here is some evidence from my logging: > > > > > > > I/WorldRenderer(14187): EGL_DEPTH_SIZE = 24 > > > > > > I/WorldRenderer(14187): EGL_BUFFER_SIZE = 16 > > > > > > I/WorldRenderer(14187): EGL_RED_SIZE = 5 > > > > > > I/WorldRenderer(14187): EGL_BLUE_SIZE = 5 > > > > > > I/WorldRenderer(14187): EGL_GREEN_SIZE = 6 > > > > > > I/WorldRenderer(14187): EGL_ALPHA_SIZE = 0 > > > > > > D/WorldRenderer(14187): OpenGL Surface Changed to (854x480) > > > > > > D/CameraMan(14187): Aspect Ratio = 1.7791667 > > > > > > > On Jan 26, 1:48 pm, Ralf Schneider <[email protected]> wrote: > > > > > > > Are you sure? > > > > > > > > At: > > > > > >http://android-developers.blogspot.com/2009/04/introducing-glsurfacev. > > > > .. > > > > > > > there is the "Trackback": "Droid can't" at the end of the page, > > > > pointing > > > > > > to: > > > > > > > >http://freeopenidea.blogspot.com/2009/11/droidcant.html > > > > > > > > so it seems the EGL configChooser supplied with the SDK is no so > > > > good: > > > > >http://gitorious.org/0xdroid/frameworks_base/blobs/93f411386a570082f2... > > > > > > > > ... it does not check for: "EGL10.EGL_NONE" which means it might > > > > return a > > > > > > > config with an " EGL10.EGL_CONFIG_CAVEAT". > > > > > > > > 2010/1/26 Robert Green <[email protected]> > > > > > > > > > Ralf, > > > > > > > > > That is an issue if you init EGL yourself but if you use > > > > GLSurfaceView > > > > > > > > it does get the correct value for the Droid. > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "Android Developers" group. > > > > > > To post to this group, send email to > > ... > > Erfahren Sie mehr » -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
