@kevin wheter your game needs native code or not depends on the type of game. If you are doing animated 3D meshes, like using md2 meshes (quake 2 format) you need to write the vertex interpolation code in c if you have more than a few (==2-3 from my experience) meshes displayed. As for the overhead of calling JNI functions i'd say it's neglectable in most cases. The space invaders clone above performs a lot of calls to OpenGL matrix functions as well as mesh rendering functions and that didn't seem to bog it down the least ( a lot ~= (32+15+1)*(4+7) = 528 ) on the hero as well as on the droid.
On 27 Jan., 11:33, Mario Zechner <badlogicga...@gmail.com> wrote: > @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 > threadhttp://groups.google.com/group/android-developers/browse_thread/threa... > 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-developm... > > > @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. > > > > > .. > > ... > > 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
