The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
IOS 8 progress
Eric Wing
Guest

On 11/5/14, Alex Szpakowski wrote:
Quote:
I guess this is a good time to mention that I have a fork[1] of SDL with
many improvements and fixes to the iOS backend. It might need a bit more
testing before it's ready to be merged into mainline SDL, but that's my
intention.

Here's an incomplete changelog:

- Retina resolutions are handled like they are in OS X (via the
SDL_WINDOW_ALLOW_HIGHDPI flag.)
- The UIKit backend uses ARC instead of manual reference counting.
- Updated a lot of UIKit code to use cleaner and more modern Objective-C.
- Fixed several rotation/orientation and fullscreen-related bugs,
especially on iOS 7+.
- Fixed many memory leaks by adding missing autorelease pool blocks to the
UIKit code.
- Removed the custom iOS splashscreen code, since it was causing several
rotation bugs and it didn't support newer iOS devices and versions.
- The SDL_HINT_ACCELEROMETER_AS_JOYSTICK hint is respected on iOS.
- Added iOS support for sRGB OpenGL contexts.
- Added support for native-resolution rendering (when ALLOW_HIGHDPI is
enabled) on the iPhone 6 Plus - i.e. 1080x1920 rather than 1242x2208.
- Added iOS-specific SDL_iPhoneGetViewRenderbuffer and
SDL_iPhoneGetViewFramebuffer functions.

Feedback is appreciated, especially with the new functions I added. I'm not
sure if they should exist, especially if I eventually add MSAA support to
OpenGL contexts on iOS (since that needs a separate 'resolve' framebuffer
and renderbuffer.)

[1]: https://bitbucket.org/slime73/sdl-experiments/branch/iOS-improvements


Wow, very impressive. But, wait, no Metal backend for the SDL 2D
renderer? Ha ha.

We're going to have to resolve the differences for the launch screen
code. My patch's behavior adds new behavior only if iOS 8 is detected
at runtime, and then falls back to legacy behavior.

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Eric Wing
Guest

On 11/5/14, Alexander Chaliovski wrote:
Quote:
Nice work !
I can test it when you are done.
Have you tested on actual device ?


Sorry for the delay. I finally posted everything and submitted the
bug. I did not test on a real device, but went through all the
permutations of the iOS Simulator available to me. I did see behavior
differences between iOS 8 simulator and iOS 7 simulator so I have
confidence they are representative in this case. But real device
testing (and additional testing) is welcome.


Here is the Bugzilla link and the copy of the body is inline below.

I have a pull request for support for iOS 8's new LaunchScreen NIBs.
Apple changed their way of handling it yet again. Their motivation was
that it is getting unwieldy to provide so many different launch screen
permutations for every device and orientation. Their "Autolayout"
system can handle this in a simplified/unified way, so for iOS 8, this
is the new way to do it.

Furthermore, this is the only way to get the "Optimized for iPhone 6
and iPhone 6 Plus" badge on the App Store as far as I can tell. So
this patch is necessary.

This normally should be automatically handled by the operating system,
but because SDL reverse-engineers and reinvents the CocoaTouch launch
and run loop, SDL doesn't inherit this new behavior.

This patch uses the old launch screen handling code as a starting
point. It mirrors the original technique, i.e. creates a new class to
handle it. To not break legacy behavior, a runtime check is done for
iOS 8 or greater.

Additionally, this patch conforms to Apple rules of behavior. This
only kicks in if the user has made an entry in their Info.plist.
They must specify the key UILaunchStoryboardName and supply the name
of the NIB/XIB file (without the extension).
Example:
<key>UILaunchStoryboardName</key>
<string>LaunchScreen</string>

Presumably, the NIB/XIB is already correctly made with AutoLayout for
their launch screen.

Omitting the Info.plist setting will then revert to legacy behavior.
The code will result in Cocoa throwing an exception if the Info.plist
specifies the key, but the corresponding nib does not exist.


Additional note:
I noticed the legacy iOS 7 behavior does not conform to the rules
Apple has in their documentation. iOS 7 is supposed to allow you to
manually specify launch screens for different resolutions, devices,
and orientations, but SDL lacks this code. I consider this a bug and
was scratching my head for a really long time. While it would be good
to fix, the rate of latest iOS adoption may render the need for that
obsolete within 3 months.

Furthermore, AutoLayout does technically work on iOS 7. It might be
possible to activate this new iOS 8 behavior for iOS 7. However, some
people might be surprised if we do this.


Testing notes:
I tested on all the different permutations of devices on the iOS
Simulator for both iOS 8 and 7, to verify that both the Launch Screen
was working on iOS 8, and the legacy path was taken on 7.

I did not test on a real device though. (Key signing problems at the moment.)

https://bitbucket.org/ewing/sdl_ios8launchscreen

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alex Szpakowski
Guest

The new Storyboard/XIB method is just one way to get native iPhone 6 / 6 Plus support, I believe. The other way is to provide appropriately-sized launch image files in your app’s Xcode project – just like you’d do for older iOS devices and versions.

I’ve successfully used launch images sized for the iPhone 6 Plus in order for my app to use the proper resolution (1242x2208 @3x, and native 1080x1920 on the device.)

On Nov 20, 2014, at 8:16 PM, Eric Wing wrote:

Quote:
I have a pull request for support for iOS 8's new LaunchScreen NIBs.
Apple changed their way of handling it yet again. Their motivation was
that it is getting unwieldy to provide so many different launch screen
permutations for every device and orientation. Their "Autolayout"
system can handle this in a simplified/unified way, so for iOS 8, this
is the new way to do it.

Furthermore, this is the only way to get the "Optimized for iPhone 6
and iPhone 6 Plus" badge on the App Store as far as I can tell. So
this patch is necessary.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alex Szpakowski
Guest

If I ever get an iOS device that supports Metal then I do want to add CAMetalLayer support for SDL windows on iOS, at least. I can’t do that right now, though. Smile


One of the reasons I removed the faux splash image code is because it caused really nasty rotation bugs. We’ll have to make sure that doesn’t happen with your new code.

On Nov 20, 2014, at 8:13 PM, Eric Wing wrote:
Quote:

Wow, very impressive. But, wait, no Metal backend for the SDL 2D
renderer? Ha ha.

We're going to have to resolve the differences for the launch screen
code. My patch's behavior adds new behavior only if iOS 8 is detected
at runtime, and then falls back to legacy behavior.

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Eric Wing
Guest

On 11/20/14, Alex Szpakowski wrote:
Quote:
The new Storyboard/XIB method is just one way to get native iPhone 6 / 6
Plus support, I believe. The other way is to provide appropriately-sized
launch image files in your app's Xcode project - just like you'd do for
older iOS devices and versions.

To be clear, I'm talking about the footnote on the App Store. You can
make an app that runs fine without the LaunchScreen NIB on iPhone 6
and 6 Plus. But from everything I've found, the only way to get that
badge/footnote that says "Optimized for iPhone 6 and iPhone 6 Plus" is
to use the LaunchScreen NIB system. As far as I can tell, using the
legacy system is not sufficient in getting the badge.


Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alex Szpakowski
Guest

I understand what you’re saying, but I don’t think it’s correct. iOS just needs to understand that the app can support the iPhone 6 / 6 Plus resolutions, and then it will give the correct resolutions at runtime and the App Store will tell users that it’s supported. Having appropriately-sized standard launch images should accomplish this.

I believe Unity still uses the standard/old launch image system, and recent versions do export apps that fully support the iPhone 6 Plus (including the notice on App Store pages.)

The Apple HIG page says:
"You use a launch XIB or storyboard file to indicate that your app runs on iPhone 6 Plus or iPhone 6.”
"Although it’s best to use a launch file for iPhone 6 and iPhone 6 Plus, you can instead supply static launch images if necessary.”

i.e. the first sentence doesn’t exclude static launch images from being used to indicate iPhone 6 Plus support, it just says what the XIB/storyboard can do.

On Nov 20, 2014, at 8:36 PM, Eric Wing wrote:

Quote:
To be clear, I'm talking about the footnote on the App Store. You can
make an app that runs fine without the LaunchScreen NIB on iPhone 6
and 6 Plus. But from everything I've found, the only way to get that
badge/footnote that says "Optimized for iPhone 6 and iPhone 6 Plus" is
to use the LaunchScreen NIB system. As far as I can tell, using the
legacy system is not sufficient in getting the badge.


Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alex Szpakowski
Guest

Actually I just read a bunch of posts by users on the Apple developer forums saying the same thing as you – it looks like I was wrong. Sorry for the noise!

On Nov 20, 2014, at 8:50 PM, Alex Szpakowski wrote:

Quote:
[…]

On Nov 20, 2014, at 8:36 PM, Eric Wing wrote:

Quote:
To be clear, I'm talking about the footnote on the App Store. You can
make an app that runs fine without the LaunchScreen NIB on iPhone 6
and 6 Plus. But from everything I've found, the only way to get that
badge/footnote that says "Optimized for iPhone 6 and iPhone 6 Plus" is
to use the LaunchScreen NIB system. As far as I can tell, using the
legacy system is not sufficient in getting the badge.


Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Eric Wing
Guest

On 11/20/14, Alex Szpakowski wrote:
Quote:
I understand what you're saying, but I don't think it's correct. iOS just
needs to understand that the app can support the iPhone 6 / 6 Plus
resolutions, and then it will give the correct resolutions at runtime and
the App Store will tell users that it's supported. Having
appropriately-sized standard launch images should accomplish this.

If you sign into Apple Developer Forums and search for the string,
every thread says the NIB is required (including complaints about the
policy).

Additionally, the Corona forums have this long thread that confirms
with their own experience.
http://forums.coronalabs.com/topic/51801-how-to-activate-optimized-for-iphone-6-iphone-6-plus/

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Eric Wing
Guest

On 11/20/14, Alex Szpakowski wrote:
Quote:
Actually I just read a bunch of posts by users on the Apple developer forums
saying the same thing as you - it looks like I was wrong. Sorry for the
noise!


No problem.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alex Szpakowski
Guest

Next question: is any custom code even necessary to support Launch Screen storyboards? I just created a new one in Xcode and set one of the SDL demos for iOS to use it, and it worked as expected in the Simulator without any new code in SDL.

(I am using my branch of SDL which doesn’t have the old buggy faux-splashscreen code.)

On Nov 20, 2014, at 9:02 PM, Eric Wing wrote:

Quote:
No problem.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Eric Wing
Guest

On 11/20/14, Alex Szpakowski wrote:
Quote:
Next question: is any custom code even necessary to support Launch Screen
storyboards? I just created a new one in Xcode and set one of the SDL demos
for iOS to use it, and it worked as expected in the Simulator without any
new code in SDL.

(I am using my branch of SDL which doesn't have the old buggy
faux-splashscreen code.)

I don't know. I was based on the main branch. And without my code, it
definitely did not work. Since the pre-iOS 7 and iOS 7 behavior (I had
an explicit Info.plist for all the different types) didn't work, I
assumed iOS 8 wouldn't work either. But I didn't think of trying it.

But either way, I still need the legacy pre-iOS 8 behavior to kick in
on older OSes, so I think the patch needs to stand. (As noted, we
could try to extend the new LaunchScreen behavior to iOS 7, but that
means we need this code still.)


Thanks,
Eric

--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alex Szpakowski
Guest

I should mention that I’ve been using standard launch images (Images.xcassets, etc.) fine as well with no code for it at all in SDL. The only reason the faux splash image code was in SDL in the first place was to keep the regular launch image displayed for longer than normal.

Since that’s now gone (in my branch), launch images are now completely out of SDL’s domain/scope. They seem to work fine with no code in SDL and SDL doesn’t need to touch them, just like app icon images.

To get launch images working pre-iOS 8, you’ll just need to supply the properly-sized images via an Xcode icon set – it becomes part of the Xcode project’s build configuration file, rather than code in SDL.

On Nov 20, 2014, at 10:14 PM, Eric Wing wrote:

Quote:
I don't know. I was based on the main branch. And without my code, it
definitely did not work. Since the pre-iOS 7 and iOS 7 behavior (I had
an explicit Info.plist for all the different types) didn't work, I
assumed iOS 8 wouldn't work either. But I didn't think of trying it.

But either way, I still need the legacy pre-iOS 8 behavior to kick in
on older OSes, so I think the patch needs to stand. (As noted, we
could try to extend the new LaunchScreen behavior to iOS 7, but that
means we need this code still.)


Thanks,
Eric

--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alexander Chaliovski
Guest

Hey Alex,


Just a quick question because I am using game engine with dependency to SDL which is currently failing for IOS 8 . I was thinking of using your branch of SDL as it is more compatible to IOS 8 . But I am not sure have you changed any high level stuff like name of the functions or files. Is everything fully compatible between your changes and SDL 2.0.3  ?


On Fri, Nov 21, 2014 at 2:31 AM, Alex Szpakowski wrote:
Quote:
I should mention that I’ve been using standard launch images (Images.xcassets, etc.) fine as well with no code for it at all in SDL. The only reason the faux splash image code was in SDL in the first place was to keep the regular launch image displayed for longer than normal.

Since that’s now gone (in my branch), launch images are now completely out of SDL’s domain/scope. They seem to work fine with no code in SDL and SDL doesn’t need to touch them, just like app icon images.

To get launch images working pre-iOS 8, you’ll just need to supply the properly-sized images via an Xcode icon set – it becomes part of the Xcode project’s build configuration file, rather than code in SDL.

On Nov 20, 2014, at 10:14 PM, Eric Wing wrote:

Quote:
I don't know. I was based on the main branch. And without my code, it
definitely did not work. Since the pre-iOS 7 and iOS 7 behavior (I had
an explicit Info.plist for all the different types) didn't work, I
assumed iOS 8 wouldn't work either. But I didn't think of trying it.

But either way, I still need the legacy pre-iOS 8 behavior to kick in
on older OSes, so I think the patch needs to stand. (As noted, we
could try to extend the new LaunchScreen behavior to iOS 7, but that
means we need this code still.)


Thanks,
Eric

--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


IOS 8 progress
Alex Szpakowski
Guest

I haven’t changed any public SDL APIs compared to the current SDL 2.0.4 / mercurial version. The biggest non-bugfix change to functionality is that SDL_CreateWindow now only enables Retina-resolution if the SDL_WINDOW_ALLOW_HIGHDPI flag is used, and once it’s enabled you’ll need to use SDL_GL_GetDrawableSize (or SDL_GetRendererOutputSize if you’re using the SDL_Render API) to get the size of the drawable in pixels. SDL_GetWindowSize and the active video display modes now always give their sizes in ‘points’ rather than pixels.

Both the official Mercurial / 2.0.4 version of SDL for iOS and my branch also require you to link your app with the CoreMotion framework, which you didn’t need to do in SDL 2.0.3.

On Nov 30, 2014, at 8:16 PM, Alexander Chaliovski wrote:

Quote:
Hey Alex,

Just a quick question because I am using game engine with dependency to SDL which is currently failing for IOS 8 . I was thinking of using your branch of SDL as it is more compatible to IOS 8 . But I am not sure have you changed any high level stuff like name of the functions or files. Is everything fully compatible between your changes and SDL 2.0.3 ?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Rainer Deyke
Guest

On 01.12.2014 03:22, Alex Szpakowski wrote:
Quote:
I haven’t changed any public SDL APIs compared to the current SDL
2.0.4 / mercurial version. The biggest non-bugfix change to
functionality is that SDL_CreateWindow now only enables
Retina-resolution if the SDL_WINDOW_ALLOW_HIGHDPI flag is used, and
once it’s enabled you’ll need to use SDL_GL_GetDrawableSize (or
SDL_GetRendererOutputSize if you’re using the SDL_Render API) to get
the size of the drawable in pixels. SDL_GetWindowSize and the active
video display modes now always give their sizes in ‘points’ rather
than pixels.

Wait, what? Why would you do that?


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alex Szpakowski
Guest

A few reasons:

- It matches SDL’s behaviour in OS X (and presumably Windows and Linux, once high-dpi support is implemented in those backends.)
- It lets you render at a high resolution while keeping the physical size of what you render consistent with what users expect on their device. In other words you can easily use the “dpi scale” of the device. This is actually really useful.
- You can save performance on older / lower-end retina iOS devices by disabling high-dpi awareness at runtime. If you’re using everything correctly, doing so will just make things look a bit less sharp to users while saving a ton of memory and GPU pixel processing performance.

There was some discussion about what SDL’s high-dpi API would be, a year or so ago: https://bugzilla.libsdl.org/show_bug.cgi?id=1934

On Dec 1, 2014, at 4:48 AM, Rainer Deyke wrote:

Quote:
Wait, what? Why would you do that?

--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alexander Chaliovski
Guest

Hi Alex,

This might cause issues where SDL is already implemented as back-end as it deviates from the original behaviour. I wonder if such change would be accepted on the main branch. I am a bit confused when we call SDL on Iphone it just opens a a windows with resolution x y no matter if it is retina or not. Is it possible to have preprocessor macro for the old behaviour ?  


On Mon, Dec 1, 2014 at 9:01 AM, Alex Szpakowski wrote:
Quote:
A few reasons:

- It matches SDL’s behaviour in OS X (and presumably Windows and Linux, once high-dpi support is implemented in those backends.)
- It lets you render at a high resolution while keeping the physical size of what you render consistent with what users expect on their device. In other words you can easily use the “dpi scale” of the device. This is actually really useful.
- You can save performance on older / lower-end retina iOS devices by disabling high-dpi awareness at runtime. If you’re using everything correctly, doing so will just make things look a bit less sharp to users while saving a ton of memory and GPU pixel processing performance.

There was some discussion about what SDL’s high-dpi API would be, a year or so ago: https://bugzilla.libsdl.org/show_bug.cgi?id=1934

On Dec 1, 2014, at 4:48 AM, Rainer Deyke wrote:

Quote:
Wait, what?  Why would you do that?

--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


IOS 8 progress
Alex Szpakowski
Guest

Quote:
This might cause issues where SDL is already implemented as back-end as it deviates from the original behaviour.

I agree – I’ve asked Sam in the other thread whether the change is acceptable for an SDL point release.

Quote:
I am a bit confused when we call SDL on Iphone it just opens a a windows with resolution x y no matter if it is retina or not.

I can illustrate with some screenshots of a modified version of one of the SDL iOS test apps.

Here it is running on an iPad 2: http://i.imgur.com/pH2ubIv.png
The iPad 2 doesn't have a high-dpi / Retina screen, and has a resolution of 768x1024.

Here’s the same test using the old SDL 2.0.3 way of doing things on iOS, running on an iPad Air: http://i.imgur.com/YNPgFIW.png
The iPad Air has the same physical screen size as the iPad 2, but it has a Retina resolution of 1536x2048 (I’ve scaled down the image by 50% so it’s easier to compare with the iPad 2.)

Here’s the same test using my changes with high dpi-aware code, running on the iPad Air again: http://i.imgur.com/7Ln3hNX.png
(I’ve also scaled down that image.)

If you only go by pixels without accounting for the retina DPI scaling, then at least your interface (and probably your whole game if it’s 2D) will look tiny on modern iOS devices and normal-sized on older ones.

If you use the SDL_Render API you can use SDL_RendererSetLogicalSize, but that’s not quite the same as this (and they can work in combination), especially since it pretends that a 3.5” iPhone and a 10” iPad have the same size.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alex Szpakowski
Guest

That actually wasn’t on this mailing list, my bad! In any case it’s been asked, and if it turns out that the change is too big (or completely unwanted) then I’ll revert that part of my branch to SDL 2.0.3’s behaviour.

On Dec 1, 2014, at 6:56 AM, Alex Szpakowski wrote:

Quote:
I’ve asked Sam in the other thread whether the change is acceptable for an SDL point release.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IOS 8 progress
Alexander Chaliovski
Guest

I have done this for Ogre3d where my contentScaleFactor matches the screen bounds. There could be be another multiplier to tweak the ratio between the two. Is that something similar to what you are doing or I am missing something ? 

Quote:
MyView* myView = [[MyView alloc] initWithFrame:CGRectMake(0,0,width,height)];
myView->viewcontroller = GetSDLViewController(sdlWindow);
[(GetSDLViewController(sdlWindow)).view addSubview:myView];
myView.contentScaleFactor = [UIScreen mainScreen].scale;



On Mon, Dec 1, 2014 at 11:36 AM, Alex Szpakowski wrote:
Quote:
That actually wasn’t on this mailing list, my bad! In any case it’s been asked, and if it turns out that the change is too big (or completely unwanted) then I’ll revert that part of my branch to SDL 2.0.3’s behaviour.

On Dec 1, 2014, at 6:56 AM, Alex Szpakowski wrote:

Quote:
I’ve asked Sam in the other thread whether the change is acceptable for an SDL point release.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org