Just me, or SpriteKit in GMs terribly broken?

Reply to myself.

After hours of work (and looking into other different threads by others) the issue with SKSprideNode(imageNamed:) is completely random. There is no way to determine which images might not load.

However, I have found a fix that works for this problem. If you specify a .zPosition for each and *every* sprite node plus set "self.ignoresSiblingOrder = false" in SKView, then it does appear that all nodes are showing. Of course, I'll keep playing but hopefully this will give some relief for a few people.

i am having terrible problems with physics bodies - nothing seems to work right with their placement which is messing up contact and collision detection. I spent hours trying to figure it out but can't come up with a solution to get the physics body placed correctly. I'm making a pretty simple game too! It's not that complicated. I'm just at a loss because I would like to move on but I can't even find a work around to make it work. Should I try going to UIKit and just do all my own physics management? Seems so backword.

I haven't really been able to nail this down yet, but I've noticed some really bizarre behavior stemming from the 'dynamic' property on SKPhysicsBody... It doesn't seem to mean what it did in iOS 8 anymore... the docs say about 'dynamic':

"The default value is

YES

NO

But I keep seeing odd side effects that are largely resolved by twiddling the 'dynamic' property of bodies in non-intuitive ways:

• contact tests fail entirely if the two bodies in contact have different values for 'dynamic', or only fire for the 'dynamic' body
• collision simulation of two 'dynamic' bodies can result in unpredictable body movement (including jumps & pass-throughs)
• if a node's body is 'dynamic' then its position relative to its own node is variable and affected by simulation

I have a game that is in development and I ported over to iOS9 (and Swift 2) and I'm using SKPhysics bodies, some dynamic some not, and I'm not having any of the issues you guys are mentioning. They all operate exactly as I expect (and same as they did in iOS8).

Clearly that doesn't help you guys, but I just wanted to balance it out, because there must be something else set differently that is causing you to have these problems.

My game is relatively complex in terms of multi-level node trees, fast moving sprites, movement using both physics and actions.

Are you able to put a simple test harness together to reproduce these issues?

You are the exception.

Perhaps put together a test harness that shows things working correctly so everyone else can see how you did things.

There is DEFINITELY something broken.

I have a chessboard set up. All the Squares A1Square B1Square etc...

Anyway, I will move a piece to A1Square.Position.

Well like every 100 or so times it moves it to the incorrect position.

I will have mnove piece to B1Square.Position and it works maye 150 times... and then every once in a while it MOVES WRONG.

Amazingly, I don't think this is a programming error. I think it is SPRITEKIT.

I think one of the problems I was having was simply trying to set the center in the initializers for the physics bodies. What they are really refering to is an anchor point. By using the initializers that did not specify a center I had a lot better luck today getting physics contacts up and and working. I think the wording is kind of confusing in the initializers. But for all my difficulty yesterday, things where working better for me today.

About that initializer, the docs say center is: The center of the square(physicsBody) in the owning node’s coordinate system. I assume the version of the initializer without center: defaults to CGPointZero because the sprite and physics body generally should line up. When I use the initializer and explicity use CGPointZero for center, the physics body still doesn't line up with the sprite and that makes no sense.

So we have Xcode beta 3 (released yesterday) and os9.1. And none of the bugs I experience is not fixed. I sen isolated bug to the ticket because Apple asked and there is silence for almost a month.

Same boat as everyone here, I have a SpriteKit based game that is 95% complete using iOS 8 / XCode 6.4, SK was working extremely well, I spent hours optimizing atlases, etc. Installed Xcode 7 beta 4/5 to check it out, and my game was / is completely broken. I've now installed the new GM and betas, spent 3 days converting my game over from a fresh project, piece by piece seeing if I can pinpoint and fix everything that was broken but no dice. Going from a completely failing build, I've got the game up and running with no changes to the core code, but it uses 4-5x the memory now (from ~150mb -> 1gb), has quadruple the number of draw calls (from 8-10 -> 40-50), won't even launch on device due to the memory issues. My biggest issue is it seems like they screwed up they way texture atlases worked, kind of a core feature to change / release busted. Was looking forward to porting to AppleTV, really making me consider dropping the framework and going cross platform after months of work with no solution in sight.

Today I ran into the new issue. If you try to use SKShapeNode with too many elements in it, the app will crash.

Very similar to this

http://stackoverflow.com/questions/32677503/spritekit-and-uikit-compatibility-opengl-error-when-migrating-to-swift-2

The log will say

Assertion failed: (length + offset <= _length), function commit_data, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/Jet/Jet-1.50/Jet/jet_types_OpenGL.h, line 863.

Filed the bug number 23087759

Spent several hours to solve the problem, but SKEmitterNode was always invisible inside SKCropNode

(Xcode Version 7.0.1 (7A1001), iOS 9.0.2 on iPad Air 2)

And the only working solution is a trick with dispatch_async( ... )

Thanks ptsochantaris

9.1 is out.

Sprites are still randomly misplaced. SKShapeNode crashes the game.

But hey, we've got the new emojis!

**Massive sigh**

I've basically had to re-engineer my game so that there are fewer nodes on screen, in order for it to run at all. And by a factor of 10. I'm also waiting for information from engineering. The person assigned to my case has corroborated my findings from the sample program I provided, but doesn't seem to have any more info from the Sprite Kit team.

@indiedeveloper said: "Many performance issues has been solved by the engineers, and they seem to be aware of the bugs."

This is the third time I've seen you make these sorts of unsubstantiated claims - no corroborating evidence, nor proof.

Where is the list of changes made?

Care to elaborate on ANY specific performance issues that have been solved?

Just seeing the fact that any single specific performance issue has been recognised and then fixed would go a little ways to supporting the idea the that they are doing something, and aware.

Empty anecdotal evidence seeds only further doubts.