Execution of the command buffer was aborted due to an error during execution. Insufficient Permission (to submit GPU work from background) - swift

I have a SpriteKit project in which I'm suddenly seeing the following error repeatedly printed to the logs when testing on a real device:
Execution of the command buffer was aborted due to an error during execution. Insufficient Permission (to submit GPU work from background)
This happens when the app is in the background state.
Now, it's pretty obvious what's going on: SpriteKit uses Metal, and the latter is committing new work to the GPU when the app is backgrounded (which is something you can't do).
I've confirmed this theory by not loading my SpriteKit scenes. If I don't load the scenes, the problem does not occur.
What I've tried:
In my SceneDelegate's sceneWillResignActive(_:) function, I tried setting isPaused to true, like this:
func sceneWillResignActive(_ scene: UIScene) {
GameSceneHelper.scene.isPaused = true
CloudSceneHelper.scene.isPaused = true
}
...and then resuming the scenes in sceneDidBecomeActive(_:), like this:
func sceneDidBecomeActive(_ scene: UIScene) {
GameSceneHelper.scene.isPaused = false
CloudSceneHelper.scene.isPaused = false
}
I'd think that would work, but it doesn't. The error persists.
Question:
What's going on, here? Why am I suddenly getting this new error, and how do I solve the problem?
Thank you!
Edit:
I found a (ugly) workaround: Because my SpriteKit scenes are presented using SwiftUI, I can just set a boolean that indicates whether or not to show the scenes. There's no error when I do it this way.
Unfortunately, this results in undesirable behaviors: 1) when you swipe the app away, you can see the scene suddenly disappear, 2) when you bring the app to the foreground you can see the scene suddenly reappear, and 3) the app snapshot (that iOS takes of your app when you move it to the background) shows an empty screen because the scenes have already been hidden when it takes the snapshot.
I can't understand why this is happening in the first place; my understanding was that SpriteKit scenes are automatically paused when the app is in the background.
So, I'm still looking for a better solution -- and maybe an explanation.
Edit #2:
According to Apple's documentation, SpriteKit is, indeed, paused/resumed automatically when the app goes from/to the background:
When an application moves from an active to an inactive state, isPaused is automatically set to true. When an application returns to an active state, isPaused is automatically set to its previous value.

I heard back from Apple Support after sending them an Xcode project illustrating the problem. They recommended that I file a bug report using Feedback Assistant. So, it appears that this is a legitimate bug.
Apple says the problem is related to the use of the playSoundFileNamed, which is somehow making my update(_:) function get called while the app is in the background (and while the SpriteKit scene is paused!).
What's really weird to me is that I don't see other people reporting this problem. If all it takes to trigger this is the use of playSoundFileNamed, I would expect a lot of SpriteKit developers to have the same issue. Maybe SpriteKit isn't used that much? I don't know.

Related

Chipmunk Error: Cannot remove a body that was not added to the space while changing scenes

I am trying to make a game in Swift, using spritebuilder. I am able to change scenes from my main scene, but when I try to switch scenes from the scene I switched to, the app crashes with this error:
Aborting due to Chipmunk error: Cannot remove a body that was not added to the space. (Removed twice maybe?)
I never use the cpSpaceRemoveBody function, and in Thread 1, remove is called twice automatically (I think this is the problem).
I am switching scenes using:
let scene = CCBReader.loadAsScene("Gameover")
CCDirector.sharedDirector().presentScene(scene)
I have been looking and I can't find anything on why this is happening.
Well, this is embarrassing. I didn't have an onExit method.

In Corona SDK How to hide a group if application suspended?

I am building a word game and I want to hide the board when application is suspended?
the code looks fine however it givs a strange behaviour!!,
when I suspend the app nothing will happen but when i resume the application then the board will hide!!
local onSystem = function( event )
if event.type == "applicationSuspend" then
print("suspend")
board_group.alpha = 0
end
end
Runtime:addEventListener( "system", onSystem )
Note: you might wonder how do I know how the application looks when suspended?
the answer is: by pressing the home button twice.
example
SpellTower in normal state
https://dzwonsemrish7.cloudfront.net/items/430k0c0b0y0b413d0b42/Image%202012.11.12%208:08:24%20AM.png?v=4822f549
SpellTower after pressing the home button twice
https://dzwonsemrish7.cloudfront.net/items/280a1y0r2U3W321y1B2z/Image%202012.11.12%208:08:31%20AM.png?v=09c37567
you can see how they are hiding the letters, this is exactly what I want to do for my game, the only difference is i am using Corona SDK
When you do board_group.alpha = 0 you only has set a variable, the result will only take effect after a screen update.
But since the application is suspended... it won't update! So, changing any graphics on applicationSuspend don't work.
I believe the reason is because the application is not considered as suspended. In normal objective c programming it means that applicationWillResignActive is called when the user double clicks on the home button. So what you want to do is to add that code for this part.
Here is a flow of events:
http://www.cocoanetics.com/2010/07/understanding-ios-4-backgrounding-and-delegate-messaging/
Corona seems to have these events:
"applicationStart" occurs when the application is launched and all code
in main.lua is executed.
"applicationExit" occurs when the user quits the application.
"applicationSuspend" occurs when the device needs to suspend the application such as during a phone call or if the phone goes to sleep
from inactivity. In the simulator, this corresponds to the simulator
running in the background. During suspension, no events (not even
enterFrame events) are sent to the application while suspended, so if
you have code that depends on time, you should account for the time
lost to an application being suspended.
"applicationResume" occurs when the application resumes after a suspend. On the phone, this occurs if the application was suspended
because of a phone call. On the simulator, this occurs when the simulator was in the background and now is the foreground application.
So my guess is that you have to implement it outside of the corona API.
According to the corona documents you can implement them in the delegate:
You can intercept UIApplicationDelegate events via your implementation
of the CoronaDelegate protocol.
This protocol conforms to the UIApplicationDelegate protocol. Corona's
internal delegate will call your protocol's method if it is
implemented.
Please keep in mind the following:
Methods that Apple has deprecated will be ignored.
In most cases, your class' version will be invoked after Corona's corresponding version of the UIApplicationDelegate method. There is one situation in which your version will be called before.
In situations where the app is about to suspend or go to the background, your method will be called before Corona's version, e.g.
applicationWillResignActive: and applicationDidEnterBackground:.
http://docs.coronalabs.com/native/enterprise/ios/CoronaDelegate.html
But this is just a guess. Hope it helps!
Edit:
I was thinking, something really simple you could do is catch it outside and present a "pause" screen, then just hide it when the application enters foreground.
So if you can't do that (for now), one other option is to save application state when the application is about to terminate, and then set UIApplicationExitsOnSuspend = true in your plist file. This will cause the application to exit instead of suspending, which will avoid any screenshots, effectively "hiding" the board, etc. The downfall is, the app will have to read the session state when it launches again... this is only useful if your application can be designed to actually exit without losing your state, and is quite honestly, a little extreme. That said, it may be the only way to effectively do what you're trying to do.
Other ideas would be to see if you can add a large black layer to the screen, even though the application is suspending; perhaps this will somehow trigger an internal screen update by natively setting setNeedsDisplay. Also, instead of modifying the alpha, you might consider temporarily removing all of your layers and see if that has a similar effect.

Lag when authenticating local user on Game Center

For my cocos2d game, I authenticate the local user in the applicationDidFinishLaunching method of my AppDelegate. However, whenever the authentication is complete, it will cause a short lag in my game when the little "Welcome back, X" message slides down and back up. The problem is I have no control over when this authentication is complete – obviously the duration is highly dependent on the data connection of the device.
Sometimes the message (and the un-avoidable accompanying lag) appears as soon as when I am in the menu scene, which is somewhat acceptable, since my menu is more or less static. More often than not, it happens later, when the game has already started. Because my game is an endless scroller, the message always causes a lag in the movement of the player, even causing the player to die sometimes (half a second of lag is enough :-/).
How might I circumvent this? I used to have a loading scene right before my menu scene to load some of my assets, and because the loading takes a while, there was always a good chance that the authentication is completed at the loading scene, but of course I can't guarantee that it will be true!
Game Center can make the game freeze for a little as its starts if your connection isn't great. I doubt that loading GameCenter on a different thread would be a good idea (or even have an effect on that) but what you could do as a work around of the issue you are having is to give the game a 3-2-1 countdown before it starts scrolling/moving. would give a little more time for game center and time for the player to build his focus, starting serious in a game straight away might not be to the liking of some players.
I hope this helps.

Objects not being released fast enough, causing an app relaunch crash

I have an app where I have 5 sets of animations that I'm storing in an array. The animations get picked to play randomly after a button touch. This is all working perfectly, however I noticed a bug when I quit the app and reopen immediately, I'll see my main view, then it'll jump to my second view that has the animation in it. (This shouldn't happen since you have to tap the main view in order for it to modally swap in the second view. If I interact with it everything works for a few seconds, then it closes with no crash log.
I finally realized that some of the objects must not be getting released fast enough, since if I close the app and wait three seconds, then reopen, everything executes fine.
I didn't want to put down code to show as this is more of a brainstorming question. I'd love any insight that could point me the right way. I changed a lot of my code to get rid of convenience methods and have all my variables defined and then released in my dealloc.
Is there a way to truly tell the app to kill everything on quit? It's not set to run in the background so this is a bit odd. Thanks for your help I'm still new to this and learning!
Alright, after working on this all weekend and doing more research comparing a barebones version of my app to my prerelease version, I traced memory leaks to the Flurry Analytics api that I am using. Apparently I was suffering from the same issue as the post here: App hangs on restart with latest Flurry SDK and ios4 . I resolved this by setting these optional methods to false, since they take extra time to send data after the app terminates, and depending on the connection it takes a few seconds.
FlurryAnalytics.h
/*
optional session settings that can be changed after start session
*/
+ (void)setSessionReportsOnCloseEnabled:(BOOL)sendSessionReportsOnClose; // default is YES
+ (void)setSessionReportsOnPauseEnabled:(BOOL)setSessionReportsOnPauseEnabled; // default is YES
Hope this helps anyone else who experienced something similar to me!
All apps can enter the background by default. Normally they do not do anything there, but they stay there in a frozen state and when you open them again, your program does not restart, it just picks up where it left off.
Anything that's set as an animation delegate might not get released, since it's retained for that purpose until the animation completes.
You can add an applicationDidEnterBackground: method to your app delegate to get informed when your app is going into the background, but exactly what you need to do depends on the design of your app. You can also add applicationWillEnterForeground: to do anything you need to do differently when restarting, as opposed to newly starting.
You might be able to force your animations to complete by starting a new animation with duration 0.0 (or very short if for some reason you can't do that).
If this happens only if your app goes to bkgnd and comes back AND you don't mind if the app restarts everytime it comes back then just put UIApplicationExitsOnSuspend in your app's plist. In all my cases where these and other bad things happen with apps going to and returning from bkgnd this helped.
While you might still see the app on the buttom when double tapping it is really stopped and will restart. Apps that show on the buttom do not always have to run or be stored in the bkgnd I learned.
ps. don't forget to set the value of UIApplicationExitsOnSuspend to YES

App crashes on backgrounding because of SimpleAudioEngine

So I׳m trying to play some effects in my Cocos2D game using SimpleAudioEngine , but after I have added them my app crashes when it goes to background (multitasked).
I searched for this problem in the internet but all the solutions that I found didn't work for me. What I did find out is that this problem happens because my app is somehow trying to play sounds when backgrounded.
In console it shows me (which is the same error I found other people had):
sgx error (background gpu access not permitted):
And another thing, when I run my app on the simulator, or even on my device while debugging carefully (going line-by-line with XCode while the app is running) this doesn't happen.
I just had this issue. I resolved it by having a bool to check if the app is running or in background that I set to true when the app goes to foreground ( applicationWillEnterForeground ) and that I set to false when the app goes to background ( applicationDidEnterbackground ) . So using the bool you can tell if the app is in the background and if it is, I just exit out of drawView function in EAGLView (thus not doing any graphics rendering which was causing the error).
I am a very dodge programmer but that method has worked for me and I hope it works for someone else. I did not need to unload and reload my sounds or anything and my app now has Multitasking XD
I was experiencing this, on about 25% of the occasions that my application re-entered the foreground. Like you, when I removed the sounds, the problem went away. That is how I came across your question here.
I may have found a solution to this. I have made what appears to be an unrelated change, but the problem seems to have gone away. Now, when my app enters the background, I invalidate my main scheduled timer. When my app re-enters the foreground, I then re-schedule the timer (after reloading my sounds, which I completely shut down on entering background).
So far, the problem has not come back. I would be interested to know if this helps.
I just resolved this issue on my end. Here's what was wrong in my case and, from what I can tell from the other answers and comments on this page, many other people's case as well:
By default, when I started my project, CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->resume(); were both being called twice, once by (void)applicationWillResignActive:(UIApplication *) and (void)applicationDidBecomeActive:(UIApplication *) respectively in AppController.mm, and once by AppDelegate::applicationDidEnterBackground() and AppDelegate::applicationWillEnterForeground() respectively in AppDelegate.cpp.
Make absolutely sure that these methods are only being called once, in AppController.mm. In AppDelegate.cpp, instead make sure that you are calling CCDirector::sharedDirector()->stopAnimation(); in place of CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->startAnimation(); in place of CCDirector::sharedDirector()->resume();.
Hope that's helpful to anyone else stuck in this crappy situation!
Are you sure it's related to audio? "background gpu access" sounds like it's using OpenGL.
I had the same issue in my application and spent some 4 hours to find out. Going background was OK the first time, but crash application the second time. With a short error message related to OpenGL. I had the same questions: how audio can crash graphics. But it wasn't a question of audio, but a question of notifications...
I discovered that going foreground was creating 2 timers in my custom level meter class.
I had registered UIApplicationWillEnterForegroundNotification and UIApplicationWillResignActiveNotification. Then, going background invalidated only one, since I registered only on notification... That was it!
One need's count its notifications!