Ok, the can be seen here:
http://pastebin.com/f3757c38c
A package is here:
http://www.file-pasta.com/file/0/TouchPerfTest.apk
The results with this Java program on the N1:
01-28 10:58:04.109: INFO/TouchPerfTest(25423): FPS: 55.82622451910052
01-28 10:58:05.129: INFO/TouchPerfTest(25423): FPS:
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
@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
2010/1/28 Mario Zechner badlogicga...@gmail.com
@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
@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
@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
@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
@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
@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-development
http://www.rbgrn.net/content/215-light-racer-3d-development-journal
@MrChaz
From my tests on 1.5 and 1.6, Thread.sleep() does not
@Kevin i wrote a small tutorial on android game dev which is available
here http://www.androidpit.de/android/de/de/wiki/view/Spieleentwicklung_101.
You can find the accompanying code here
http://code.google.com/p/android-gamedev/.
Currently there's only a german version of the tutorial, i'm
@robert. i'm curios wheter you succeeded in implementing proper
multitouch controls. I planned on going the 2.0 root myself for the
racer, having all controls on screen but that didn't work out as
expected. see this thread
@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
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
@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
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:
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 at
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
2010/1/27 Mario Zechner badlogicga...@gmail.com
How does your onTouch method look like? Are you synchronizing on som
object instance?
class EngineGLSurfaceView extends GLSurfaceView {
public EngineGLSurfaceView(Context context) {
super(context);
mRenderer = new
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
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
@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
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,
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
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:
@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
Is there any reason as to why when you touch the screen, a constant flood of
events comes in? I mean, does each event reflect a single pixel on the
screen where a touch is happening..and thus a finger that might span a
circumference of say 60 pixels, causes tons of events to come in for those
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
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
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/thread/734a5f5d8d800ef1/53104ea7d9706f37
The most important part might be this:
It seems that DEPTH_SIZE of
Very insightful post. It takes a lot of time to do all of those tests
and make all of those observations. I feel like we should assemble a
little knowledgebase containing all of this information structured
into something cohesive that developers can use. I'd be happy to host
it on
Ralf,
That is an issue if you init EGL yourself but if you use GLSurfaceView
it does get the correct value for the Droid.
On Jan 25, 7:00 pm, 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
Are you sure?
At:
http://android-developers.blogspot.com/2009/04/introducing-glsurfaceview.html
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:
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
@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
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
Mario,
There is one thing in Light Racer 3D which shows what I'm talking
about - the slow moving background. You're inside a skysphere in that
game (when advanced graphics are enabled) and it does time-based
rotation very slowly to give an effect of some sort. All of the
movement in that game
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
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
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
39 matches
Mail list logo
