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 > [email protected] > > > To unsubscribe from this group, send email to > > > [email protected]<android-developers%[email protected]><android-developers%2Bunsubs > [email protected]> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > -- > 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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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
