IOS 8 progress |
Eric Wing
Guest
|
On 11/5/14, Alex Szpakowski wrote:
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:
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:
_______________________________________________ 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.
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:
|
|||||||||||||
|
IOS 8 progress |
Eric Wing
Guest
|
On 11/20/14, Alex Szpakowski wrote:
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:
_______________________________________________ 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:
_______________________________________________ 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:
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:
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:
_______________________________________________ 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:
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:
_______________________________________________ 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:
|
|||||||||||||||
|
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:
_______________________________________________ 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:
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:
_______________________________________________ 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:
|
|||||||||||||||
|
IOS 8 progress |
Alex Szpakowski
Guest
|
I agree – I’ve asked Sam in the other thread whether the change is acceptable for an SDL point release.
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:
_______________________________________________ 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 ?Â
On Mon, Dec 1, 2014 at 11:36 AM, Alex Szpakowski wrote:
|
|||||||||||||||||
|