Android rendering messed up (all red) on a Samsung S3 / Mali-400MP4 GPU

I confirm that calling SDL_GL_SetAttribute for the 3 colour channels fixed
the problem.

This was happening on a Samsung S3 running Android 4.3, but not on one
running Android 4.4.

As Alex suggested, I agree it would be sensible to set the default values
to 565.On 5 September 2015 at 20:38, Alex Szpakowski wrote:

SDL requests an R3G3B2-sized color framebuffer by default:
https://hg.libsdl.org/SDL/file/6d6a972746b3/src/video/SDL_video.c#l2669

But systems are allowed to actually use larger sizes than what was
requested (and they definitely do in practice.) The 3-3-2 request just
seems to screw up colors on some Android devices.

On Sep 5, 2015, at 4:31 PM, Raymond Jennings wrote:

I always thought that the default size of the rgb bitfields depended on
system capabilities.


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


Davide Coppola

email: @Davide_Coppola
website: http://www.davidecoppola.com
blog: http://blog.davidecoppola.com

http://plus.google.com/+DavideCoppola
http://www.linkedin.com/in/davidecoppola
http://www.twitter.com/vivaladav

I’d rather set the default values based on underlying hardware capabilities.

On my system for example the preferred format is 8888 :)On Mon, Sep 7, 2015 at 9:44 AM, Davide Coppola wrote:

I confirm that calling SDL_GL_SetAttribute for the 3 colour channels
fixed the problem.

This was happening on a Samsung S3 running Android 4.3, but not on one
running Android 4.4.

As Alex suggested, I agree it would be sensible to set the default values
to 565.

On 5 September 2015 at 20:38, Alex Szpakowski wrote:

SDL requests an R3G3B2-sized color framebuffer by default:
https://hg.libsdl.org/SDL/file/6d6a972746b3/src/video/SDL_video.c#l2669

But systems are allowed to actually use larger sizes than what was
requested (and they definitely do in practice.) The 3-3-2 request just
seems to screw up colors on some Android devices.

On Sep 5, 2015, at 4:31 PM, Raymond Jennings <@Raymond_Jennings> wrote:

I always thought that the default size of the rgb bitfields depended on
system capabilities.


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


Davide Coppola

email: vivaladav at gmail.com
website: http://www.davidecoppola.com
blog: http://blog.davidecoppola.com

http://plus.google.com/+DavideCoppola
http://www.linkedin.com/in/davidecoppola
http://www.twitter.com/vivaladav


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

yes, that would be definitely better!

I didn’t look at the code though and I was assuming the default values were
used when the proper capabilities are not recognized or properly handled by
SDL (as it seems to happen for this, still unfixed, bug).On 7 September 2015 at 17:47, Raymond Jennings wrote:

I’d rather set the default values based on underlying hardware
capabilities.

On my system for example the preferred format is 8888 :slight_smile:

On Mon, Sep 7, 2015 at 9:44 AM, Davide Coppola <@Davide_Coppola> wrote:

I confirm that calling SDL_GL_SetAttribute for the 3 colour channels
fixed the problem.

This was happening on a Samsung S3 running Android 4.3, but not on one
running Android 4.4.

As Alex suggested, I agree it would be sensible to set the default values
to 565.

On 5 September 2015 at 20:38, Alex Szpakowski wrote:

SDL requests an R3G3B2-sized color framebuffer by default:
https://hg.libsdl.org/SDL/file/6d6a972746b3/src/video/SDL_video.c#l2669

But systems are allowed to actually use larger sizes than what was
requested (and they definitely do in practice.) The 3-3-2 request just
seems to screw up colors on some Android devices.

On Sep 5, 2015, at 4:31 PM, Raymond Jennings wrote:

I always thought that the default size of the rgb bitfields depended on
system capabilities.


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


Davide Coppola

email: @Davide_Coppola
website: http://www.davidecoppola.com
blog: http://blog.davidecoppola.com

http://plus.google.com/+DavideCoppola
http://www.linkedin.com/in/davidecoppola
http://www.twitter.com/vivaladav


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


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


Davide Coppola

email: @Davide_Coppola
website: http://www.davidecoppola.com
blog: http://blog.davidecoppola.com

http://plus.google.com/+DavideCoppola
http://www.linkedin.com/in/davidecoppola
http://www.twitter.com/vivaladav

OSX enforces vsync in most cases.

–ryan.On 9/5/15 4:29 AM, jeroen clarysse wrote:

are you sure ? I?m on OSX and I figured SDL_GetTicks() was accurate enough up to a msec ?

are you sure ? I?m on OSX and I figured SDL_GetTicks() was accurate enough up to a msec ?

OSX enforces vsync in most cases.

dang? is this by-passable ?

The Xcode Graphics Tools includes the Quartz Debug app, which can globally enable or disable vsync (for testing purposes only.)

Even on other platforms you can?t rely on vsync being disabled, since the user or the driver may override your app?s request.> On Sep 11, 2015, at 4:20 AM, jeroen clarysse <jeroen.clarysse at telenet.be> wrote:

are you sure ? I?m on OSX and I figured SDL_GetTicks() was accurate enough up to a msec ?

OSX enforces vsync in most cases.

dang? is this by-passable ?


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