Sorry, I gave a bit too much information and didn’t explain my point at all. I was thinking if you ran one of the OpenGL examples from Android 1.1 (the Kube demo is a good one), you could put timings in around eglSwapBuffers to see if that is sucking up all the time. If it is not that, you can then work out what it is (In Android 1.1, you have control of the draw loop. In the Kube demo, the draw loop is in GLSurfaceView.java GLThread.guardedRun()). If it turns out to be eglSwapBuffers, I’d recommend posting a message on http://groups.google.com/group/android-developers to see what Google says. Just an idea, it is definitely odd. Oh, and when you output your timings, use the Log class (apparently, using System.out.println is really slow).
It’s not caused by eglSwapBuffers or something like that. The problem is that everything runs in software mode and that consumes all the time. Even your game runs in software mode when enabling OpenGL (judging from the console output). It’s just that the software mode is fast enough to handle that game. I’ve ported one of my example programs (a simple fps world based on a pretty simple and low poly Quake3 level) for jPCT. If i do all computations and GL-calls but omit the final call to glDrawElements, i get 40-50fps on the phone. If i add the glDrawElements-call, i get 3-5fps(!!)…and that’s just for one single reason: It runs in software emulation mode even when the device could do better as it shows in the Neocore demo…and i have no idea why!?
Another indicator for software mode: The current software emulation of 1.5 has a confirmed bug in the lighting code. Lights are not transformed correctly, so vertex lighting is all screwed up in the emulation. This happens in the emulator (of course). On a real device using a real GPU, it looks fine. On the Samsung, it’s all screwed up too…because, again, it uses software emulation. If it wouldn’t be a pretty nifty device apart from that flaw, i would have already thrown it out of the window…
Well, my game does not run properly on the Android emulator (both 1.1 and 1.5) with OpenGL. So I don’t know why it would run ok on the Samsung if it was using software rendering.
Best get on the phone to Samsung and be asking them, for I expect they have the answers…
Cas 
No idea, but i’m pretty sure that it does, because it prints out these scanline messages like the emulator does. The software renderer seems to assemble an optimized scanline renderer for each texture/mode. You can easily see this when adding more textures with different blending modes. Every new combination causes a new log entry. And you only need a scanline renderer when doing software rendering…i should know, i did that long enough.
Do you know a way to query the gl driver for its or the chipsets name? That would clear things up.
About contacting Samsung: i’ll do so in two weeks when i’m back from vacation…i’m posting this on the phone right now…pretty hard…
Brilliant idea! So I did this:
Log.v("CraigsRace", "OpenGL Vendor: "+gl.glGetString(GL10.GL_VENDOR));
Log.v("CraigsRace", "OpenGL Renderer: "+gl.glGetString(GL10.GL_RENDERER));
Log.v("CraigsRace", "OpenGL Version: "+gl.glGetString(GL10.GL_VERSION));
On the Android Emulator I got this:
08-02 13:34:55.396: VERBOSE/CraigsRace(770): OpenGL Vendor: Android
08-02 13:34:55.416: VERBOSE/CraigsRace(770): OpenGL Renderer: Android PixelFlinger 1.0
08-02 13:34:55.426: VERBOSE/CraigsRace(770): OpenGL Version: OpenGL ES-CM 1.0
On my G1 I got this:
08-02 13:35:45.600: VERBOSE/CraigsRace(16375): OpenGL Vendor: QUALCOMM, Inc.
08-02 13:35:45.620: VERBOSE/CraigsRace(16375): OpenGL Renderer: Q3Dimension MSM7500 01.02.08 0 4.0.0
08-02 13:35:08.520: VERBOSE/CraigsRace(16334): OpenGL Version: OpenGL ES 1.0-CM
Great. Is there some way for me to try it on the phone and how do i get the console output without attaching the phone to s pc (which i can’t do atm)… ???
Good idea. On my G1 I got the same as Ranger.
HTC Hero:
Kev
I back from vacation and finally had the chance to try it. This is the code i was using (derived from a simple example from google):
package com.threed.jpct.example;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.app.Activity;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.util.Log;
public class TestActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mGLView = new GLSurfaceView(this);
mGLView.setRenderer(new TestRenderer());
setContentView(mGLView);
}
@Override
protected void onPause() {
super.onPause();
mGLView.onPause();
}
@Override
protected void onResume() {
super.onResume();
mGLView.onResume();
}
private GLSurfaceView mGLView;
}
class TestRenderer implements GLSurfaceView.Renderer {
private boolean printed=false;
private int fps=0;
private long time=System.currentTimeMillis();
public void onSurfaceCreated(GL10 gl, EGLConfig config) {
}
public void onSurfaceChanged(GL10 gl, int w, int h) {
gl.glViewport(0, 0, w, h);
}
public void onDrawFrame(GL10 gl) {
gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT);
if (System.currentTimeMillis()-time>=1000) {
time=System.currentTimeMillis();
Log.i("TestRenderer", fps+"fps");
fps=0;
}
if (!printed) {
printed=true;
Log.i("TestRenderer", "OpenGL Vendor: "+gl.glGetString(GL10.GL_VENDOR));
Log.i("TestRenderer", "OpenGL Renderer: "+gl.glGetString(GL10.GL_RENDERER));
Log.i("TestRenderer", "OpenGL Version: "+gl.glGetString(GL10.GL_VERSION));
}
fps++;
}
}
And this is what the phone says (like i expected):
08-15 22:44:04.915: INFO/TestRenderer(4740): OpenGL Vendor: Android
08-15 22:44:04.915: INFO/TestRenderer(4740): OpenGL Renderer: Android PixelFlinger 1.0
08-15 22:44:04.925: INFO/TestRenderer(4740): OpenGL Version: OpenGL ES-CM 1.0
That code runs @56fps on the phone.
So the situation is, that the Samsung can do 3D (as proofed by the Neocore demo and Omnigsofts race games) but inside the Dalvik VM, it does software rendering in all its glory. I’ll try to contact Samsung about this…i can’t wait to receive a nonsense response from an underpaid and overworked hotliner who didn’t even understand my problem…stay tuned!
Edit: I’ve written an support request…it started out very promising: I couldn’t even select my phone from their list…
Update: Got a mail from Samsung that they have send the request to the responsible division…took them over a week to do so… ???
More trouble for the Galaxy? http://www.mobiletoday.co.uk/Samsung’s_first_Android_phone_delayed_after_O2_testing.aspx
Funny…in germany, they (read: O2) are happily selling it. I should know…i bought mine from O2.
I’m sure others have seen it but this just popped up for me:
For the Galaxy owners here, do you know if this fixes the OpenGL hardware acceleration issue? I’ve already put in a check in my game to look for the Android vendor string, warn the user, and disable sound/music/orientation/kitchen sink if found - not an optimal solution. :-\
Ernest Woo
Woo Games
http://www.woogames.com
No, the update doesn’t help. But i had plenty of fun with it rendering the whole phone useless after upgrading… >:(
Anyway, it’s working again but still no hardware acceleration.
They have found a fix for the OpenGL hardware acceleration on the Galaxy. You have to use a depth size of 16.
See: http://groups.google.com/group/android-developers/browse_thread/thread/b521170e92e30366
EDIT: This would explain why CraigsRace ran ok on the Galaxy, as I was already doing this. However, in the latest version, I removed it, as I was also specifying the RGB size which apparently was causing issues with the DROID (running Android 2.0). Could anyone check that CraigsRace still runs ok on the Galaxy? Thanks.
Thanks for the head’s up. I’m still trying to digest the solution proposed by Google when you had issues with Droid/Android 2.0. I’d be wary of blindly asking for just a specific EGL_DEPTH_SIZE. Maybe a better solution would be to ask for all configs with the desired RGBA sizes and where EGL_CONFIG_CAVEAT is EGL_NONE. As far as I can tell from reading the EGL spec, this should give you something hardware accelerated at or better than the requested color sizes.
If no suitable EGLConfigs are found, an EGLConfig where EGL_CONFIG_CAVEAT is EGL_SLOW_CONFIG should be chosen (implies software rendering).
I recommend that people read the EGL spec before using the proposed solution (http://www.khronos.org/registry/egl/). It is quite an interesting document but I’m weird like that . . . also while playing around with supported EGLConfigs on my HTC Magic, I see a EGL_NON_CONFORMANT_CONFIG RGBA=8888 config. Very interesting!
EDIT: To clarify, the Google fix I’m talking about is mentioned here: http://groups.google.com/group/android-developers/browse_thread/thread/859adcf26d4350de/1a785843c3f1dd8c#1a785843c3f1dd8c
Ernest
Woo Games
http://www.woogames.com
I haven’t seen this reply ealier…i’ll try that 16bit thing and report back. Your game still works fine on the Galaxy.