Android device displays everything in purple tones

Limanima · February 26, 2015, 5:22pm

Today a friend of mine installed my game on his device and something is wrong. All the game is tinted in purple tones. At the beggining I thought there was some color channel switching, but there’s a strange behaviour:
A screen capture shows the colors correctly. When the game is minimizing, the colors are ok. The colors are also good in the android task manager. The colors are only wrong when the game is active.
This behaviour makes think that: the color information and the texture format are correct and the shaders are ok (and are very simple).
As anyone ever experienced something similar?

Reto_Schneider · February 26, 2015, 10:29pm

Yes: Android: Red screen an some devices (Samsung Galaxy S3, Galaxy Note 8, Galaxy Note 2) · Issue #1265 · libsdl-org/SDL · GitHub

And it is not yet resolved.

Regards,
RetoOn 26.02.2015 18:22, Limanima wrote:

As anyone ever experienced something similar?

Limanima · February 27, 2015, 8:56am

Reto Schneider wrote:> On 26.02.2015 18:22, Limanima wrote:

As anyone ever experienced something similar?

Yes: Android: Red screen an some devices (Samsung Galaxy S3, Galaxy Note 8, Galaxy Note 2) · Issue #1265 · libsdl-org/SDL · GitHub

And it is not yet resolved.

Regards,
Reto

Ok thanks. At least I have some clues of what is going on.

SiPlus · February 27, 2015, 1:34pm

IT’S NOT PURPLE, IT’S WHITE AND GOLD!!!

Anyway, try changing #if ANDROID to #ifdef ANDROID in src/video/SDL_egl.c. It’s possible that the NDK simply defines ANDROID instead of setting it to 1 (I’m not exactly sure about this, but another macro, ANDROID, is defined by NDK-Build with -DANDROID, not -DANDROID=1).

Limanima · February 28, 2015, 5:03pm

SiPlus wrote:

IT’S NOT PURPLE, IT’S WHITE AND GOLD!!!

Anyway, try changing #if ANDROID to #ifdef ANDROID in src/video/SDL_egl.c. It’s possible that the NDK simply defines ANDROID instead of setting it to 1 (I’m not exactly sure about this, but another macro, ANDROID, is defined by NDK-Build with -DANDROID, not -DANDROID=1).

I don’t think that will solve the problem. It’s seems to be a render target problem.

SiPlus · February 28, 2015, 8:15pm

Limanima wrote:

SiPlus wrote:

IT’S NOT PURPLE, IT’S WHITE AND GOLD!!!

Anyway, try changing #if ANDROID to #ifdef ANDROID in src/video/SDL_egl.c. It’s possible that the NDK simply defines ANDROID instead of setting it to 1 (I’m not exactly sure about this, but another macro, ANDROID, is defined by NDK-Build with -DANDROID, not -DANDROID=1).

I don’t think that will solve the problem. It’s seems to be a render target problem.

Actually yes, I just tried, ANDROID is set to 1.

Limanima · March 2, 2015, 10:39am

SiPlus wrote:

Limanima wrote:

SiPlus wrote:

IT’S NOT PURPLE, IT’S WHITE AND GOLD!!!

Anyway, try changing #if ANDROID to #ifdef ANDROID in src/video/SDL_egl.c. It’s possible that the NDK simply defines ANDROID instead of setting it to 1 (I’m not exactly sure about this, but another macro, ANDROID, is defined by NDK-Build with -DANDROID, not -DANDROID=1).

I don’t think that will solve the problem. It’s seems to be a render target problem.

Actually yes, I just tried, ANDROID is set to 1.

Sorry, I’ve checked the code and you may actually be right. I’m going to try that. Maybe this should be fixed in the head?

Limanima · March 2, 2015, 8:59pm

SiPlus wrote:

Limanima wrote:

SiPlus wrote:

IT’S NOT PURPLE, IT’S WHITE AND GOLD!!!

Anyway, try changing #if ANDROID to #ifdef ANDROID in src/video/SDL_egl.c. It’s possible that the NDK simply defines ANDROID instead of setting it to 1 (I’m not exactly sure about this, but another macro, ANDROID, is defined by NDK-Build with -DANDROID, not -DANDROID=1).

I don’t think that will solve the problem. It’s seems to be a render target problem.

Actually yes, I just tried, ANDROID is set to 1.

I forced a compile error in the piece of code and the compiler reports the error. That code is compiling in Android. That’s not the problem after all.

Limanima · March 3, 2015, 11:58am

Limanima wrote:

SiPlus wrote:

Limanima wrote:

SiPlus wrote:

IT’S NOT PURPLE, IT’S WHITE AND GOLD!!!

Anyway, try changing #if ANDROID to #ifdef ANDROID in src/video/SDL_egl.c. It’s possible that the NDK simply defines ANDROID instead of setting it to 1 (I’m not exactly sure about this, but another macro, ANDROID, is defined by NDK-Build with -DANDROID, not -DANDROID=1).

I don’t think that will solve the problem. It’s seems to be a render target problem.

Actually yes, I just tried, ANDROID is set to 1.

I forced a compile error in the piece of code and the compiler reports the error. That code is compiling in Android. That’s not the problem after all.

I did this (like Hak Matsuda suggested in the bugzilla entry):

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

After creating the rendering and it solved the problem on the faulting device. It doesn’t seem to have broken the other devices.

Limanima · March 3, 2015, 12:00pm

Limanima wrote:

Limanima wrote:

SiPlus wrote:

Limanima wrote:

SiPlus wrote:

IT’S NOT PURPLE, IT’S WHITE AND GOLD!!!

Anyway, try changing #if ANDROID to #ifdef ANDROID in src/video/SDL_egl.c. It’s possible that the NDK simply defines ANDROID instead of setting it to 1 (I’m not exactly sure about this, but another macro, ANDROID, is defined by NDK-Build with -DANDROID, not -DANDROID=1).

I don’t think that will solve the problem. It’s seems to be a render target problem.

Actually yes, I just tried, ANDROID is set to 1.

I forced a compile error in the piece of code and the compiler reports the error. That code is compiling in Android. That’s not the problem after all.

I did this (like Hak Matsuda suggested in the bugzilla entry):

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

After creating the rendering and it solved the problem on the faulting device. It doesn’t seem to have broken the other devices.

Correction to the previous post: it’s not AFTER, it’s BEFORE creating the renderer.

Sylvain_Becker · March 3, 2015, 1:58pm

From what I remember, setting 565 is a workaround, because it will choose
indirectly a different “egl-configuration”.

But that’s the best thing to do currently.

I spend some time to help in this ticket and the problem as I understandood
it, is:

the device S3 provides many egl-configurations.
the application is in landscape and choose/request an egl-configuration.

At first, the selected “egl-config” seems correct (regarding colors, depth,
etc.), but, in fact,when running, the application appears to be bad (red
screen problem).

Can you tell if you hardware device is a S3 ? and if you application is
also landscape ?

Another issue that happens to me is this one:

github.com/libsdl-org/SDL

Android: screen distorted in Landscape after background/foreground

opened 11:49PM - 10 Feb 21 UTC

closed 11:49PM - 10 Feb 21 UTC

SDLBugzilla

# This bug report was migrated from our old Bugzilla tracker. These attachments… are available in the static archive: * [video of the bug (2_video-2014-10-03-11-53-01.mp4, video/mp4, 2014-11-01 15:22:11 +0000, 3167092 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1922) * [testsprite2 starts in landscape (first.png, image/png, 2014-11-04 18:35:21 +0000, 132950 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1923) * [testsprite2 in landscape, after background/foreground (second.png, image/png, 2014-11-04 18:36:11 +0000, 117430 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1924) * [discard surfaceChanged (SDL_patch_landscape.txt, text/plain, 2014-11-14 15:30:02 +0000, 1691 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1932) * [discard surfaceChanged v2 (SDL_patch_landscape-v2.txt, text/plain, 2014-11-30 07:07:18 +0000, 2087 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1946) **Reported in version:** 2.0.3 **Reported for operating system, platform:** Android (All), ARM # Comments on the original bug report: On 2014-11-01 15:22:11 +0000, Sylvain wrote: > Created attachment 1922 > video of the bug > > With a Landscape application. > Going to background with Home Key, then foreground. > The screen is distorted. > > This has been reported by Samsung. It happens on S5 and Samsung Alpha, see the video attached. > > I have captured the following logcat: > > V/SDL (20549): onResume() > V/SDL (20549): surfaceCreated() > V/SDL (20549): surfaceChanged() > V/SDL (20549): pixel format RGB_565 > V/SDL (20549): Window size:1920x1080 > I/SDL (20549): SDL_Android_Init() > I/SDL (20549): SDL_Android_Init() finished! > V/SDL (20549): SDL audio: opening device > V/SDL (20549): SDL audio: wanted stereo 16-bit 22.05kHz, 256 frames buffer > V/SDL (20549): SDL audio: got stereo 16-bit 22.05kHz, 1764 frames buffer > V/SDL (20549): onWindowFocusChanged(): true > V/SDL (20549): onWindowFocusChanged(): false > V/SDL (20549): onPause() > V/SDL (20549): nativePause() > V/SDL (20549): surfaceDestroyed() > > Background / Foreground > > V/SDL (20549): onResume() > V/SDL (20549): surfaceCreated() > V/SDL (20549): surfaceChanged() > V/SDL (20549): pixel format RGB_565 > V/SDL (20549): Window size:1080x1920 > V/SDL (20549): surfaceChanged() > V/SDL (20549): pixel format RGB_565 > V/SDL (20549): Window size:1920x1080 > V/SDL (20549): onWindowFocusChanged(): true > V/SDL (20549): nativeResume() > > > > This seems to be related to the fact that I have in "AndroidManifest.xml": > android:configChanges="..." > Because of the fields: "orientation" and also "screenSize". > > > The following patch works (in Java_org_libsdl_app_SDLActivity_onNativeSurfaceChanged): > > diff -r 741700a12835 src/core/android/SDL_android.c > > --- a/src/core/android/SDL_android.c Fri Oct 24 11:53:34 2014 +0200 > +++ b/src/core/android/SDL_android.c Sat Nov 01 15:33:52 2014 +0100 > @@ -224,6 +224,18 @@ > } > data->native_window = Android_JNI_GetNativeWindow(); > data->egl_surface = SDL_EGL_CreateSurface(_this, (NativeWindowType) data->native_window); > + } else { > + > + SDL_EGL_MakeCurrent(_this, NULL, NULL); > + SDL_EGL_DestroySurface(_this, data->egl_surface); > + > + if(data->native_window) { > + ANativeWindow_release(data->native_window); > + } > + > + data->native_window = Android_JNI_GetNativeWindow(); > + data->egl_surface = SDL_EGL_CreateSurface(_this, (NativeWindowType) data->native_window); > + > } > > And also a shorter version works: > > + SDL_EGL_MakeCurrent(_this, NULL, NULL); > + SDL_EGL_DestroySurface(_this, data->egl_surface); > + data->egl_surface = SDL_EGL_CreateSurface(_this, (NativeWindowType) data->native_window); > > > I looked deeper into "SDL_EGL_CreateSurface" and I tried this, but it did not work: > > + data->native_window = Android_JNI_GetNativeWindow(); > + ANativeWindow_setBuffersGeometry(data->native_window, > + ANativeWindow_getWidth(data->native_window), > + ANativeWindow_getHeight(data->native_window), > + ANativeWindow_getFormat(data->native_window)); On 2014-11-02 10:31:59 +0000, Sylvain wrote: > Some update: > > It works if I remove this line from my application: > > SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0); > > So, it seems to be also related to the choice of the EGL configuration. > > > I have tried testgles2 and testsprite2. Both have this issue. > Provided that: > - set the landscape mode > - comment out all the SDL_GL_SetAttribute in "SDL_test_common.c" > - add SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0); On 2014-11-04 18:35:21 +0000, Sylvain wrote: > Created attachment 1923 > testsprite2 starts in landscape On 2014-11-04 18:36:11 +0000, Sylvain wrote: > Created attachment 1924 > testsprite2 in landscape, after background/foreground On 2014-11-04 18:42:04 +0000, Sylvain wrote: > I have just attached two screen shots of testsprite2 : > - when it starts > - after background/foreground > > the screen is distorted : > - stretched > - shifter to the right > > > About the video. Notice it has garbage on the left part of the screen. Because I don't do a "RenderClear" before writing each frame. On 2014-11-04 18:45:14 +0000, Sylvain wrote: > I have played with the egl configs, by hardcoding the config no to load. > > They all works when it starts! (no red screen ...) > > 25% of them have this is issue of landscape-background-foreground. > With (so far) no apparent reason. On 2014-11-14 15:27:48 +0000, Sylvain wrote: > Please ignore the above patch. It adds some problem when going back to the application from the lock-screen. > > > I have looked for another way to solve the issue. Discarding the "surfaceChanged" call, based on the "requestedOrientation" and the new Orientation. It seems to be better. > > > On my failing test case, the first "surfaceChanged()" is discarded. Sometimes the "focusChanged()" might appear between the two "surfaceChanged()", while the surface is not yet ready. Thus, discarding also the "nativeResume()". > > So, for robustness, a call to "nativeResume()" is added at the end of "surfaceChanged()". > > Let me know about the following patch. On 2014-11-14 15:30:02 +0000, Sylvain wrote: > Created attachment 1932 > discard surfaceChanged > > discard surfaceChanged base on orientation. On 2014-11-29 22:47:19 +0000, Sam Lantinga wrote: > Gabriel, can you look at this patch and see if it's good for 2.0.4? > > Thanks! On 2014-11-30 07:07:18 +0000, Sylvain wrote: > Created attachment 1946 > discard surfaceChanged v2 On 2014-11-30 07:23:42 +0000, Sylvain wrote: > Some update: > > 1/ First I tried, to discard the surface using the current orientation (rather than width / heigh). -> that solve the issue sometimes, but not always. > > 2/ Samsung Certification now accepts my application that were previously failing. > > 3/ I personally now owns a Samsung S5, and was able to solve the issue on my side. > > 4/ I now use the patch and get no complaints from my users. (but I admit, nobody seemed to be complaining before neither...). > > 5/ I have added a v2 because of a new smart-phone called "Black Berry Passport" that has a square screen of 1440x1440. This screen has a "status bar" so the resolution is in fact : 1440x1308. (as reported by "surfaceChanged"). > > Problem is: the portrait resolution is in fact a Landscape! > > So the "v1" patch is always discarding the "surface" of BlackBerry Passport. Which is terribly bad. > > > Hence, I added the "v2" patch not to discard the surface when aspect ratio is < 1.20. (BB 1440/1308 is : 1.1009). Which seems fair. On 2015-06-17 05:17:21 +0000, Sam Lantinga wrote: > Fixed, thanks! > https://hg.libsdl.org/SDL/rev/a1b920bc870d

The application is landscape. The java layer calls incorrectly
“onSurfaceChanged()” with (width, height) instead of (height, width).
Then the screen is distorded.
But it is only problematic with some egl-configurations and some device.

You may want to try the path attached in this ticket. Please, tell if you
try it and the result !On Tue, Mar 3, 2015 at 1:00 PM, Limanima <jorge.raposo.lima at gmail.com> wrote:

Limanima wrote:

Limanima wrote:

SiPlus wrote:

Limanima wrote:

SiPlus wrote:

IT’S NOT PURPLE, IT’S WHITE AND GOLD!!! [image: Very Happy]

Anyway, try changing #if ANDROID to #ifdef ANDROID in
src/video/SDL_egl.c. It’s possible that the NDK simply defines ANDROID
instead of setting it to 1 (I’m not exactly sure about this, but another
macro, ANDROID, is defined by NDK-Build with -DANDROID, not -DANDROID=1).

I don’t think that will solve the problem. It’s seems to be a render
target problem.

Actually yes, I just tried, ANDROID is set to 1.

I forced a compile error in the piece of code and the compiler reports the
error. That code is compiling in Android. That’s not the problem after all.

I did this (like Hak Matsuda suggested in the bugzilla entry):

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

After creating the rendering and it solved the problem on the faulting
device. It doesn’t seem to have broken the other devices.

Correction to the previous post: it’s not AFTER, it’s BEFORE creating the
renderer.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Sylvain Becker

Limanima · March 3, 2015, 6:17pm

slvn wrote:

From what I remember, setting 565 is a workaround, because it will choose indirectly a different “egl-configuration”.

But that’s the best thing to do currently.

I spend some time to help in this ticket and the problem as I understandood it, is:??

the device S3 provides many egl-configurations.

the application is in landscape and choose/request an egl-configuration.

At first, the selected “egl-config” seems correct (regarding colors, depth, etc.), but, in fact,when running, the application appears to be bad (red screen problem).

Can you tell if you hardware device is a S3 ? and if you application is also landscape ?

Another issue that happens to me is this one: https://bugzilla.libsdl.org/show_bug.cgi?id=2774 (https://bugzilla.libsdl.org/show_bug.cgi?id=2774)

The application is landscape. The java layer calls incorrectly “onSurfaceChanged()” with (width, height) instead of (height, width).
Then the screen is distorded.
But it is only problematic with some egl-configurations and some device.

You may want to try the path attached in this ticket. Please, tell if you try it and the result !
Sylvain Becker

It is an S3 but my application is in portait not in landscape (not my phone).

I’ve never experienced the distorted issue in my phone (Galaxy Fresh) nor the red screen problem.

Limanima · March 4, 2015, 5:18pm

Limanima wrote:

slvn wrote:

From what I remember, setting 565 is a workaround, because it will choose indirectly a different “egl-configuration”.

But that’s the best thing to do currently.

I spend some time to help in this ticket and the problem as I understandood it, is:??

the device S3 provides many egl-configurations.

the application is in landscape and choose/request an egl-configuration.

At first, the selected “egl-config” seems correct (regarding colors, depth, etc.), but, in fact,when running, the application appears to be bad (red screen problem).

Can you tell if you hardware device is a S3 ? and if you application is also landscape ?

Another issue that happens to me is this one: https://bugzilla.libsdl.org/show_bug.cgi?id=2774 (https://bugzilla.libsdl.org/show_bug.cgi?id=2774)

The application is landscape. The java layer calls incorrectly “onSurfaceChanged()” with (width, height) instead of (height, width).
Then the screen is distorded.
But it is only problematic with some egl-configurations and some device.

You may want to try the path attached in this ticket. Please, tell if you try it and the result !
Sylvain Becker

It is an S3 but my application is in portait not in landscape (not my phone).

I’ve never experienced the distorted issue in my phone (Galaxy Fresh) nor the red screen problem.

I also confirm that this workaround fixed another issue in an Samsung S2 where the game was running very slow. Now it is running smoothly.