When I exit out of the everyplay interface sometimes it will cause my entire unity rendering window to shift to the left and up by about 25%.
It seems to only happen the second time the everyplay interface is closed.
The latest 1.0.8 SDK introduced a change to Unity plugins native code level,
could you try commenting out
/* Force orientation check, orientation could have changed while Unity was paused */
UIInterfaceOrientation orientIOS = UnityGetGLViewController().interfaceOrientation;
ScreenOrientation orientation = ConvertToUnityScreenOrientation(orientIOS, 0);
UnitySetScreenOrientation(orientation);
from your projects Assets/Plugins/iOS/EveryplayUnity.mm and see if it works better
without it?
Related
I'm trying to debug a very strange behaviour of SpriteKit animation. It's quite easy to reproduce:
Create a new Game project in Xcode leaving all the options unchanged.
Open GameScene.swift and change line #23 from label.run(SKAction.fadeIn(withDuration: 2.0)) to label.run(SKAction.fadeIn(withDuration: 0.2))
Connect your phone and start a debugging session, observe how the text (Hello, World!) fades in and appears in full brightness. Well, so far, so good.
Stop the application from Xcode and start it again clicking its icon on your phone.
Observe how the text, although visible, is not faded in completely.
I found this trying to understand why my animation just stops half the way when my application loads. I assume that somehow the view stops refreshing if some initialisation step is longer than the animation but I don't know how to fix this. I also noticed that if you click on the screen it refreshes and the animated view appears in the final state.
iOS version: 10.3
I've discovered a serious issue with iOS11 and SpriteKit. The Game Scene during the transition is getting paused automatically (but only in iOS11).
After transitioning to the scene run
myScene.isPaused = false
and it should fix the issue, and should have no adverse affects when the game is run on iOS10
While running an ARKit session with world tracking enabled, the Xcode console shows log messages about (I presume: reduced) tracking performance, even though
The AR Session is in Normal tracking state,
I am using the device in a well-lit office room with plenty of "features" to detect, and
The device moves only subtly.
TLDR: I want to understand what could be causing them, what impact they could have, and how to prevent them, or (re)act to them when they do occur—NB. not simply hide these errors.
[Technique] World tracking performance is being affected by resource constraints [0]
[Technique] World tracking performance is being affected by resource constraints [1]
The Console app shows that these are coming from the library ARKit and fall in the logging category Technique.
Although they sound like warnings, the Console app shows their type as errors.
As expected while using world tracking, the Console app does show a lot of CoreMotion logs around the time of the errors, but those lines do not seem to contain any errors, warnings, or other info that helps me diagnose what's going on.
The moment the errors show up in the log, there are no delegate callbacks, but eventually (anything between 5 seconds or 50 seconds) the screen will freeze with the callback session failed:
Error Domain=com.apple.arkit.error Code=200 "World tracking failed." UserInfo={NSLocalizedDescription=World tracking failed., NSLocalizedFailureReason=World tracking cannot determine the device's position.}
The ARKit source/documentation doesn't provide any hints on what "resource constraints" might have caused the inability to determine the device's position, it just reads:
World tracking has encountered a fatal error.
I've tried (without success) to stop the warnings from appearing by:
Resetting the session tracking: still errors,
Resetting the session with removal of all ARAnchors: still errors,
Disabling plane detection (once no longer needed): still errors.
Pausing the AR Session silences the warnings (makes sense, since it means the device stops tracking its movement while paused), but when resuming the session, the warnings return.
When closing the session and re-creating it (i.e. dismiss VC and recreate), while not having moved the camera (or changed lighting) the problem doesn't always re-occur.
My best guess is that blinking TL-lights are the cause for the tracking performance warnings, given Apple's explanation how world tracking works:
… visual-inertial odometry. This process combines information from the iOS device’s motion sensing hardware with computer vision analysis of the scene visible to the device’s camera. ARKit recognizes notable features in the scene image, tracks differences in the positions of those features across video frames, and compares that information with motion sensing data.
(iPhone 6S, iOS 11 beta 4, no other apps running in the background)
Questions:
What is the difference between [0] and [1]?
What can cause these errors?
What impact do they have while the ARSession hasn't failed (yet)? I'm assuming we'll see "jumpy" models as the world coordinates supplied by the frame updates aren't accurate—NB. after resetting/stopping ARAnchor tracking the errors still occurred.
Will we know if the AR session is about to fail, or will it be unexpected? (Again, the ARSession doesn't fail immediately after the tracking state changes to "limited")
Is there some way to deal with this, e.g. freeing up some of these mentioned "resources"—or other ways to avoid running into these constraints?
Only allowing Portrait Device Orientation resolved this error for me.
I think this is xcode 9.1 bug. If you are use SceneKit: find where you set .backgroundColor = "your color" for ARSCNView or subclass. Comment this row and clean project.
This error happened to me because I manually added a view controller on the storyboard and added an ARSKView to it. This adds it as a child to a UIView which is by default a child view in a UIViewController. Therefore to support landscape and portrait orientation I had to add Auto-layout constraints, which for some reason triggered this error.
When I looked at the stock AR project, the ARSKView is an immediate child of the view controller, and it supports all view sizes and orientations out of the box without auto-layout constraints. When I set it up this way, the errors disappeared.
I think this is kind of bag because this issue happened for me only when I use constraints when I try to po something.
If I disable, for example, constraint below my code works well as expected.
I noticed that whenever the Control Center is being used on the iPhone, glkView:drawInRect: of my underlying app is not being called - hence the animation appears frozen. This happens as soon as the interaction with the Control Center starts - even when majority of the app is still visible. Animations that are not OpenGL based continue running just fine.
Is there any way to make the app call this method despite the Control Center showing, or is this an inherent limitation of OpenGL?
I have an iOS Unity Game developed. In order to help tester to track the bug, I have added one more module which will take the snapshot and then show a view to the tester to Annotate it. I am using Apple's GLPaint example : https://developer.apple.com/library/ios/samplecode/GLPaint/Introduction/Intro.html .
When I start annotating, I pause the Unity game and resume when the annotation is over. But there is one problem, when I try to resume the unity game, the app crashes weirdly with some error GL_INVALID_OPERATION
Check the trace log
Never used Unity, but it smells like the current GL context changes when you bring up the annotation view, and isn't restored properly when you return to the game. Give saving/restoring Unity's GL context a shot (see: EAGLContext +currentContext & +setCurrentContext:).
I have nearly completed my first app. In testing on the device, I am getting a crash when I press the home button, with the error message
libGPUSupportMercury.dylib`gpus_ReturnNotPermittedKillClient:
Based on these posts:
https://stackoverflow.com/search?q=how+to+shut+down+OpenGL
OpenGL ES crash on move background, iOS 5.1
I am pretty sure the problem is that my app is an extension of software that uses some sample code involving OpenGL (about which I have very little understanding) and that the OpenGL tasks are not shutting down properly on resignActive.
I tried the following in my AppDelegate with no luck:
- (void)applicationWillResignActive:(UIApplication *)application {
glFinish();
}
My app does not need to save any settings upon exit... it just needs to end.
Can anyone suggest a solution?
I am now working on a Sprite Kit game and I had a similar problem.
Check if you have on the screen the node that tells the FPS, because that might be rendering and causing the crash.. It did for me.
In applicationWillResignActive method I call my pause method as all of you.
*edit - and check for audio playing
To finish program at user push home button ?
on Xcode, choice Target and select Info tab.
Custom iOS Target Properties, add a Key named
Application does not run in background
and set Value
YES
Try it!
p.s. Not necessary write glFinish().