@robert. i'm curios wheter you succeeded in implementing proper multitouch controls. I planned on going the 2.0 root myself for the racer, having all controls on screen but that didn't work out as expected. see this thread http://groups.google.com/group/android-developers/browse_thread/thread/be4151b4bc769a0/d5ec6cdfce2025be?lnk=gst&q=multitouch#d5ec6cdfce2025be and the videos linked to in there for more information. All multitouch capable apps on the market suffer from this problem. I'd be very interested in your onTouch handler in case that worked out for you.
On 27 Jan., 09:41, Robert Green <rbgrn....@gmail.com> 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 <mrchazmob...@googlemail.com> 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 <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 > > ... > > 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 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
