@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 <andjar...@gmail.com> 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 <badlogicga...@gmail.com>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 <li...@gestaltgeber.com> 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 <rbgrn....@gmail.com> > > > > > 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 <li...@gestaltgeber.com> 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 <rbgrn....@gmail.com> > > > > > > > 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 > > android-developers@googlegroups.com > > > > To unsubscribe from this group, send email to > > > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > > > cr...@googlegroups.com><android-developers%2Bunsubs > > cr...@googlegroups.com> > > > > 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 android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > cr...@googlegroups.com> > > 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 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
