All Testers -- SDL 2.0 Upgrade!

[Paul]

Littleguy added compatibility for SDL 2.0.  This is a major update, and we now need all testers to help identify any problems.  Spread the word among your friends and networks!

Please provide feedback on performance and compatibility.  In particular, we are interested in results from older devices, devices that have performance issues like the Galaxy S3 US version, and devices with unique rendering problems like the Droid Razr.

SDL 2 Test A

SDL 2 Test B

SDL 2 Test C

SDL 2 Test D

[Pau]

You manifest minsdkversion and the jni APP_PLATFORM is wrong. The SDL2 Android readme says that the correct setting has to be at least 10 and not 5 and 9 (which is wrong from the beginning because they have conflicting values with minsdk 5 < platform 9)

[Paul]

It's not strictly incorrect to have minsdk less than 10, depending on if those API level 10 features are used by the app or not.  Before changing anything, I would like to see if it crashes on these devices, because there is still a non-trivial percentage of Mupen64Plus AE users with pre-2.3.3.

As for the question of APP_PLATFORM, it has been sitting at 9 for some time, and never caused any problems.  I would have to do some research to see what the implications are (the fact that Eclipse or ant do not fail when minSDK is less than APP_PLATFORM would lead me to believe this is not necessarily an error).

[littleguy]

It's not strictly an error if you're sure about what you're doing.  SDK 9 is required only on the native side, only to build the special library for the Xperia PLAY touchpad.  If you were to exclude that library from the build you could build everything for SDK 5.  I.e. we're not using any APIs above 5 anywhere else in the native code.  If SDL 2 truly requires API 10 then it just wouldn't build, plain and simple.

I'm not sure why the SDL2 readme says that API 10 is needed, but the Java Android code provided with SDL 2 is just a hello world example and we're not using it.  We are using some higher APIs in the Java code but the version is always run-time tested before executing any of that code.

Edit: Also, only in the latest NDK (8e) does ndk-build even throw a warning about API mismatch between native and java side.

Edit2: Ok, I tried my own suggestion and you're right, SDL 2 does require platform-9 for EGL headers (though it seems only for some macro constants).

As Paul said, let's see if anyone with a pre-2.3.3 device can run it before throwing in the towel.

[littleguy]

Well now you piqued my curiosity.  SDL2's dependency on platform-9 comes down to just a few constants defined in egl.h

Code: [Select]

#define EGL_BUFFER_SIZE         0x3020
#define EGL_ALPHA_SIZE          0x3021
#define EGL_BLUE_SIZE           0x3022
#define EGL_GREEN_SIZE          0x3023
#define EGL_RED_SIZE            0x3024
#define EGL_DEPTH_SIZE          0x3025
#define EGL_STENCIL_SIZE        0x3026
#define EGL_SAMPLES             0x3031
#define EGL_SAMPLE_BUFFERS      0x3032
#define EGL_NONE                0x3038
#define EGL_RENDERABLE_TYPE     0x3040
#define EGL_OPENGL_ES_BIT       0x0001
#define EGL_OPENGL_ES2_BIT      0x0004

If you cut and paste those into SDL_android.cpp in place of #include <EGL/egl.h> the whole thing builds with platform-5 (excluding the xperia play library of course).  Not saying we should do that, just wanted to make a clarification about how thin SDL2's dependency is on platform-9.

[littleguy]

Just discovered that the gl context is not being created properly on my xperia play.  It's the new sdl interface that allows sdl to specify the configuration (GameSurface.createGLContext( int majorVersion, int minorVersion, int[] configSpec )... apparently my device isn't happy with what SDL is requesting.  Have to look into that tomorrow....

[WinSuk]

Android 2.2.2 (on a Motorola Flipside): On-screen controller is shown for a bit, then it backs out to the Play screen.

Log: https://dl.dropboxusercontent.com/u/1077120/mupentesting/froyosdl2log.txt

[littleguy]

Very similar to my issue, but possibly a different cause.  I remembered late last night that I forgot to make one other change in the java side when migrating to SDL 2.0 (forgot to cherry pick a commit from one of my experimental branches).  I'll try to have an update tonight.  In the meantime, this is still a worthwhile test for folks to run if they can get past the loading stage.

[littleguy]

Ok I fixed the crash on my xperia play, and may have fixed winsuk's crash as well.

Paul - Ready to go for round 2 of testing.

[Paul]

Here is the updated version (as of commit 3f7b8d6902):

SDL 2 Test B

[WinSuk]

Nope, that didn't fix it..

Log again if needed: https://dl.dropboxusercontent.com/u/1077120/mupentesting/froyosdl2log2.txt

[littleguy]

Thanks much for the log.  Here's the key section, looks like we can't get a valid rendering context, even with the fallback I added:

Code: [Select]

04-16 18:42:19.147  6198  6833 D gles2n64: Initializing SDL video subsystem...
04-16 18:42:19.147  6198  6833 D gles2n64: Setting video mode 480x320...
04-16 18:42:19.147  6198  6833 V GameSurface: Starting up OpenGL ES 2.0
04-16 18:42:19.147  6198  6833 D libEGL  : loaded /system/lib/egl/libGLES_android.so
04-16 18:42:19.155  6198  6833 D libEGL  : loaded /system/lib/egl/libEGL_POWERVR_SGX530_121.so
04-16 18:42:19.163  6198  6833 D libEGL  : loaded /system/lib/egl/libGLESv1_CM_POWERVR_SGX530_121.so
04-16 18:42:19.170  6198  6833 D libEGL  : loaded /system/lib/egl/libGLESv2_POWERVR_SGX530_121.so
04-16 18:42:19.225  6198  6833 E GameSurface: Couldn't create EGL window surface
04-16 18:42:19.225  6198  6833 W CoreInterfaceNative: Retrying GL context creation without EGL_BUFFER_SIZE=0
04-16 18:42:19.225  6198  6833 V GameSurface: Starting up OpenGL ES 2.0
04-16 18:42:19.241  6198  6833 E GameSurface: Couldn't create EGL window surface
04-16 18:42:19.241  6198  6833 V GameSurface: Starting up OpenGL ES 1.1
04-16 18:42:19.256  6198  6833 E GameSurface: Couldn't create EGL window surface
04-16 18:42:19.256  6198  6833 W CoreInterfaceNative: Retrying GL context creation without EGL_BUFFER_SIZE=0
04-16 18:42:19.256  6198  6833 V GameSurface: Starting up OpenGL ES 1.1
04-16 18:42:19.272  6198  6833 E GameSurface: Couldn't create EGL window surface
04-16 18:42:19.272  6198  6833 D gles2n64: Problem setting videomode 480x320: No hardware accelerated renderers available
...
04-16 18:42:21.920  6198  6833 E libEGL  : call to OpenGL ES API with no current context (logged once per thread)
04-16 18:42:21.920  6198  6833 E libEGL  : call to OpenGL ES API with no current context (logged once per thread)
04-16 18:42:21.920  6198  6833 E libEGL  : call to OpenGL ES API with no current context (logged once per thread)
(etc...)


[WinSuk]

Just tried it on a different phone (HTC Aria) with CyanogenMod 6 (Android 2.2.1), and it works fine there. Doesn't seem to be using the fallback either ("Retrying GL context creation without EGL_BUFFER_SIZE=0" isn't in the log like it is on the Flipside)

I was hoping CyanogenMod would have more debugging output if it failed..

Probably won't help much, but here's the log anyway https://dl.dropboxusercontent.com/u/1077120/mupentesting/froyosdl2logliberty.txt

[littleguy]

Thanks for all the testing.  I just pushed another change, which adds a deeper fallback if the first fallback fails.  I'll be really surprised if this doesn't fix the problem.

Paul - ready when you are.  Sorry to give you so much work 

[Paul]

No problem, you are doing the work.  I'm just building

I'll post the next test in the morning.