2.0.2 release

SDL Development
22

You might want to check this patch / bug report out, its code is a bit more future-proof I think: https://bugzilla.libsdl.org/show_bug.cgi?id=2197#c2

It?s also worth mentioning that in OS X 10.9, requesting a GL 3.2 context will always give you either a 3.3 or a 4.1 context back, so another workaround is to just always request 3.2 on OS X (and bail on pre-10.9 systems.)On Feb 13, 2014, at 8:47 PM, Daniel C. Sinclair <daniel.c.sinclair at gmail.com> wrote:

Hello, I am trying to use OpenGL 3.3 core profile in SDL2 (checked out today) on OS X 10.9 and get this error:

“Could not initialize OpenGL: Requested GL version is not supported on this platform”

This https://hg.libsdl.org/SDL/rev/bb624b1348da was commited to update the versions that are supported. But the logic seems odd since it is hardcoded to 3.2. If I change “(wantver == 0x0302)” to use 0x0303 it works fine but then I can’t use previous versions.

The following patch isn’t pretty but works. Another option would be just checking the major version and ignoring the minor. I don’t really understand why the versions are checked like this at all (or why the OS X version is checked) so maybe there is a better way.

— a/src/video/cocoa/SDL_cocoaopengl.m Thu Feb 13 11:08:12 2014 -0800
+++ b/src/video/cocoa/SDL_cocoaopengl.m Thu Feb 13 16:29:05 2014 -0800
@@ -186,7 +186,7 @@
if (data->osversion >= 0x1070) {
NSOpenGLPixelFormatAttribute profile = kCGLOGLPVersion_Legacy;
if (_this->gl_config.profile_mask == SDL_GL_CONTEXT_PROFILE_CORE) {

  •        if (wantver == 0x0302) {

  •        if ((wantver == 0x0300) || (wantver == 0x0301) || (wantver == 0x0302) || (wantver == 0x0303)) {
           profile = kCGLOGLPVersion_GL3_Core;
       } else if ((wantver == 0x0401) && (data->osversion >= 0x1090)) {
           profile = kCGLOGLPVersion_GL4_Core;

It would be nice to get this fixed for 2.0.2.

Daniel

On Mon, Jan 27, 2014 at 4:05 AM, Gabriel Jacobo wrote:
The 2.0.2 release is coming next week!

If you have any critical bugs that require fixing before that happens, please say so as soon as possible. We don’t promise we’ll get all of them fixed, but we’ll do our best.

Thanks!

–
Gabriel.

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

23

This is sort of a mess, and we need to clean it up for 2.0.2.

–ryan.On 2/13/14, 7:47 PM, Daniel C. Sinclair wrote:

Hello, I am trying to use OpenGL 3.3 core profile in SDL2 (checked out
today) on OS X 10.9 and get this error:

24

Please take a look at the libsdl wiki here:
https://wiki.libsdl.org/SDL_RWread?highlight=(\bCategoryIO\b)|(CategoryEnum)|(CategoryStruct)

More Examples

int buffer[10]
SDL_RWread(rwop, buffer, sizeof(buffer), 4)
This will read 40 bytes of data, and put it into ‘buffer’, which is
intended to hold 32-bit integers. Each int is 4 bytes, or 32-bits.

I already asked them via their feedback formular, but I wanted to get a
quick answer on this here.
Isn’t this wrong? They set the maxnum paramter to 4 here, but expect 10
objects to be read.

Did I get this wrong?

25

Yeah, that doesn’t seem quite right, since sizeof(buffer) would return 40
when using 32-bit ints. It would also make more sense to switch the size
and maxnum arguments.

Jonny DOn Sat, Feb 15, 2014 at 12:56 PM, Julian Winter wrote:

Please take a look at the libsdl wiki here:
https://wiki.libsdl.org/SDL_RWread?highlight=(\bCategoryIO\b)https://wiki.libsdl.org/SDL_RWread?highlight=(\bCategoryIO\b)
|%28CategoryEnum%29|%28CategoryStruct%29

More Examples

int buffer[10]SDL_RWread(rwop, buffer, sizeof(buffer), 4)

This will read 40 bytes of data, and put it into ‘buffer’, which is
intended to hold 32-bit integers. Each int is 4 bytes, or 32-bits.

I already asked them via their feedback formular, but I wanted to get a
quick answer on this here.
Isn’t this wrong? They set the maxnum paramter to 4 here, but expect 10
objects to be read.

Did I get this wrong?

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

26

Message-ID: <52FFAA5C.5080600 at julianwinter.de>
Content-Type: text/plain; charset=“us-ascii”; Format=“flowed”

Please take a look at the libsdl wiki here:
https://wiki.libsdl.org/SDL_RWread?highlight=(\bCategoryIO\b)|(CategoryEnum)|(CategoryStruct)

More Examples

int buffer[10]
SDL_RWread(rwop, buffer, sizeof(buffer), 4)
This will read 40 bytes of data, and put it into ‘buffer’, which is
intended to hold 32-bit integers. Each int is 4 bytes, or 32-bits.

I already asked them via their feedback formular, but I wanted to get a
quick answer on this here.
Isn’t this wrong? They set the maxnum paramter to 4 here, but expect 10
objects to be read.

Did I get this wrong?

I’m not actually certain what the confusion is, so I’ll just explain
my understanding: the API expects the number of objects, in
conjunction with the size of the objects. Now, you would expect the
value given to each to matter, but as far as I know the only case
where it CAN matter which value gets put in which argument is if
you’re targeting a “middle-endian” system where, for example, the
lowest-indexed element in an array is stored at the highest set of
addresses in the array, but the least-significant byte in an integer
is stored at the LOWEST byte of the integer. This would make for a
weird system where it was unnecessarily difficult to convert raw data
to and from network-transportable form, so I assume that such systems
are rare.

Of course, just as weird is that the API looks like this in the first
place. You’d expect it to be some sort of gather-store api, but it
doesn’t have any way that I know of to indicate any amount of memory
to skip, so it’s really no different from a raw-block api on most (and
depending on implementation, all) platforms.

tl;dr: 410 == 104, so don’t worry about it.> Date: Sat, 15 Feb 2014 18:56:44 +0100

From: Julian Winter
To: SDL Development List
Subject: [SDL] SDL_RWread

27

Hi,

Yeah, that doesn’t seem quite right, since sizeof(buffer) would
return 40 when using 32-bit ints.

this is definitely a buffer overflow (also in the example following
this one). The SDL_RWread() command reads 160 bytes into a buffer of 40
bytes (assuming sizeof(int) == 4).

Best,
Felix> It would also make more sense to switch the size and maxnum arguments.

Jonny D

On Sat, Feb 15, 2014 at 12:56 PM, Julian Winter wrote:

Please take a look at the libsdl wiki here:
https://wiki.libsdl.org/SDL_RWread?highlight=(\bCategoryIO\b)https://wiki.libsdl.org/SDL_RWread?highlight=(\bCategoryIO\b)
|%28CategoryEnum%29|%28CategoryStruct%29

More Examples

int buffer[10]SDL_RWread(rwop, buffer, sizeof(buffer), 4)

This will read 40 bytes of data, and put it into ‘buffer’, which is
intended to hold 32-bit integers. Each int is 4 bytes, or 32-bits.

I already asked them via their feedback formular, but I wanted to
get a quick answer on this here.
Isn’t this wrong? They set the maxnum paramter to 4 here, but
expect 10 objects to be read.

Did I get this wrong?

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

–
Felix Fontein – @Felix_Fontein – https://felix.fontein.de/

28

One really annoying bug is gamma not working on X11:
https://bugzilla.libsdl.org/show_bug.cgi?id=1680
(yes, that one applies to both 1.2 and 2.0)
It’s due to an Xorg bug introduced in 2010 and I doubt that Xorg will
fix it in the near future - and even if they did it would take long
until it’s in the mainstream distributions…

In short: It sucks that setting gamma on X11 doesn’t work at all and SDL
should at least have a workaround setting gamma for the whole screen
(which still works on recent Xorg versions).

One could even try only to set gamma on the screen the window is on (for
multimonitor), but that implies the additional complexity of reacting to
window movement events.

Cheers,
DanielAm 27.01.2014 13:05, schrieb Gabriel Jacobo:

The 2.0.2 release is coming next week!

If you have any critical bugs that require fixing before that happens,
please say so as soon as possible. We don’t promise we’ll get all of
them fixed, but we’ll do our best.

Thanks!

–
Gabriel.

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

30

Not a critical bug, but SDL_ShowSimpleMessageBox doesn’t work in Android.
It would be appreciated if it could be fixed since this function is very useful.
Thanks.

PS: Please ignore this reply if it is already fixed.

31

Can you put this into a bug in bugzilla so it doesn’t get lost?

Thanks!On Mon, Feb 17, 2014 at 5:39 PM, Daniel C. Sinclair < daniel.c.sinclair at gmail.com> wrote:

Ok, I took some inspiration from Alex’s patch and came up with this:

diff -r 18ffe88a2148 src/video/cocoa/SDL_cocoaopengl.m
— a/src/video/cocoa/SDL_cocoaopengl.m Mon Feb 17 11:47:54 2014 -0500
+++ b/src/video/cocoa/SDL_cocoaopengl.m Mon Feb 17 16:58:39 2014 -0800
@@ -35,17 +35,14 @@

#define DEFAULT_OPENGL
"/System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib"

-#ifndef kCGLPFAOpenGLProfile
-#define kCGLPFAOpenGLProfile 99
+#ifndef NSOpenGLPFAOpenGLProfile
+#define NSOpenGLPFAOpenGLProfile 99
#endif
-#ifndef kCGLOGLPVersion_Legacy
-#define kCGLOGLPVersion_Legacy 0x1000
+#ifndef NSOpenGLProfileVersionLegacy
+#define NSOpenGLProfileVersionLegacy 0x1000
#endif
-#ifndef kCGLOGLPVersion_GL3_Core
-#define kCGLOGLPVersion_GL3_Core 0x3200
-#endif
-#ifndef kCGLOGLPVersion_GL4_Core
-#define kCGLOGLPVersion_GL4_Core 0x4100
+#ifndef NSOpenGLProfileVersion3_2Core
+#define NSOpenGLProfileVersion3_2Core 0x3200
#endif

@implementation SDLOpenGLContext : NSOpenGLContext
@@ -156,8 +153,6 @@
SDL_GLContext
Cocoa_GL_CreateContext(_THIS, SDL_Window * window)
{

  • const int wantver = (_this->gl_config.major_version << 8) |
  •                    (_this->gl_config.minor_version);
    SDL_VideoData *data = (SDL_VideoData *) _this->driverdata;
    NSAutoreleasePool *pool;
    SDL_VideoDisplay *display = SDL_GetDisplayForWindow(window);
    @@ -167,16 +162,16 @@
    SDLOpenGLContext *context;
    NSOpenGLContext *share_context = nil;
    int i = 0;

  • const char *glversion;

  • int glversion_major;

  • int glversion_minor;

    if (_this->gl_config.profile_mask == SDL_GL_CONTEXT_PROFILE_ES) {
    SDL_SetError (“OpenGL ES is not supported on this platform”);
    return NULL;
    }

  • /* Sadly, we’ll have to update this as life progresses, since we need
    to
  •   set an enum for context profiles, not a context version number */
  • if (wantver > 0x0401) {
  •    SDL_SetError ("OpenGL > 4.1 is not supported on this platform");
  • if ((_this->gl_config.profile_mask == SDL_GL_CONTEXT_PROFILE_CORE) &&
    (data->osversion < 0x1070)) {
  •    SDL_SetError ("OpenGL Core Profile is not supported on this

platform version");
return NULL;
}

@@ -184,19 +179,11 @@

 /* specify a profile if we're on Lion (10.7) or later. */

 if (data->osversion >= 0x1070) {

  •    NSOpenGLPixelFormatAttribute profile = kCGLOGLPVersion_Legacy;

  •    NSOpenGLPixelFormatAttribute profile =

NSOpenGLProfileVersionLegacy;

     if (_this->gl_config.profile_mask == SDL_GL_CONTEXT_PROFILE_CORE)

{

  •        if (wantver == 0x0302) {

  •            profile = kCGLOGLPVersion_GL3_Core;

  •        } else if ((wantver == 0x0401) && (data->osversion >=

0x1090)) {

  •            profile = kCGLOGLPVersion_GL4_Core;

  •        } else {

  •            SDL_SetError("Requested GL version is not supported on

this platform");

  •            [pool release];

  •            return NULL;

  •        }

  •        profile = NSOpenGLProfileVersion3_2Core;
   }

  •    attr[i++] = kCGLPFAOpenGLProfile;

  •    attr[i++] = NSOpenGLPFAOpenGLProfile;
   attr[i++] = profile;
    }

@@ -276,9 +263,33 @@

 if ( Cocoa_GL_MakeCurrent(_this, window, context) < 0 ) {
     Cocoa_GL_DeleteContext(_this, context);

  •    SDL_SetError ("Failed making OpenGL context current");
   return NULL;

    }

  • glversion = (const char *)glGetString(GL_VERSION);

  • if (glversion == NULL) {

  •    Cocoa_GL_DeleteContext(_this, context);

  •    SDL_SetError ("Failed getting OpenGL context version");

  •    return NULL;

  • }

  • if (SDL_sscanf(glversion, “%d.%d”, &glversion_major,
    &glversion_minor) != 2) {

  •    Cocoa_GL_DeleteContext(_this, context);

  •    SDL_SetError ("Failed parsing OpenGL context version");

  •    return NULL;

  • }

  • if ((glversion_major < _this->gl_config.major_version) ||

  •   ((glversion_major == _this->gl_config.major_version) &&

(glversion_minor < _this->gl_config.minor_version))) {

  •    Cocoa_GL_DeleteContext(_this, context);

  •    SDL_SetError ("Failed creating OpenGL context at version

requested");

  •    return NULL;
  • }
  • _this->gl_config.major_version = glversion_major;
  • _this->gl_config.minor_version = glversion_minor;
  • return context;
    }

The logic is:

  • OpenGL ES is not supported (would ARB_ES2_compatibility be enough to
    add it?)
  • core profile is only supported on 10.7 and up, so the OS version check
    is necessary
  • only compatibility or core profile can be requested; OS X gives you
    the latest version it supports
  • the version it gives must be greater or equal to the version requested
  • on success, update SDL’s GL attributes with the context version number

I can only test on 10.9.1 with hardware that supports 3.3 so it would be
good to test on other OS versions and hardware.

Daniel

On Thu, Feb 13, 2014 at 7:22 PM, Ryan C. Gordon wrote:

On 2/13/14, 7:47 PM, Daniel C. Sinclair wrote:

Hello, I am trying to use OpenGL 3.3 core profile in SDL2 (checked out
today) on OS X 10.9 and get this error:

This is sort of a mess, and we need to clean it up for 2.0.2.

–ryan.

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

32

On 2/22/14, 6:36 AM, RunningOn wrote:

Not a critical bug, but SDL_ShowSimpleMessageBox doesn’t work in Android.
It would be appreciated if it could be fixed since this function is very
useful.
Thanks.

PS: Please ignore this reply if it is already fixed.

It doesn’t appear to be implemented at all at the moment.

I’ve opened a bug for it here:

 https://bugzilla.libsdl.org/show_bug.cgi?id=2415

–ryan.

34

Le lundi, 27 janvier 2014 ? 13:05, Gabriel Jacobo a ?crit :

The 2.0.2 release is coming next week!

If you have any critical bugs that require fixing before that happens, please say so as soon as possible. We don’t promise we’ll get all of them fixed, but we’ll do our best.
Now that I found the issue, I’d be glad if we can do something about this one for 2.0.2.

https://bugzilla.libsdl.org/show_bug.cgi?id=2339

Daniel