Slick-AE Development

Java on Mobile Devices Android
#41

I’ll give it a try. Were there any optimizations for moving to GL11 ?

Kev

#42

Unfortunately no effect on this particular case.

Kev

#43

Works on the Galaxy with 1.5 now. However, it’s very slow because it uses the software renderer instead of hardware. To use hardware rendering on this particular phone, you have to make sure that you are initializing gl in a particular way. You can look at any jPCT-AE example to see how.

#44

Thanks Egon!

Kev

#45

This bit?


mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {

			public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {

				// Ensure that we get a 16bit framebuffer. Otherwise, we'll fall

				// back to Pixelflinger on some device (read: Samsung I7500)

				int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };

				EGLConfig[] configs = new EGLConfig[1];

				int[] result = new int[1];

				egl.eglChooseConfig(display, attributes, configs, 1, result);

				return configs[0];

			}

		});

Any chance that could be wound into libgdx NateS/badlogic ?

Kev

#46

Yes, that part does the trick.

#47

Hm, i can add that but it will have side effects when applied to all phones. I’d rather make a special case for the Samsung I7500. Does anyone have the device string?

#48

Systeminfo says the device is “GT-I7500”. Does that help?

#49

if it’s the same as the Build.MODEL string then yes :slight_smile: http://developer.android.com/reference/android/os/Build.html#MODEL

#50

MODEL is “Galaxy”, DEVICE and PRODUCT are both “GT-I7500”

#51

f’ing samsung not setting the Model string correctly :confused: i guess that will overlap with other Galaxy models, like the Galaxy S. Thanks for the other strings, that should allow us to pinpoint the crappy I7500!

#52

Product, Model and Device on my Galaxy S are all “GT-I9000”

#53

Ok, i checked the GLSurfaceView sources, especially the config choosing. EgonOlsen, are you doing all your config choosing yourself or do you use the default config choosers? In any case, i uploaded our test suite to http://www.badlogicgames.com/downloads/gdx-tests-android.apk. For those of you that have a Galaxy I7500, could you install that apk and run one of the tests? I output the EGL and OGL config to logcat, the tag is “AndroidGraphics”.

On my Milestone i get this for example:


12-03 00:49:11.975: DEBUG/AndroidGraphics(1803): OGL renderer: PowerVR SGX 530
12-03 00:49:11.975: DEBUG/AndroidGraphics(1803): OGL vendor: Imagination Technologies
12-03 00:49:11.975: DEBUG/AndroidGraphics(1803): OGL version: OpenGL ES 2.0
12-03 00:49:11.975: DEBUG/AndroidGraphics(1803): OGL extensions: GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_vertex_half_float GL_OES_texture_float GL_OES_texture_half_float GL_OES_element_index_uint GL_OES_mapbuffer GL_OES_fragment_precision_high GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image GL_OES_required_internalformat GL_OES_depth_texture GL_OES_get_program_binary GL_OES_packed_depth_stencil GL_OES_standard_derivatives GL_EXT_multi_draw_arrays GL_EXT_texture_format_BGRA8888 GL_EXT_discard_framebuffer GL_IMG_shader_binary GL_IMG_texture_compression_pvrtc GL_IMG_texture_stream2 GL_IMG_texture_npot GL_IMG_texture_format_BGRA8888 GL_IMG_read_format GL_IMG_program_binary GL_IMG_vertex_array_object 
12-03 00:49:11.975: DEBUG/AndroidGraphics(1803): framebuffer: (5, 6, 5, 0)
12-03 00:49:11.975: DEBUG/AndroidGraphics(1803): depthbuffer: (24)
12-03 00:49:11.983: DEBUG/AndroidGraphics(1803): stencilbuffer: (8)

Note that the depth and stencil buffer config is an exception, on most phones you’d get no stencil and a 16-bit depth buffer by default. Please report what you get for your Galaxy phones. Thanks a bunch.

#54

I’m doing what has been posted above. Default config choosers don’t work (if we actually mean the same thing…). To be exact, nothing else works except for the code snippet above. OGL Renderer for your test case is Pixelflinger. I stopped reading from there… :wink:

#55

Cool, thanks a bunch. I assume your fix instantiates a depth buffer as well, right? Just asking cause i have no I7500 to test so i have to make sure things won’t break.

#56

Yes. I’m using it in all my applications on all devices and never had a single problem with that.

#57

Tried this on a Magic with 1.5; seemed to work fine (if a little bit slow - nothing serious, though).

#58

Yay, 1.5 success :slight_smile: Has Egon’s workrounds found it into LibGDX?

Kev

#59

I’m getting a Fail: Unsupported glGenLists, but otherwise it seems to work well enough. I haven’t really stressed this yet, though - just played for a handful of minutes.

#60

The Fail: messages are just reminders to me. For instance, some things in slick are optimized using display lists - which don’t work on this renderer (yet?).

Kev