[android-developers] Re: Mulit-Touch Problems
First off, sorry for posting in this and the other thread. I was under
the impression that this thead hasn't been moderated yet. Just found
it via a search.
I informed the maker of the multitouch pong game of the problem i
encountered in his game on the droid. He was a bit surprised as he
thought he'd already solved it. Turns out the bug is also
reproduceable on the Nexus One.
I'd really love to know wheter it's my code that is doing something
stupid or the framework that has a problem somwhere. Given the logcat
output i start to suspect the later as i tried nearly everything to
get this working.
Is the description/video/source code above enough to file a bug?
On 6 Feb., 05:10, Peter Kirn peterk...@gmail.com wrote:
Mario,
I can verify this on the two Droids I have here. (Then again, I guess
that'd be ONE way to get two reliable pointers... yipes...)
What happens on the NexusOne or other Android devices that report
multiple pointers? My strong suspicion is that this is hardware -
firmware related, not Android platform-related. That raises an issue
of how even to document the problem.
Peter
On Jan 30, 7:49 am, Mario Zechner badlogicga...@gmail.com wrote:
Hi,
i'm currently investigatingmulti-touchsupport on = 2.0 devices,
testing it on a motorola milestone. Themulti-touchAPI seems to be
very well thought out and processing the respective MotionEvents is
really a piece of cake.
I want to usemulti-touchas an optional input method for a small game
i'm developing. The requirement is to detect 2 fingers on screen with
their respective x/y coordinates. Fingers will be lifted and pressed
down randomly and rapidly (rapidly ~ 500ms intervals). As mentioned
earlier, getting the data is no problem at all, here's how i do it in
my test application:
@Override
public boolean onTouch(View v, MotionEvent event)
{
int action = event.getAction();
int ptrId = event.getPointerId(0);
if(event.getPointerCount() 1)
ptrId = (action MotionEvent.ACTION_POINTER_ID_MASK)
MotionEvent.ACTION_POINTER_ID_SHIFT;
action = action MotionEvent.ACTION_MASK;
if(action 7 action 4)
action = action - 5;
if( action == MotionEvent.ACTION_DOWN )
{
for( int i = 0; i event.getPointerCount(); i++ )
{
float x = event.getX(i);
float y = event.getY(i);
touchX[event.getPointerId(i)] = (int)x;
touchY[event.getPointerId(i)] = (int)y;
}
touched[ptrId] = true;
}
if( action == MotionEvent.ACTION_MOVE )
{
for( int i = 0; i event.getPointerCount(); i++ )
{
float x = event.getX(i);
float y = event.getY(i);
touchX[event.getPointerId(i)] = (int)x;
touchY[event.getPointerId(i)] = (int)y;
}
}
if( action == MotionEvent.ACTION_UP )
{
touched[ptrId] = false;
if( event.getPointerCount() == 1 )
for( int i = 0; i 10; i++ )
touched[i] = false;
}
if( action == MotionEvent.ACTION_CANCEL )
{
touched[ptrId] = false;
if( event.getPointerCount() == 1 )
for( int i = 0; i 10; i++ )
touched[i] = false;
}
return true;
}
touchX[], touchY[] andtouch[] are fixed size arrays that store the
pointers coordinates andtouchstate. Later on i'm going to poll those
to react to player input.
Now, after some initial testing i noticed a problem when randomly
lifting and holding down 2 fingers in a random sequence. I arrived at
a small sequence that always let's me reproduce the problem:
1) (in landscape mode) hold down finger 1 on the right side of the
screen
2) hold down finger 2 on the left side of the screen and leave both
fingers on the screen for a small amount of time
3) now lift finger 1 and let it go down on the screen again
What happens is that logcat get's filled with
01-30 13:06:45.702: INFO/InputDevice(1167): Dropping bad point #0:
newY=759 closestDy=420 maxDy=420
and the coordinates of the second finger are equal to the coordinate
of the other finger on a single axis.
I'm currently downloading the android source from git to maybe figure
out
[android-developers] Re: How to achieve ultra smooth OpenGL/ES animation
I also had to fight this problem for a racing game. As Robert suggested, average your delta times, it's the only way you can smooth things out. I use a window of 5 frames per second for which i sum up the delta times and divide by the number of frames. An example 15ms, 15ms, 33ms, 15ms, 15ms will give you an average delta time of 18.6ms for frame 6. The 33ms will also influence the delta time of the next 4 frames after it. To avoid that effect you could use weighted averaging: frame delta times that are newer receive a higher weight (just an example, haven't boughtered using it) On 2 Feb., 06:55, tomei.ninge...@gmail.com tomei.ninge...@gmail.com wrote: I am already doing the animation in a time-based fashion. However, when I scroll the texture at a constant speed across the screen, I can see stuttering when the frame rate changes between 60fps and 30fps. Apparently the human eye is very good at detecting this kind of anomaly. On Feb 1, 4:35 pm, Robert Green rbgrn@gmail.com wrote: What MrChaz said. Use time-based animation and then if you want to smooth out the rough spots, you can tick using a running average. On Feb 1, 1:02 pm, MrChaz mrchazmob...@googlemail.com wrote: The easiest way to achieve a smooth rotation is to multiply the rotation amount by the time difference between the current frame and the last frame - that way the amount moved is constant over time. On Feb 1, 5:18 pm, tomei.ninge...@gmail.com tomei.ninge...@gmail.com wrote: Hello Android OpenGL/real-time gurus, I am drawing a pretty simple scene, with one large texture the about size of the screen (two triangles). I notice that the frame-rate is irregular: in most of cases, a frame finishes in 17 ms. However, in about 1 of 10 times, the frame finishes in 33ms. My guess is probably some background services need to run. However, the Linux scheduler is biased towards my FG app, so the BG services are usually starved, until they can't take it anymore and they grab the CPU from my app I am seeing stuttering in the animation. Is this due to the irregular frame rate? Should I delay each frame so that all frames are rendered with 33ms frame time? If so, what's the best technique of achieving this? Is there an API that I can call to guarantee CPU resources for the render thread I really hope Android runs on some sort of real time kernel ... Thanks! -- 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
[android-developers] Segfault in Bitmap.getPixel()
Hi,
I have a larger 512x512 32-bit ARGB Bitmap loaded from a PNG in my
application. I traverse each pixel in this bitmap as follows:
int height = bitmap.getHeight()-1;
for( int y = 0; y bitmap.getHeight(); y++ )
{
for( int x = 0; x bitmap.getWidth(); x++ )
{
int pixel = bitmap.getPixel( x, y);
collisionMap[x][height-y] = pixel != -1 ?(byte)BACKGROUND_PIXEL:
0;
}
}
I check each pixel in the bitmap for a specific color value and set a
byte in a corresponding 2D array that has the same dimensions as the
image. This works perfectly fine on my droid, on my hero as well as on
the emulator. I send the app containing this code to some other people
that have a g1 and a mytouch and there this few lines fail horribly
with a segfault:
02-01 17:47:25.532 I/ActivityManager( 74): Process
android.process.media (pid 3920) has died.
02-01 17:47:25.622 I/DEBUG ( 48): *** *** *** *** *** *** *** ***
*** *** *** *** *** *** *** ***
02-01 17:47:25.622 I/DEBUG ( 48): Build fingerprint: 'tmobile/opal/
sapphire/sapphire:1.6/DRC92/15632:user/ota-rel-keys,release-keys'
02-01 17:47:25.622 I/DEBUG ( 48): pid: 4033, tid: 4039
com.badlogic.doodleescape
02-01 17:47:25.622 I/DEBUG ( 48): signal 7 (SIGBUS), fault addr
02-01 17:47:25.622 I/DEBUG ( 48): r0 44527d84 r1 4622700a r2
0001 r3
02-01 17:47:25.622 I/DEBUG ( 48): r4 0001 r5 4622700a r6
44527d84 r7 4104be78
02-01 17:47:25.622 I/DEBUG ( 48): r8 44527d9c r9 4104be6c 10
4104be5c fp 0001
02-01 17:47:25.622 I/DEBUG ( 48): ip 4622700a sp 44527d70 lr
ad346c1f pc ad3469a0 cpsr 0030
02-01 17:47:26.242 I/DEBUG ( 48): #00 pc 000469a0 /
system/lib/libandroid_runtime.so
02-01 17:47:26.242 I/DEBUG ( 48): #01 pc 00046c1c /
system/lib/libandroid_runtime.so
02-01 17:47:26.242 I/DEBUG ( 48): #02 pc e434 /
system/lib/libdvm.so
02-01 17:47:26.252 I/DEBUG ( 48): stack:
02-01 17:47:26.252 I/DEBUG ( 48): 44527d30 ad083e1c /system/
lib/libdvm.so
02-01 17:47:26.252 I/DEBUG ( 48): 44527d34 ad0159f4 /system/
lib/libdvm.so
02-01 17:47:26.252 I/DEBUG ( 48): 44527d38 032c
02-01 17:47:26.252 I/DEBUG ( 48): 44527d3c 002a
02-01 17:47:26.252 I/DEBUG ( 48): 44527d40 0054
02-01 17:47:26.252 I/DEBUG ( 48): 44527d44 ad083e1c /system/
lib/libdvm.so
02-01 17:47:26.252 I/DEBUG ( 48): 44527d48 0064
02-01 17:47:26.262 I/DEBUG ( 48): 44527d4c 001a
02-01 17:47:26.262 I/DEBUG ( 48): 44527d50
02-01 17:47:26.262 I/DEBUG ( 48): 44527d54 4104be78
02-01 17:47:26.262 I/DEBUG ( 48): 44527d58 0001
02-01 17:47:26.262 I/DEBUG ( 48): 44527d5c 41c3a728 /system/
framework/framework.odex
02-01 17:47:26.262 I/DEBUG ( 48): 44527d60 0003
02-01 17:47:26.262 I/DEBUG ( 48): 44527d64 41c3a728 /system/
framework/framework.odex
02-01 17:47:26.262 I/DEBUG ( 48): 44527d68 df002777
02-01 17:47:26.262 I/DEBUG ( 48): 44527d6c e3a070ad
02-01 17:47:26.262 I/DEBUG ( 48): #00 44527d70 ad346999 /system/
lib/libandroid_runtime.so
02-01 17:47:26.262 I/DEBUG ( 48): 44527d74 001aae00 [heap]
02-01 17:47:26.262 I/DEBUG ( 48): 44527d78 0001
02-01 17:47:26.262 I/DEBUG ( 48): 44527d7c ad346c1f /system/
lib/libandroid_runtime.so
02-01 17:47:26.262 I/DEBUG ( 48): #01 44527d80 0027
02-01 17:47:26.262 I/DEBUG ( 48): 44527d84
02-01 17:47:26.262 I/DEBUG ( 48): 44527d88 44527dc0
02-01 17:47:26.262 I/DEBUG ( 48): 44527d8c 0004
02-01 17:47:26.262 I/DEBUG ( 48): 44527d90 ad346bed /system/
lib/libandroid_runtime.so
02-01 17:47:26.262 I/DEBUG ( 48): 44527d94 ad00e438 /system/
lib/libdvm.so
02-01 17:47:28.122 I/ActivityManager( 74): Process
com.badlogic.doodleescape (pid 4033) has died.
The bitmap is loaded successfully otherwise i'd get a
NullPointerException when requesting its height in the first line of
code. It seems that Bitmap.getPixel() fails with a segfault.
I have not the slightest clou of what is happening here. The really
frightening part is that it works on the droid,hero and emulator but
not on g1 hardware. I'd really appreciate any pointers.
--
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
[android-developers] Re: Segfault in Bitmap.getPixel()
Well, there seems to be a bug when specifying a different Format in
the Options of BitmapFactory.decodeStream(). I specified ARGB and
it didn't complain. On 2.0 it worked, on the G1/MyTouch it didn't.
Maybe i'll file a bug about this.
On 2 Feb., 15:46, Mario Zechner badlogicga...@gmail.com wrote:
Hi,
I have a larger 512x512 32-bit ARGB Bitmap loaded from a PNG in my
application. I traverse each pixel in this bitmap as follows:
int height = bitmap.getHeight()-1;
for( int y = 0; y bitmap.getHeight(); y++ )
{
for( int x = 0; x bitmap.getWidth(); x++ )
{
int pixel = bitmap.getPixel( x, y);
collisionMap[x][height-y] = pixel != -1 ?(byte)BACKGROUND_PIXEL:
0;
}
}
I check each pixel in the bitmap for a specific color value and set a
byte in a corresponding 2D array that has the same dimensions as the
image. This works perfectly fine on my droid, on my hero as well as on
the emulator. I send the app containing this code to some other people
that have a g1 and a mytouch and there this few lines fail horribly
with a segfault:
02-01 17:47:25.532 I/ActivityManager( 74): Process
android.process.media (pid 3920) has died.
02-01 17:47:25.622 I/DEBUG ( 48): *** *** *** *** *** *** *** ***
*** *** *** *** *** *** *** ***
02-01 17:47:25.622 I/DEBUG ( 48): Build fingerprint: 'tmobile/opal/
sapphire/sapphire:1.6/DRC92/15632:user/ota-rel-keys,release-keys'
02-01 17:47:25.622 I/DEBUG ( 48): pid: 4033, tid: 4039
com.badlogic.doodleescape
02-01 17:47:25.622 I/DEBUG ( 48): signal 7 (SIGBUS), fault addr
02-01 17:47:25.622 I/DEBUG ( 48): r0 44527d84 r1 4622700a r2
0001 r3
02-01 17:47:25.622 I/DEBUG ( 48): r4 0001 r5 4622700a r6
44527d84 r7 4104be78
02-01 17:47:25.622 I/DEBUG ( 48): r8 44527d9c r9 4104be6c 10
4104be5c fp 0001
02-01 17:47:25.622 I/DEBUG ( 48): ip 4622700a sp 44527d70 lr
ad346c1f pc ad3469a0 cpsr 0030
02-01 17:47:26.242 I/DEBUG ( 48): #00 pc 000469a0 /
system/lib/libandroid_runtime.so
02-01 17:47:26.242 I/DEBUG ( 48): #01 pc 00046c1c /
system/lib/libandroid_runtime.so
02-01 17:47:26.242 I/DEBUG ( 48): #02 pc e434 /
system/lib/libdvm.so
02-01 17:47:26.252 I/DEBUG ( 48): stack:
02-01 17:47:26.252 I/DEBUG ( 48): 44527d30 ad083e1c /system/
lib/libdvm.so
02-01 17:47:26.252 I/DEBUG ( 48): 44527d34 ad0159f4 /system/
lib/libdvm.so
02-01 17:47:26.252 I/DEBUG ( 48): 44527d38 032c
02-01 17:47:26.252 I/DEBUG ( 48): 44527d3c 002a
02-01 17:47:26.252 I/DEBUG ( 48): 44527d40 0054
02-01 17:47:26.252 I/DEBUG ( 48): 44527d44 ad083e1c /system/
lib/libdvm.so
02-01 17:47:26.252 I/DEBUG ( 48): 44527d48 0064
02-01 17:47:26.262 I/DEBUG ( 48): 44527d4c 001a
02-01 17:47:26.262 I/DEBUG ( 48): 44527d50
02-01 17:47:26.262 I/DEBUG ( 48): 44527d54 4104be78
02-01 17:47:26.262 I/DEBUG ( 48): 44527d58 0001
02-01 17:47:26.262 I/DEBUG ( 48): 44527d5c 41c3a728 /system/
framework/framework.odex
02-01 17:47:26.262 I/DEBUG ( 48): 44527d60 0003
02-01 17:47:26.262 I/DEBUG ( 48): 44527d64 41c3a728 /system/
framework/framework.odex
02-01 17:47:26.262 I/DEBUG ( 48): 44527d68 df002777
02-01 17:47:26.262 I/DEBUG ( 48): 44527d6c e3a070ad
02-01 17:47:26.262 I/DEBUG ( 48): #00 44527d70 ad346999 /system/
lib/libandroid_runtime.so
02-01 17:47:26.262 I/DEBUG ( 48): 44527d74 001aae00 [heap]
02-01 17:47:26.262 I/DEBUG ( 48): 44527d78 0001
02-01 17:47:26.262 I/DEBUG ( 48): 44527d7c ad346c1f /system/
lib/libandroid_runtime.so
02-01 17:47:26.262 I/DEBUG ( 48): #01 44527d80 0027
02-01 17:47:26.262 I/DEBUG ( 48): 44527d84
02-01 17:47:26.262 I/DEBUG ( 48): 44527d88 44527dc0
02-01 17:47:26.262 I/DEBUG ( 48): 44527d8c 0004
02-01 17:47:26.262 I/DEBUG ( 48): 44527d90 ad346bed /system/
lib/libandroid_runtime.so
02-01 17:47:26.262 I/DEBUG ( 48): 44527d94 ad00e438 /system/
lib/libdvm.so
02-01 17:47:28.122 I/ActivityManager( 74): Process
com.badlogic.doodleescape (pid 4033) has died.
The bitmap is loaded successfully otherwise i'd get a
NullPointerException when requesting its height in the first line of
code. It seems that Bitmap.getPixel() fails with a segfault.
I have not the slightest clou of what is happening here. The really
frightening part is that it works on the droid,hero and emulator but
not on g1 hardware. I'd really appreciate any pointers.
--
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
[android-developers] Re: OpenGL poor performance with textures?
i'm working a prototype game that has a very similar setup to yours. I have a 2048x2048 big background texture which i load in 32-bit argb mode (i have yet to discover what format to use for 16-bit rgb 565, png doesn't support it, didn't care yet though). I split up this big thing into 256x256 pixel chunks for visibility culling so i only draw those chunks on screen. Additionally i have a second layer of 256x256 chunks in 16-bit rgba for which i also do culling. i have up to 1000 sprites on the screen, those are 12by12 pixels big. The sprites each consist of 2 triangles. All sprite triangles i write into a dynamic VBO each frame which is extremely fast to my surprise (write to temporary float array then pass that to the VBO). Everything is rendered in ortho mode using pixel perfect projection except for the sprites which use a lower mipmap level due to me still not sure on how big they should get. The two layers of background use linear filtering for both min and mag. On my droid i get between 35-45fps, rendering and simulating the scene (and the simulation of the sprites takes quiet some time as it does pixel perfect collisions on a collision map of 2048x2048 bytes). On my hero i can get 60fps with the sprites turned of. The MSM7200 seems to have an optimization for axis aligned triangles in there that makes it blazingly fast. The droid gets around 50fps if i turn the sprites off. Note that i use 32-bit argb for the first layer which waste a lot of bandwidth and memory. The problem on the droid is sampling the texture. The portions of your quad that are not visible will of course not fetch any texels, try the following to see that effect: - let the quad fill the whole screen - the the quad fill 3/4 of the screen - let the quad fill 1/2 of the screen you only have 4 vertices to be transformed so you are clearly not transform bound. However, as you fill less and less space on the screen your framerate increases indicating that you are fillbound. For an ortho setup mipmapping won't help you as all texels will be fetched from the original size level 0. Linear filtering will also scrap some fps as you sample 4 textels for each pixel on screen. Nearest filtering might be the best option and will look as good as mipmapping (which is essentially linear filtering in your case) or linear filter as your quad is pixel perfect and screen aligned. Another way to reduce the texel fetch pressure is to use lower bit-depth textures, 16- bit argb or rgb565 as less bytes have to go over the bus (if they do). There is simply no way on the droid to get around the fill rate issue. Switching to compatibility density mode which is around 540x320 pixels (from the top of my head this figure is for sure not correct) will get you another 2-3fps, but compared to the native screen res it looks worse and is not worth the extra fps. From this it is clear that the problem is probably not related to actually filling the framebuffer but only to fetching texels. To summarize: - use mipmapping for scaled down quads, nearest filtering for pixel perfect screen aligned quads - use 16-bit argb/rgb textures instead of 32-bit argb textures That's all you can do. The PowerVR in the droid is a beast and will happily transform as many vertices as you throw at it, i have yet to encounter an issue with that rendering stage. Fetching texels is expensive though so avoid it at all cost :) On 1 Feb., 07:22, Robert Green rbgrn@gmail.com wrote: The texture memory copy / fill bottleneck has been fairly consistent across all chips so far. It's more pronounced on the MSM7200 chips but is clearly still there. The good news is that while you might not be able to get your upper FPS that you were hoping for, you probably will be able to get a fairly good and stable framerate with a far more complex scene. I was surprised at how no matter what I did, I couldn't get my environment rendering over 40FPS with low res textures, mipmap/nearest and no special effects, yet with a full scene of monsters, HUD, multitextured environment, weapons, explosions, fire, etc running with large textures with trilinear filtering on, I got 30FPS. Crazy, huh? I think there is a LOT going on in terms of optimizations and I wouldn't necessarily expect slowdown to be linear. On Jan 31, 10:14 pm, Federico Carnales fedecarna...@gmail.com wrote: Hi Lance, I doubt that's going to change much, I'm not doing any complex geometry or anything. Just to make sure, I removed the glClear, glActiveTexture, and glBindTexture calls from the draw method, and the performance is exactly the same. The performance hit seems to come from using heavy textures, not from excessive GL calls or state changes. Thanks, Federico On Feb 1, 12:52 am, Lance Nanek lna...@gmail.com wrote: If the final is only a non-transparent background and a couple sprites, you may actually get it to perform slightly better than the benchmark, not worse. The
[android-developers] Re: OpenGL poor performance with textures?
@Kevin I can easily see wheter something runs at 30 or 60fps. http://www.gamasutra.com/blogs/RadekKoncewicz/20100106/4021/Framerates_Do_Matter.php is an interesting article on the matter @Federico The thread over at http://groups.google.com/group/android-developers/browse_thread/thread/57afe5120c24c371# might be intersting for you. On 31 Jan., 07:55, Kevin Duffey andjar...@gmail.com wrote: I am curious..why do you need 60fps? 30fps is smooth motion to the human eye. I've seen that posted a few times now and fail to understand why 60fps is needed? Of course, I understand doing 30fps would be nice, but if I could yank more out of my game and sustain 30fps, I'd rather do that. On Sat, Jan 30, 2010 at 8:58 PM, Federico Carnales fedecarna...@gmail.comwrote: Hi all, So I'm doing some simple 2D stuff with OpenGL on Android and found the performance to be very, very poor. To give you an example, I made an app with a full screen GLSurfaceView. I loaded a 512x1024 texture (containing a 480x854 image), set up an orthogonal 2D matrix, and set it to draw a 480x854 pixel quad with that texture, using vertex and texture arrays. Lighting, dither, blending, etc. is disabled. I would expect this to run at 60fps without problem, but that simple operation already drags the frame drawing time to 19ms/frame. If I add some more small textured quads around the screen, the drawing time goes up to 22/24ms. If I enable blending it balloons to 28/30ms. This is testing on a Motorola Milestone, running 2.0.1. Is this normal? Am I doing something wrong or is it just a common problem in Android? Any advice on how to attain 60fps drawing simple textured quads in 2D using OpenGL? Thanks in advance! Regards, Federico -- 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.comandroid-developers%2bunsubscr...@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
[android-developers] Mulit-Touch Problems
Hi,
i'm currently investigating multi-touch support on = 2.0 devices,
testing it on a motorola milestone. The multi-touch API seems to be
very well thought out and processing the respective MotionEvents is
really a piece of cake.
I want to use multi-touch as an optional input method for a small game
i'm developing. The requirement is to detect 2 fingers on screen with
their respective x/y coordinates. Fingers will be lifted and pressed
down randomly and rapidly (rapidly ~ 500ms intervals). As mentioned
earlier, getting the data is no problem at all, here's how i do it in
my test application:
@Override
public boolean onTouch(View v, MotionEvent event)
{
int action = event.getAction();
int ptrId = event.getPointerId(0);
if(event.getPointerCount() 1)
ptrId = (action MotionEvent.ACTION_POINTER_ID_MASK)
MotionEvent.ACTION_POINTER_ID_SHIFT;
action = action MotionEvent.ACTION_MASK;
if(action 7 action 4)
action = action - 5;
if( action == MotionEvent.ACTION_DOWN )
{
for( int i = 0; i event.getPointerCount(); i++ )
{
float x = event.getX(i);
float y = event.getY(i);
touchX[event.getPointerId(i)] = (int)x;
touchY[event.getPointerId(i)] = (int)y;
}
touched[ptrId] = true;
}
if( action == MotionEvent.ACTION_MOVE )
{
for( int i = 0; i event.getPointerCount(); i++ )
{
float x = event.getX(i);
float y = event.getY(i);
touchX[event.getPointerId(i)] = (int)x;
touchY[event.getPointerId(i)] = (int)y;
}
}
if( action == MotionEvent.ACTION_UP )
{
touched[ptrId] = false;
if( event.getPointerCount() == 1 )
for( int i = 0; i 10; i++ )
touched[i] = false;
}
if( action == MotionEvent.ACTION_CANCEL )
{
touched[ptrId] = false;
if( event.getPointerCount() == 1 )
for( int i = 0; i 10; i++ )
touched[i] = false;
}
return true;
}
touchX[], touchY[] and touch[] are fixed size arrays that store the
pointers coordinates and touch state. Later on i'm going to poll those
to react to player input.
Now, after some initial testing i noticed a problem when randomly
lifting and holding down 2 fingers in a random sequence. I arrived at
a small sequence that always let's me reproduce the problem:
1) (in landscape mode) hold down finger 1 on the right side of the
screen
2) hold down finger 2 on the left side of the screen and leave both
fingers on the screen for a small amount of time
3) now lift finger 1 and let it go down on the screen again
What happens is that logcat get's filled with
01-30 13:06:45.702: INFO/InputDevice(1167): Dropping bad point #0:
newY=759 closestDy=420 maxDy=420
and the coordinates of the second finger are equal to the coordinate
of the other finger on a single axis.
I'm currently downloading the android source from git to maybe figure
out what's the problem but i'm afraid i'm not a kernel hacker enough
to arrive at a helpful conclusion.
Luke Hutchison posted on this list and on his web site (http://
lukehutch.wordpress.com/2010/01/06/my-multi-touch-code-ported-to-
eclair/) that he experienced similar results. The problem is also
reproduceable with his MTVisualizer application available in the
market as well as with all other multi touch games i could find on the
market. It seems that when the fingers are close on one axis the
hardware/driver/framework get's confused and sets one of the
coordinates of one of the fingers to the same value the coordinate of
the other finger has on this axis (Luke pointed that out in his posts,
i was hoping this would not be true for post G1 hardware). I wrote a
small sample application you can find at
http://code.google.com/p/android-gamedev/source/browse/trunk/src/com/badlogic/gamedev/samples/MultitouchSample.java
and prepared a video to show the problem:
http://www.youtube.com/watch?v=bvqX4EkpbNI
I'm not entirely sure wheter there's a bug in the code or wheter it is
hardware/driver related. I'd be very thankful for any comments on the
matter as the behaviour as shown in the video doesn't allow for multi-
touch controls of games as seen for example in iphone games as
minigore.
Thanks for reading,
Mario
--
You
[android-developers] Re: Motorola Droid (possible android) multi-touch bug and how to reproduce
Thanks, i stubled upon your blog today and already found a lot of usefull code there. I guess that's how you arrived at this post :) It's kind of a sad situation really. I'd love to use android to it's full potential but it seems that some things aren't just where they should be yet. Never the less, android is the way to go! On 29 Jan., 20:46, luke luke.hu...@gmail.com wrote: All these bugs (and several more you may not have discovered yet, e.g. event noise on touch up/down) are covered in excruciating detail on my blog,http://lukehutch.wordpress.com/android-stuff. The main posts you will want to read are: http://lukehutch.wordpress.com/2009/01/10/full-working-multitouch-on-...http://lukehutch.wordpress.com/2009/01/25/get-multi-touch-support-on-...http://lukehutch.wordpress.com/2010/01/06/my-multi-touch-code-ported-... These are hardware / firmware limitations and it is actually impossible to overcome them on current hardware/firmware. Some could possibly be fixed with a firmware update from synaptics though this probably won't happen (e.g. partially raising a touch point up loses one of X or Y but not the other) and some of the bugs will not be fixed without new hardware (the fact it's a 2x1D device and not a 2D device). -- Luke Hutchison On Jan 28, 7:06 pm, Mario Zechner badlogicga...@gmail.com wrote: It seems Toon Warz, another game usingmultitouchalso has some issues on N1 and Droid. Can others confirm the problem with the code posted above? Did anyone arrive at a solution? This is a pretty bad situation for game developers as nothing freaks users more out than bad controls. I think the code above is even a demo code from the android framework so i find it kinda strange that the problem didn't pop up during their testing phase. I also couldn't find any information on the logcat output telling me about the drop of a bad pointer. On 23 Jan., 19:39, mzechner mario.zech...@gmail.com wrote: I can confirm this problem using the sample code above, my own code and playing multipong. I created two videos, one showing the problem for the sample code above and one showing it in multipong. http://www.youtube.com/watch?v=865cd2Ui0Co(samplecode)http://www.yout...market) Each time thepointergo crazy LogCat displays messages tagged InputDevice saying droppingbadpointer#0, in all 3 cases (sample code, my code, multipong). ThepointerIds get mixed up, and as can be seen in the video for the sample code above the x coordinate for the secondpointeris wrong. I have a suspicion that this might be a driver related bug. In any way it makes writting games withmultitouch impossible. The bug can be reproduced by quickly tapping around and then settle with 2 digits on the screen. It does not work always but often enough to be annoying in a game with a dual analog stick setup on screen (like in my code). I hope this gets fixed asap. If more people can confirm this i file a bug athttp://b.google.com/ On 15 Jan., 21:32, Mirmathrax mirmath...@gmail.com wrote: here is in the original text from the post, this explains how to make the bug occur: 1) Touch screen with finger 1 and start doodling 2) Without removing finger 1, touch screen with finger 2 and start doodling 3) Remove finger 1 from the screen (without removing finger 2) 4) Replace finger 1 on the screen and start doodling again (never remove finger 2) 5) Voila, you will see the bug. The drawn lines for finger 1 will suddeny connect to finger 2. This is because there is a bug when the first finger is placed back down again, the event only has points for the wrong finger! Even though finger 1 went back down at a new location, the code thinks for some reason that finger 2 is the one that went back down (but it never went up). -Colin On Jan 15, 2:35 pm, rollbak roll...@gmail.com wrote: Can you please explain which the issue is? On Jan 15, 1:09 pm, Mirmathrax mirmath...@gmail.com wrote: Multi-touch API is bugged (at least on Motorola Droid). Here is a method to reproduce the error for analysis: 1) Create a new android project in Eclipse with the following fields: Project name: PointerLocation Build target: Android 2.0.1 Application Name: PointerLocation Package Name: com.example.pointerlocation Create Activity: PointerLocation 2) Copy the following code and paste this into the PointerLocation.java file that is automatically created /* * Copyright (C) 2007 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses
[android-developers] Re: OpenGL Fillrate Issues
@Ralf The code looks ok. The only differene to my code is that i don't overwrite GLSurfaceView but instead register an OnTouchListener with the surface view. Just in case, maybe you could try that as well? You example should be easily adaptable. Maybe Robert can try your code on his N1. @Kevin From what i could gather it's pretty much as you stated. Maybe Dianne could elaborate on that. Alternatively you could try to find the other threads in this group that talk about this issue in depth. On 28 Jan., 11:14, Ralf Schneider li...@gestaltgeber.com wrote: 2010/1/28 Lance Nanek lna...@gmail.com Someone in one of the past threads on this issue mentioned that overriding dispatchTouchEvent on Activity performs better than onTouchEvent on a View. It might be worth testing that if you guys are writing benchmarks anyway. Thanks for the tip! I tried it. Unfortunately it does not imporove performance significantly. I will go this route anyway. Another java codepath I can avoid... Thanks, Ralf -- 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
[android-developers] Re: OpenGL Fillrate Issues
@mrchaz I check for MB200/MB220/Behold. I use String.contains() for the behold. This is only a list for the dext/clique and behold. There might be other devices that have the same problem. Maybe Robert could share his settings. On 28 Jan., 15:15, MrChaz mrchazmob...@googlemail.com wrote: @Mario Could you do me a favour and paste in the strings you're checking when using android.os.Build.Model? I don't have access to any phones other than the G1. It would be willing to bet that the couple of comments of missing objects I've had are related to the VBO issue you mention. Maybe the things I've produced just aren't cpu intensive for me to notice the dip in frame-rate. That said I've not kept a close eye on it after I got to where it was smooth to me. On Jan 26, 9:28 pm, Mario Zechner badlogicga...@gmail.com wrote: @robert, i'd be more than willing to contribute to such a best practices/common pitfalls site for opengl and game development on android. I will also send you the code for the racer, boiled down to just rendering the racer itself so you can see and test the effect. In light racer 3d this effect is not noticeable, the same is true for first person games like toon warz. I'll check out light racer 2d. Expect an email soon :) @mrchaz you can detect on which device you are running by checking via the android.os.build.Build.Model String (writing this from the top of my head, just google for android build). I use the SimpleEglConfigChoser and don't react on specific devices apart for blur/dext/samsung behold 2 which seem to share a common bug. They report the VBO extension but throw errors when using any of the VBO related functions. Apart from that I wouldn't open that can of worms, coding up paths for individual devices that is. Also, the Pixelflinger OpebGL software renderer used in the emulator and on cyanogen mods doesn't like deleting VBO buffers and will crash (take that for your site robert :)) I will try to finish translating my android game dev tutorial to english this week (I'm pretty busy with my day to day job and releasing the full version of Newton in the moment). Maybe you, Robert, could share that on your site too. Awesome discussion so far. Keep it up On 26 Jan., 21:41, MrChaz mrchazmob...@googlemail.com wrote: Am I right in thinking that the Galaxy likes a depth of 16? I guess this might also be a good to place to ask how I'd find out the type of phone the game or whatever is running on so that I can start accounting for this stuff? On Jan 26, 1:00 am, Ralf Schneider li...@gestaltgeber.com wrote: I have just started playing around with OpenGL ES on the Nexus One. But this thread might be intresting for your problem: http://groups.google.com/group/android-developers/browse_thread/threa... The most important part might be this: 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. Regards, Ralf -- 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
[android-developers] Re: Motorola Droid (possible android) multi-touch bug and how to reproduce
It seems Toon Warz, another game using multitouch also has some issues
on N1 and Droid. Can others confirm the problem with the code posted
above? Did anyone arrive at a solution? This is a pretty bad situation
for game developers as nothing freaks users more out than bad
controls. I think the code above is even a demo code from the android
framework so i find it kinda strange that the problem didn't pop up
during their testing phase. I also couldn't find any information on
the logcat output telling me about the drop of a bad pointer.
On 23 Jan., 19:39, mzechner mario.zech...@gmail.com wrote:
I can confirm this problem using the sample code above, my own code
and playing multipong. I created two videos, one showing the problem
for the sample code above and one showing it in multipong.
http://www.youtube.com/watch?v=865cd2Ui0Co(sample
code)http://www.youtube.com/watch?v=glNWToF6aOI(multipong from market)
Each time thepointergo crazy LogCat displays messages tagged
InputDevice saying droppingbadpointer#0, in all 3 cases (sample
code, my code, multipong). ThepointerIds get mixed up, and as can be
seen in the video for the sample code above the x coordinate for the
secondpointeris wrong. I have a suspicion that this might be a
driver related bug. In any way it makes writting games with multitouch
impossible.
The bug can be reproduced by quickly tapping around and then settle
with 2 digits on the screen. It does not work always but often enough
to be annoying in a game with a dual analog stick setup on screen
(like in my code).
I hope this gets fixed asap. If more people can confirm this i file a
bug athttp://b.google.com/
On 15 Jan., 21:32, Mirmathrax mirmath...@gmail.com wrote:
here is in the original text from the post, this explains how to make
the bug occur:
1) Touch screen with finger 1 and start doodling
2) Without removing finger 1, touch screen with finger 2 and
start doodling
3) Remove finger 1 from the screen (without removing finger 2)
4) Replace finger 1 on the screen and start doodling again
(never remove finger 2)
5) Voila, you will see the bug. The drawn lines for finger 1
will suddeny connect to finger 2.
This is because there is a bug when the first finger is placed back
down again, the event only has points for the wrong finger! Even
though finger 1 went back down at a new location, the code thinks for
some reason that finger 2 is the one that went back down (but it never
went up).
-Colin
On Jan 15, 2:35 pm, rollbak roll...@gmail.com wrote:
Can you please explain which the issue is?
On Jan 15, 1:09 pm, Mirmathrax mirmath...@gmail.com wrote:
Multi-touch API is bugged (at least on Motorola Droid). Here is a
method to reproduce the error for analysis:
1) Create a new android project in Eclipse with the following fields:
Project name: PointerLocation
Build target: Android 2.0.1
Application Name: PointerLocation
Package Name: com.example.pointerlocation
Create Activity: PointerLocation
2) Copy the following code and paste this into the
PointerLocation.java file that is automatically created
/*
* Copyright (C) 2007 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package com.example.pointerlocation;
import android.app.Activity;
import android.content.Context;
import android.graphics.Canvas;
import android.graphics.Paint;
import android.graphics.Paint.FontMetricsInt;
import android.os.Bundle;
import android.util.Log;
import android.view.MotionEvent;
import android.view.ViewConfiguration;
import android.view.WindowManager;
import android.view.VelocityTracker;
import android.view.View;
import java.util.ArrayList;
/**
* Demonstrates wrapping a layout in a ScrollView.
*
*/
public class PointerLocation extends Activity {
@Override
protected void onCreate(Bundle icicle) {
super.onCreate(icicle);
setContentView(new MyView(this));
// Make the screen full bright for this activity.
WindowManager.LayoutParams lp = getWindow().getAttributes();
lp.screenBrightness = 1.0f;
getWindow().setAttributes(lp);
}
public static class PointerState {
[android-developers] Re: OpenGL Fillrate Issues
@Ralf i started testing on my gf's htc hero today and am getting some strange results now as well concerning touch. First of all, the game i'm working on will have the player constantly touch the screen more or less (as oposed to for example replica island). As it is good practice i insert a Thread.sleep(16) in my onTouch method when an MotionEvent.ACTION_MOVE is triggered. This does absolutely not solve the flooding issues of MotionEvents. Additionally as new MotionEvents are generated permanently as long as the finger is on the screen the garbage collector kicks in. This is on the latest HTC Hero ROM which is Android 1.5 afaik. I had a look at the MotionEvent implementation and it pretty much explains the memory leak (see MotionEvent.obtain ()). The trick with recycle gets rid of the garbage collector calls but wrecks havok with the event queue as Dianne stated. There doesn't seem to be an obvious solution and a lot of googling was rather inconclusive. Robert has the same problems on G1 level hardware with Android 2.0. I notice the same effect in other twitch games like Radiant. I guess that forces me to go all = 2.0 for the next game. I don't want angry players shouting at me calling me incompetent when it's really a problem with the Android framework (not that i implement everything perfectly, far from it :). In short Android is awesome i just wished it was more game dev friendly). On Jan 28, 4:24 pm, Mario Zechner badlogicga...@gmail.com wrote: @mrchaz I check for MB200/MB220/Behold. I use String.contains() for the behold. This is only a list for the dext/clique and behold. There might be other devices that have the same problem. Maybe Robert could share his settings. On 28 Jan., 15:15, MrChaz mrchazmob...@googlemail.com wrote: @Mario Could you do me a favour and paste in the strings you're checking when using android.os.Build.Model? I don't have access to any phones other than the G1. It would be willing to bet that the couple of comments of missing objects I've had are related to the VBO issue you mention. Maybe the things I've produced just aren't cpu intensive for me to notice the dip in frame-rate. That said I've not kept a close eye on it after I got to where it was smooth to me. On Jan 26, 9:28 pm, Mario Zechner badlogicga...@gmail.com wrote: @robert, i'd be more than willing to contribute to such a best practices/common pitfalls site for opengl and game development on android. I will also send you the code for the racer, boiled down to just rendering the racer itself so you can see and test the effect. In light racer 3d this effect is not noticeable, the same is true for first person games like toon warz. I'll check out light racer 2d. Expect an email soon :) @mrchaz you can detect on which device you are running by checking via the android.os.build.Build.Model String (writing this from the top of my head, just google for android build). I use the SimpleEglConfigChoser and don't react on specific devices apart for blur/dext/samsung behold 2 which seem to share a common bug. They report the VBO extension but throw errors when using any of the VBO related functions. Apart from that I wouldn't open that can of worms, coding up paths for individual devices that is. Also, the Pixelflinger OpebGL software renderer used in the emulator and on cyanogen mods doesn't like deleting VBO buffers and will crash (take that for your site robert :)) I will try to finish translating my android game dev tutorial to english this week (I'm pretty busy with my day to day job and releasing the full version of Newton in the moment). Maybe you, Robert, could share that on your site too. Awesome discussion so far. Keep it up On 26 Jan., 21:41, MrChaz mrchazmob...@googlemail.com wrote: Am I right in thinking that the Galaxy likes a depth of 16? I guess this might also be a good to place to ask how I'd find out the type of phone the game or whatever is running on so that I can start accounting for this stuff? On Jan 26, 1:00 am, Ralf Schneider li...@gestaltgeber.com wrote: I have just started playing around with OpenGL ES on the Nexus One. But this thread might be intresting for your problem: http://groups.google.com/group/android-developers/browse_thread/threa... The most important part might be this: 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. Regards, Ralf -- 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
[android-developers] Re: OpenGL Fillrate Issues
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.comwrote: 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
[android-developers] Re: OpenGL Fillrate Issues
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.comwrote: 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
[android-developers] Re: OpenGL Fillrate Issues
@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
[android-developers] Re: OpenGL Fillrate Issues
@Ralf that is very strange behaviour i wouldn't expect from a Nexus One. I have to admit that i only own a Droid so i can't confirm it for the N1. Would you mind putting an apk with your test application up somewhere, for example at http://www.file-pasta.com, and add log cat output so we can observe the behaviour of your app on our devices? Additionally, if it's not to much of a hazzle you could also share the source code so we can have a look at it. On 27 Jan., 12:42, Ralf Schneider li...@gestaltgeber.com wrote: I definitely have this problem on the Nexus One. My OpenGL performance test (using JNI/NDK pumped by java GLSurfaceView) is drawing 3 rotating Quads(8-8-8 texture) - all covering the whole screen - with blending. And I get very constant 60 FPS. As soon as I touch the screen: Frame rate drops to 43 FPS until i release the finger, than it gets back to 60 FPS. I think the garbage collection is the remaining reason for the slow down on Android 2.0. The problem is less visible in a more complex scene where the initial frame rate is around 35 FPS. Touching the screen in this case does not change the frame rate significantly. 2010/1/27 Robert Green rbgrn@gmail.com @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 -- 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
[android-developers] Re: OpenGL Fillrate Issues
I did some more testing and am now calculating mean delta times for each second as well as the standard deviation of the delta times. Here's what i get for the space racer above: 01-27 15:11:42.274: DEBUG/AFX(2504): fps: 56.82312, delta: 0.016143799, mean delta: 0.01756897, stddev. delta: 0.0026706476, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:43.274: DEBUG/AFX(2504): fps: 54.986576, delta: 0.016479492, mean delta: 0.018019613, stddev. delta: 0.0038374658, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:44.290: DEBUG/AFX(2504): fps: 50.92457, delta: 0.03729248, mean delta: 0.019476827, stddev. delta: 0.0064565083, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:45.298: DEBUG/AFX(2504): fps: 53.9243, delta: 0.015136719, mean delta: 0.019114176, stddev. delta: 0.00692833, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:46.306: DEBUG/AFX(2504): fps: 52.600296, delta: 0.012298585, mean delta: 0.018918864, stddev. delta: 0.0053105806, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:47.306: DEBUG/AFX(2504): fps: 52.914413, delta: 0.01171875, mean delta: 0.018682353, stddev. delta: 0.005447507, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:48.337: DEBUG/AFX(2504): fps: 51.17586, delta: 0.030395508, mean delta: 0.019417318, stddev. delta: 0.0067782626, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:49.337: DEBUG/AFX(2504): fps: 53.930874, delta: 0.031311035, mean delta: 0.019150289, stddev. delta: 0.0061283736, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:50.345: DEBUG/AFX(2504): fps: 54.986576, delta: 0.017272947, mean delta: 0.01829478, stddev. delta: 0.0044108317, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:51.360: DEBUG/AFX(2504): fps: 55.01943, delta: 0.026489256, mean delta: 0.018075053, stddev. delta: 0.0037128378, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:52.376: DEBUG/AFX(2504): fps: 55.93651, delta: 0.026336668, mean delta: 0.017899577, stddev. delta: 0.003501554, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:53.384: DEBUG/AFX(2504): fps: 56.657646, delta: 0.016845703, mean delta: 0.017754618, stddev. delta: 0.0029748674, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:54.384: DEBUG/AFX(2504): fps: 55.919792, delta: 0.016937256, mean delta: 0.017803447, stddev. delta: 0.002930975, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:55.391: DEBUG/AFX(2504): fps: 54.774338, delta: 0.016662598, mean delta: 0.018299866, stddev. delta: 0.0052955016, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:56.407: DEBUG/AFX(2504): fps: 51.882175, delta: 0.016479492, mean delta: 0.018996684, stddev. delta: 0.005628621, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:57.415: DEBUG/AFX(2504): fps: 55.93684, delta: 0.0223999, mean delta: 0.018104045, stddev. delta: 0.0036228807, #listeners: 1, #meshes: 35, #textures: 2 01-27 15:11:58.415: DEBUG/AFX(2504): fps: 51.946102, delta: 0.011444091, mean delta: 0.019133504, stddev. delta: 0.0067592976, #listeners: 1, #meshes: 35, #textures: 2 The delta time varries between 3-6ms from frame to frame! That explains the stuttering pretty well. Now i wonder why i get such inconsistent delta times. I removed rendering the background tiles so i only render the ship which is a lousy 50 triangles big, no textures or lighting. Very strange indeed. On 27 Jan., 14:23, Mario Zechner badlogicga...@gmail.com wrote: @Ralf that is very strange behaviour i wouldn't expect from a Nexus One. I have to admit that i only own a Droid so i can't confirm it for the N1. Would you mind putting an apk with your test application up somewhere, for example athttp://www.file-pasta.com, and add log cat output so we can observe the behaviour of your app on our devices? Additionally, if it's not to much of a hazzle you could also share the source code so we can have a look at it. On 27 Jan., 12:42, Ralf Schneider li...@gestaltgeber.com wrote: I definitely have this problem on the Nexus One. MyOpenGLperformance test (using JNI/NDK pumped by java GLSurfaceView) is drawing 3 rotating Quads(8-8-8 texture) - all covering the whole screen - with blending. And I get very constant 60 FPS. As soon as I touch the screen: Frame rate drops to 43 FPS until i release the finger, than it gets back to 60 FPS. I think the garbage collection is the remaining reason for the slow down on Android 2.0. The problem is less visible in a more complex scene where the initial frame rate is around 35 FPS. Touching the screen in this case does not change the frame rate significantly. 2010/1/27 Robert Green rbgrn@gmail.com @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 -- You
[android-developers] Re: OpenGL Fillrate Issues
How does your onTouch method look like? Are you synchronizing on som
object instance?
On 27 Jan., 16:28, Ralf Schneider li...@gestaltgeber.com wrote:
2010/1/27 Mario Zechner badlogicga...@gmail.com
@Ralf
that is very strange behaviour i wouldn't expect from a Nexus One. I
have to admit that i only own a Droid so i can't confirm it for the
N1. Would you mind putting an apk with your test application up
somewhere, for example athttp://www.file-pasta.com, and add log cat
output so we can observe the behaviour of your app on our devices?
Additionally, if it's not to much of a hazzle you could also share the
source code so we can have a look at it.
Sorry, unfortunately I can not upload a test app at this point.
I just checked it again:
- The 60 FPS I reported for 3 textured full screen quads was to high. It
is more around 40 FPS (if not touching the screen).
It goes down to 35 FPS as long as I touch the screen.
- The 60 FPS I reported was from a simple colored triangle. During
touching the screen it is ca. 48 FPS.
Sorry, for the wrong numbers in my previous post.
There is a very simple test you can perform by yourself:
- On every frame [*public void onDrawFrame(GL10 gl) *] just do a glClear
like:
*gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT);*
- Measure FPS
- Touch the screen
- Measure FPS
This simple test on the N1 shows a frame rate drop while touching the
screen:
01-27 16:01:20.920: DEBUG/GGTest(21690): FPS: 60.92
01-27 16:01:21.920: DEBUG/GGTest(21690): FPS: 60.73
01-27 16:01:22.921: DEBUG/GGTest(21690): FPS: 60.83
01-27 16:01:23.930: DEBUG/GGTest(21690): FPS: 60.65
01-27 16:01:24.951: DEBUG/GGTest(21690): FPS: 43.25 # Touch Screen
01-27 16:01:25.960: DEBUG/GGTest(21690): FPS: 48.48
01-27 16:01:26.960: DEBUG/GGTest(21690): FPS: 53.60
01-27 16:01:27.980: DEBUG/GGTest(21690): FPS: 49.22
01-27 16:01:28.980: DEBUG/GGTest(21690): FPS: 46.83
01-27 16:01:29.991: DEBUG/GGTest(21690): FPS: 44.65
01-27 16:01:30.991: DEBUG/GGTest(21690): FPS: 52.82
01-27 16:01:32.000: DEBUG/GGTest(21690): FPS: 60.89 # Release Finger
01-27 16:01:33.000: DEBUG/GGTest(21690): FPS: 60.64
01-27 16:01:34.010: DEBUG/GGTest(21690): FPS: 60.71
01-27 16:01:35.011: DEBUG/GGTest(21690): FPS: 60.70
01-27 16:01:36.020: DEBUG/GGTest(21690): FPS: 60.73
..Btw: I tried a:
event.recycle();
try {
Thread.sleep(18);
} catch (InterruptedException e) {
}
... this helps nothing on the N1. So, (in this case) the problem might not
be a garbage collection issue. May be the the whole input flow is just to
bloated with to many abstraction layers.
--
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
[android-developers] Re: OpenGL Fillrate Issues
Nice, there goes another myth. I read about recycling the MotionEvent at a couple of places on the net. Thanks for clearing that up! I wonder however why it is exposed as a public method. Additionally, the semantics of onTouch allow me to return a boolean indicating that i consumed the event (or not). So my reasoning was that in case i return true from onTouch and recycle the event, everything should work out fine. Maybe add to the documentation that it should never ever be called by an application? Anyways, thanks again! (if you have the time, seeing as you are obviously responsible for this part of the framework, could you have a look at the other discussion on multi-touch over here http://groups.google.com/group/android-developers/browse_thread/thread/be4151b4bc769a0/d5ec6cdfce2025be?lnk=gstq=multitouch+bug#d5ec6cdfce2025be? :) On Jan 27, 7:17 pm, Dianne Hackborn hack...@android.com wrote: On Tue, Jan 26, 2010 at 4:20 PM, Mario Zechner badlogicga...@gmail.comwrote: 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. Oh my ghod... are you saying you are calling recycle() on the MotionEvent that is -given- to you in onMotionEvent()? Please please please do not do that, you do not own the event, and you are going to cause nasty problems if you recycle it from the caller that does own it. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: OpenGL Fillrate Issues
@Ralf that doesn't look suspicious at all. I guess we'll have to wait for Robert to chim in. On Jan 27, 7:45 pm, Mario Zechner badlogicga...@gmail.com wrote: Nice, there goes another myth. I read about recycling the MotionEvent at a couple of places on the net. Thanks for clearing that up! I wonder however why it is exposed as a public method. Additionally, the semantics of onTouch allow me to return a boolean indicating that i consumed the event (or not). So my reasoning was that in case i return true from onTouch and recycle the event, everything should work out fine. Maybe add to the documentation that it should never ever be called by an application? Anyways, thanks again! (if you have the time, seeing as you are obviously responsible for this part of the framework, could you have a look at the other discussion on multi-touch over herehttp://groups.google.com/group/android-developers/browse_thread/threa... :) On Jan 27, 7:17 pm, Dianne Hackborn hack...@android.com wrote: On Tue, Jan 26, 2010 at 4:20 PM, Mario Zechner badlogicga...@gmail.comwrote: 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. Oh my ghod... are you saying you are calling recycle() on the MotionEvent that is -given- to you in onMotionEvent()? Please please please do not do that, you do not own the event, and you are going to cause nasty problems if you recycle it from the caller that does own it. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: OpenGL Fillrate Issues
@Ralf you can find the base activity for my tutorial code at http://code.google.com/p/android-gamedev/source/browse/trunk/src/com/badlogic/gamedev/tools/GameActivity.java. Inserting fps timing should be easy. @Lance that sounds like an interesting idea. However, i suspect the flood arises at a deeper abstraction level not accesible via the java framework. On Jan 28, 1:16 am, Lance Nanek lna...@gmail.com wrote: Someone in one of the past threads on this issue mentioned that overriding dispatchTouchEvent on Activity performs better than onTouchEvent on a View. It might be worth testing that if you guys are writing benchmarks anyway. On Jan 27, 5:56 pm, Ralf Schneider li...@gestaltgeber.com wrote: Robert, yes, there is really nothing more! I have already tested with a Thread.sleep(18). This does not change the behaviour. Actually it makes other things worse. Events don't get handled in time: If you don't touch the screen for a while it's get dimmed. If I put in the Thread.sleep(...) and touch a (dimmed) screen it can take up to 3 and more seconds until it gets bright again. Without the sleep() it is reacting instantly. So I have abonomed Thread.sleep(...) and event.recycle(). I think we have to live with this behaviour. But it would be good if another one can confirm this. Especially if it is a problem with the Nexus One or Android 2.1. Can someone post its Java Framerate meassurement code and post it? Mine is in a Game-Framework (which I can not share) written in C++. With this I can prepare a simple testcase. But as I told the test is really simple: Take the code from:http://android-developers.blogspot.com/2009/04/introducing-glsurfacev... add the log output of the frame rate. Regards, Ralf 2010/1/27 Robert Green rbgrn@gmail.com So Ralf, Is that really what you have for your touch handling? Nothing - and you get that slowdown? Can you test with a Thread.sleep(16) in there? On Jan 27, 3:01 pm, Mario Zechner badlogicga...@gmail.com wrote: @Ralf that doesn't look suspicious at all. I guess we'll have to wait for Robert to chim in. On Jan 27, 7:45 pm, Mario Zechner badlogicga...@gmail.com wrote: Nice, there goes another myth. I read about recycling the MotionEvent at a couple of places on the net. Thanks for clearing that up! I wonder however why it is exposed as a public method. Additionally, the semantics of onTouch allow me to return a boolean indicating that i consumed the event (or not). So my reasoning was that in case i return true from onTouch and recycle the event, everything should work out fine. Maybe add to the documentation that it should never ever be called by an application? Anyways, thanks again! (if you have the time, seeing as you are obviously responsible for this part of the framework, could you have a look at the other discussion on multi-touch over herehttp:// groups.google.com/group/android-developers/browse_thread/threa... :) On Jan 27, 7:17 pm, Dianne Hackborn hack...@android.com wrote: On Tue, Jan 26, 2010 at 4:20 PM, Mario Zechner badlogicga...@gmail.comwrote: 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. Oh my ghod... are you saying you are calling recycle() on the MotionEvent that is -given- to you in onMotionEvent()? Please please please do not do that, you do not own the event, and you are going to cause nasty problems if you recycle it from the caller that does own it. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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.comandroid-developers%2bunsubscr...@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
[android-developers] Re: OpenGL Fillrate Issues
to not feel jerky. Well, try this here http://file-pasta.com/file/104641723/spaceracer-android.apk. Control the thrusters by any key/trackball except the home, back, search and menu key, controll the rotation of the ship by the onscreen buttons. If you are as sensible as me you will see a bit of stuttering when the ship moves in a single direction and more stuttering when the ship rotates. I draw the ship in total white so the effect is more pronounced. Now all the calculations are based on the delta time between frames. It does not matter wheter i put the physics in a seperate thread with double buffering as proposed at http://replicaisland.blogspot.com/2009/10/rendering-with-two-threads.html or do them in the GL rendering thread, the stuttering is always there. It's not the first time that i write a game using time-based movement, hell i can't even count the number of times i did that in the past already. On any Android devices i tested is the stuttering is there, leaving me with the suspicion that the multi-tasking is taking it's toll. On further inspection the delta times vary between 16 and 30 milliseconds which is the cause of the stuttering. I love Android and i was used to working with shitty hardware in my DOS days. But some things just make me go crazy. Maybe we can use this discussion thread to share best practices concerning fill-rate and other issues. On 25 Jan., 19:55, Robert Green rbgrn@gmail.com wrote: Seems like no matter what I do with the Droid/Nexus One, I don't get much over 40FPS. I'm multitexturing and drawing a full screen level with HUD on top. If I drop the texture resolutions down to crap and use all nearest neighbor filtering, I get about 40FPS. If I crank the texture resolutions (all 1K) and pop it up to trilinear filtering, I get 30-32FPS. G1 is more extreme - 35FPS on all low/nearest, 7FPS on high/trilinear. It seems then that most of these chips (MSM7200, PVR SGX530, Snapdragon) are all fill-bound in the same way. Perhaps it's a memory bandwidth issue of some sort. Are you rendering your background in an orthographic projection with the obvious stuff like lights, depth check and blend shut off? That should go really fast - much faster than what you're getting. I remember getting 60FPS on both the G1 and Droid rendering a full screen quad orthographically. BTW - I don't let my scenes get much over 2000 triangles. The MSM7200 seems to start to get vert processing slow-down around there. The SGX and Snapdragon don't seem to mind it. I'd be comfortable pushing those up to 10k triangles. Static VBOs do help a lot with the memory bottleneck. Since I can't use a vertex shader to do mesh animations, I can't use a static vbo on those but I keep the vert count super low on my animated characters so performance isn't too bad. To be honest, my biggest performance problem is simply the touch slow- down issue on Android 1.5/1.6. On Jan 24, 7:44 pm, Mario Zechner badlogicga...@gmail.com wrote: Hi, i'm currently writting a small game that uses a tile based approach to render the background. Additionally i want to zoom in and out so using the 2D texture blit extension is out of the window. The tile map is split up into different cells i use for frustum culling, similar to a quadtree but with fixed size. I really only render what can be seen from the camera (and a bit outside the borders of the view). Here's an image that should give you an idea: http://file-pasta.com/file/0/device.png Each tile is mapped to a 32x32 region in a texture atlas of size 256x256. The texture minification filter is set to mipmap-nearest, the magnification filter is set to linear. At the zoom level above the mipmap filter kicks in which should lower the pressure during sampling. The mesh for the scene above is actually several meshes (here 4, one for each partition) each containing 8x8 tiles, using 2 triangles per tile that makes 8x8x6=384 vertices. That's 384x4=1536 vertices to be transformed, which the powervr sgx 530 in my trusty milestone should handle easily. The meshes are stored in static VBOs of course. The following settings are used for the above scene: depth test disabled, dithering disabled, lighting disabled, texturing enabled, blending enabled. i even bound the texture only once in the setup code for the screenshot above. I get 35fps on my milestone in native resolution, and 36fps in compatibility mode. If i don't fill up the full screen with tiles but only half of the screen i get 50fps. again, all i do is: bind texture atlas render partition 1 render partition 2 render partition 3 render partition 4 where each partition consists of 8x8x2=96 lousy triangles. According to the specs of the chip it's capable of roughly 200mp/s. The scene above has 8x8x32x32x4=262144 pixels and i even include the ones that get culled away when the scanlines for each triangle are produced. multiply
[android-developers] Re: OpenGL Fillrate Issues
And yes, the touch slowdown also sucks a lot. I use 30ms for the racer i linked to above and it is still noticeable. On 26 Jan., 19:44, Mario Zechner badlogicga...@gmail.com wrote: I can share your experience on the Droid/Nexus One. Interestingly the HTC Hero performs better than the droid on the scene above. As for the background: yes, depth tests/writes and lighting are disabled, only alpha testing is enabled (which is a bit faster than alpha blending). A single fullscreen quad performs as you said with 60fps on MSM7200 hardware. That's probably the optimization in the chip. I was however suspecting that this optimization would also kick in for the tiles of the scene above but it doesn't seem so. Never the less i get a framerate between 40 and 50fps on the hero, while the droid struggles at ~40fps now. Lowering the texture resolution helped on the PowerVR as well as on the MSM7200, around 5fps increase. Setting the filters to near and linear yields similar relative results to yours on the PowerVR. The effect with nearest filtering is much more pronounced on the MSM7200. Which should be expected as the PowerVR has a way higher nominal fill- rate. However, only getting not even 10% of the fill-rate kinda sucks. I don't suspect that it's a bandwidth problem in the CPU-GPU direction as the textures should be stored on the graphics chip itself. I might be wrong though, that's how it works on the desktop at least. If the textures are indeed stored in system RAM than that might explain the poor sampling rates. The triangle cap at 2000 is something i tried to achieve already. It helped a bit on the MSM7200, no real difference on the PowerVR. I think i read somewhere that the vertex transforms are performed on the CPU on G1 hardware. The PowerVR should have it's own FPU or ALU. I have all my VBOs in dynamic mode at the moment, i will try to use static ones and see if that helps. There's also no difference between using fixed and floating point vertex attributes from some microbenchmarks i did (small untextured triangles, depth buffer off, lighting on, no alpha blending/testing). The bottle neck in my case is not the transformation and lighting though as far as i can tell, at least not on the PowerVR. Here's another interesting case study. I wrote a tutorial on Android Game Development for the german Android community over athttp://www.androidpit.de. You can find it athttp://www.androidpit.de/android/de/de/wiki/view/Spieleentwicklung_101. The end result of the tutorial is a small Space Invaders clone. The scene is pretty simple: http://www.androidpit.de/android/de/de/wiki/view/Datei:gameworld.png There's a total of 4x8=32 saucers displayed, each using a mesh with ~50 triangles, unindexed. That's 1600 triangles. The blocks are also rendered seperately, there's 3x5=15 of them each having 12 triangles that's another 180 triangles. The ship in the front has another 50 triangles. The background is not moving and a fullscreen quad rendered with ortho projection, depth test/write off, lighting off, alpha blending/testing off and min/mag filter set to mipmap-nearest and linear. The saucers, blocks and ship are rendered with depth test/ write on, lighting on, and for the blocks alpha blending is also on. The saucers share one texture which is bound once for rendering all of them, min/mag filter mipmap-nearest and linear. The same for the ship. The text is a couple of quads in a single VBO with a glyph texture, ortho projection, and nearest for both filters. All meshes are dynamic VBOs. For each object i do a push and pop of the model-view matrix, one glRotatef and glTranslatef call per object (saucer, block, ship). That's a shitload of JNI calls. Now, on the droid i get between 47-50fps with the above setting. My Hero can do 32fps max when all saucers are on screen. The more saucers you kill, and thus the less saucers are on the screen the better the framerate gets on the Hero. With one saucer left it's roughly 55-58fps. I got a little suspicious and disabled lighting on the Hero. Instant 60fps. So i suspect the rumor that TL is done on the CPU is true. Interestingly the matrix operations are not a problem. I can happily draw 100 objects the way i described above and still get 100fps (good for my RTS i'm working on :p). Lighting on the MSM7200 seems to be a no go. And the worst part is that i can't precalculate the vertex colors and thus the lighting for rotating objects. Sucks big times. You can find the full source code for the Space Invaders clone athttp://code.google.com/p/android-gamedev/. Now the performance on the Droid is also a little strange. So seeing that turning of the lighting didn't affect the framerate on the droid i suspected the fill-rate to be the sucker. I turned off rendering the background image, and tada instant 60fps again. This is really troublesome, especially since a friend of mine, an iphone game dev, has
[android-developers] Re: OpenGL Fillrate Issues
@robert, i'd be more than willing to contribute to such a best practices/common pitfalls site for opengl and game development on android. I will also send you the code for the racer, boiled down to just rendering the racer itself so you can see and test the effect. In light racer 3d this effect is not noticeable, the same is true for first person games like toon warz. I'll check out light racer 2d. Expect an email soon :) @mrchaz you can detect on which device you are running by checking via the android.os.build.Build.Model String (writing this from the top of my head, just google for android build). I use the SimpleEglConfigChoser and don't react on specific devices apart for blur/dext/samsung behold 2 which seem to share a common bug. They report the VBO extension but throw errors when using any of the VBO related functions. Apart from that I wouldn't open that can of worms, coding up paths for individual devices that is. Also, the Pixelflinger OpebGL software renderer used in the emulator and on cyanogen mods doesn't like deleting VBO buffers and will crash (take that for your site robert :)) I will try to finish translating my android game dev tutorial to english this week (I'm pretty busy with my day to day job and releasing the full version of Newton in the moment). Maybe you, Robert, could share that on your site too. Awesome discussion so far. Keep it up On 26 Jan., 21:41, MrChaz mrchazmob...@googlemail.com wrote: Am I right in thinking that the Galaxy likes a depth of 16? I guess this might also be a good to place to ask how I'd find out the type of phone the game or whatever is running on so that I can start accounting for this stuff? On Jan 26, 1:00 am, Ralf Schneider li...@gestaltgeber.com wrote: I have just started playing around with OpenGL ES on the Nexus One. But this thread might be intresting for your problem: http://groups.google.com/group/android-developers/browse_thread/threa... The most important part might be this: 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. Regards, Ralf -- 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
[android-developers] Re: OpenGL Fillrate Issues
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.comandroid-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
