Bad quality of background picture in Android

[Miroslav-Stimac]

Hello,

I have a PNG picture that is my game background with a resolution of 800 x 480. I use 8 bit color depth per channel. In PNG there are four channels, so the total color depth is 32 bit. The picture shows the sky with very soft color gradients from dark blue to light blue.

When I use this picture in my GLBasic game and compile it for Windows 7 or Windows 8, then everything looks perfect. But when I compile and run it on Android 2.3, then I see that the color gradients from dark blue to light blue are not soft anymore. It looks like 16 bit color depth. There are many lines of colors. It remembers me of old games in the 90s when I used a Voodoo 3 graphic card that could not display more than 16 bit color depth in 3D. However, my GLBasic game is 2D.

I also tried to use BMP and JPG with a color depth of 24 bit and it did not help, too. Now I am using the newest version of GLBasic. I tried it with Android 2.3 on a Lenovo Ideapad A1 and on a Samsung Galaxy S Plus. In both cases I have the same ugly gradients.

Is this a bug in GLBasic?
Why does the background picture look perfectly in Windows, but ugly on Android devices?
By the way, if I open the picture in the picture viewer of the Samsung Galaxy S Plus, then it looks nice. This means that the device can display the picture perfectly, but something is wrong when the picture is displayed by GLBasic.

Maybe it is a bug in the OpenGL driver. But it sounds strange that it happens on both devices that I have. Did somebody else try to use such pictures in GLBasic games and compile them for Android devices?

Best wishes,
Miroslav Stimac

[spacefractal]

You are right.

it's use 16bit and you can see it when you use _logview.bat, it's open a 565 surface on android and hence you see that.

I guess its a speed reason or a sdl limit. Not sure it's a choiced reason.

[MrTAToad]

Its a limitation of current devices....

[erico]

I, for example, have noticed web pages going on my brother´s samsung galaxy sII display gfx quite strange, pretty much as a 16bit image highly dithered with lots of ´errors´.

We can get around to this by testing gfx on a device before and accommodate our gfx to the same 32bits but caring for a color depth it can handle.

[Kitty Hello]

See the .java file in the distribute directory. I search for all possible formats (you can print hem out) and pick the "best" one that's supported.

[Miroslav-Stimac]

Thanks for the fast answers. What exactly is the reason for the 16 bit color depth on some Android devices?
Is it the OpenGL, the SDL or the GPU driver?

Cya,
Miroslav

[erico]

As you said on your other post, that using the internal viwer of your phone produces no garbage, it may be because of it having better 24-16 bit convert. I could be wrong.

[Wampus]

Is anyone aware of a good (free) app that can downsize RGB888 to RGB565 with dithering options? I will find a way but maybe there is a good solution already.

[erico]

GIMP should be able to handle such I guess.
Maybe grafx2 too, but am not sure.

[sf-in-sf]

Its a limitation of current devices....

I don't agree, Dude. To me it means the design was not careful/clever enough. processsing images in memory should be done in RAM and any depth, like 24, 32, or more. Only when it's time to refresh the screen the dithering should be done down to 16 bits or so.
It's no luxury! ....even gimp and films are currently moving to a proper 48 bits resolution, 3 x 16 for quality colors -and editing.

[sf-in-sf]

See the .java file in the distribute directory. I search for all possible formats (you can print hem out) and pick the "best" one that's supported.

Dear Kitty,
   Please have a look at this, it looks like it's the answer -but i don't know how to integrate it into GLb.
Quotation: By default GLSurfaceView chooses a EGLConfig that has an RGB_888 pixel format................
the page is there:
http://developer.android.com/reference/android/opengl/GLSurfaceView.html
Thank you in advance!

24/32 bit images look possible in android, but someone says they take longer to process/display.

[spacefractal]

long time ago this was debated....

Tts still uses 16bit and my guess its will not been changed, because its uses around double so much bandwidth for 32bit process, which was to much for some older Android 2.2 devices. Yes 16bit can look crude, but its can been hidden very much if well designed around it. I dont think its was a problem in my game at all.

This is not a issue for today Android devices of course, but that again something that could been sdk4.x platform. Gernot can you hint me how to add a new platform, then I do a tryout for that.

[sf-in-sf]

Right, spacefractal.
A good design trick is to ban color shades or dither everything down to 16 bits, RGB565, in a clean way. Or at least use directly a 16-bit restricted palette. Transparency can add problems too.

Gernot, I seem to make progress on the subject but I still need your help to succeed.
I found /distribute/Android/src/com/glbasic/test/SDLActivity.java . I wanted to make a short test with other settings but the new ****.java got crushed and automatically re-generated to the original setting. What is the way to change that and introduce new settings?
I wanted to try:
- remove the 4 out-commented lines EGL10.EGL_RED_SIZE, 8 and so on.
- change the next line to EGL10.EGL_DEPTH_SIZE, 32 (or 24)
in the initEGL function, 80% near the end.

Thank you!

[spacefractal]

I have tried that in the past, but sadly 32bit was not doing well, so far fom all devices does simply not supporting 32bit very well or at all! You have not wrote which device you are using. Its property limited too.

My game, Greedy Mouse was also not designed with 16bit in mind at all, but its still shown pretty nice and fully playable with 16bit colors on Android. So its depend on content.

Howover to edit the javafile, use that one from the glbasic installation:
Compiler\platform\android\templateproj\src\com\glbasic\test

[sf-in-sf]

Thanks for the hint, I will try soon.
I use an android tablet Archos 10.1 G9.
I just posted my fresh 16bit dither in the 'snippets'. It reduces banding but adds a bit of noise.
Hope it works o.k. for everyone.