Just me, or SpriteKit in GMs terribly broken?

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.

Thanks for filing the bug for this, pavelgubarev.

Lost a month of productivity because of this with no end in sight. And NO Apple I'm not going to make example scene after example scene documenting problems. IT'S NOT MY JOB! Were the engineers not aware of these basic issues when they released the framework? Shouldn't they have tons of unit tests to make sure everything works fine? Apple looks incompentent as a result of this. Or worse if they knowingly released a borked framework and let us all suffer.

Where is that new emoji....

Agreed. I went to the trouble of submitting sample programs, and the engineer assigned to my case just keeps asking me for crash logs for out of memory crashes on my iPad.. It's like the problem is right in front of their eyes and they're staring at their feet. It's out of memory because they've f*cked up Sprite Kit and have done something to tripple/quadruple/??? the CPU/GPU load when handling sprites. I don't know how else to explain in plain terms that their engineers only need to add a few effing spaceships to their own stupid template project and the frame rate plummets. Who is in charge there?! Is there even anyone there? Are they not reading these forums?? Or looking at the bugs we've submitted? Am at a loss what to do now...

Well, I can assure you they read the forum because they've deleted some of my posts.😉

Aside from talking people out of using SpriteKit for new projects I don't know what to do either...

No idea too. Except writing a desperate letter to Tim Cook.😐

Yeah, I can vouch for this. I've had an entire thread deleted, amongst other individual posts.

Hi all,

Thank you for your patience. Many of these issues have been fixed in iOS 9.2 Beta 1 and Xcode 7.2 Beta 1, which are now available via the Developer Center. Please let us know if any of these issues persist, by filing a bug report or updating the original with a description.

Thank you.

Hi gabhel,

Thank you for your patience. This issue has been fixed in Xcode 7.2 Beta 1, but I would also recommend updating to iOS 9.2 Beta 1, which are now available via the Developer Center. If any issues persist, please update the original bug (22416124) with a description.

Thank you.

Hi four5six.pixel,

iOS 9.2 Beta 1 and Xcode 7.2 Beta 1 are now available via the Developer Center. Can you please verify these issues?

Additionally, it'd be great to get more information on the texture squishing/stretching you're seeing. Is this issue still present in iOS 9.2 Beta 1?

Thanks.

Hi ashort,

Thank you for filing the bug. Asset catalogs offer many benefits such as app thinning, but if you concerned about performance most, we currently recommend using a texture atlas outside of an asset catalog.

Thanks.

Well, initial tests suggest that many of my issues at least, appear to have been resolved. Mainly the use of SKCropNode no longer tanks the frame rate, and the node/draw count has returned to a normal level, with an acceptable frame rate.

Thank you for fixing the problems with Sprite Kit. I, and I'm sure many other developers, appreciate this.

For me, since the release of iOS9, pretty much all of my time has involved re-engineering large chunks of code, in order to get my game to run on older devices, and to achieve an acceptable frame rate on newer ones. If I now run my original code with 9.2, the frame rate has returned to ~60, and it seems, we are back to iOS8 performace levels. Weeks of work that could have been focussed elsewhere.

Now I don't consider this work entirely wasted, as some of it is optimisations that I will keep. However, not knowing whether or not Apple was investigating, fixing, or even aware of these issues has meant an arduous and stressful process, trying to accomodate for a bad update. I have been communicating with an Apple tech support engineer, however he has apparenlty been as in the dark over the Sprite Kit team's progress as I am.

At the very least, it would have been helpful if Apple could have written on these forums, to offer some level of reassurance that this issue was known and being looked in to. Instead there is generally outcry from devs (myself included), with the odd request from Apple to submit a bug. I, and many others, have submitted bugs, example programs and detailed reports, with little to no feedback on their progress. I began to adopt the general feeling that Apple doesn't care.

I am grateful that this issue seems to finally have been resolved, however I would just like to say that a little more communication from Apple would have gone a long way. And possibly saved many stressful, late night coding sessions. I have felt extremely let down by Apple over the last couple of months, and being an independent developer, this has affected me personally and professionally.

So just to be clear, thank you for fixing Sprite Kit, but next time, a little more transparency please. It would go a long way to supporting devs, some of whose entire livelihoods rest on your whims. And in my case, my mental state too 😐

Dear Apple,

By silently fixing some of the issues addressed above, and not listing how, what, where, or why of those fixes (nor the extent of awareness and fixed) you've confirmed everyone's worst fear... that Apple will never communicate, even when they have good news.

So the blackhole is endless.

We know from the pattern we can expect it to widen by an uncertain amount at each full new iOS release, constrict slightly and vacuum less during point upgrades, but never go away.

A perpetual blackhole sucking in all the unwary via overt, confident proclaimations of impending world dominance at each WWDC. Each new Kit is great, a new and all conquering ease of use combined with wondrous productivity and amazing performance.

How many developers will believe you next year?

Well said. The lack of official communication from Apple shows their contempt for small developers. We all make mistakes, this much I can forgive. But failing to acknowledge and own one's mistakes, especially when they affect so many other people, is unforgivable and the main reason I will no longer rely on Apple frameworks for future projects.

It has also earned Apple negative word-of-mouth PR for SpriteKit since I am making sure friends and co-workers are aware of the problems I've had. This is not a framework, or working process I would recommend to anyone.

This is exactly my story too. The whole day before yesterday was devoted to coding. And with 9.2 beta it turned out everything was quite okay with the old code.

Not cool.

tcasella:

I just updated to 9.2 b1 & 7.2 beta (7C46l). I'm now seeing the texture "squishing" on my project where I wasn't before. It's only affecting a few sprites: my Player Character sprite (consistently), and some sprites like doors that have texture-related animations. Not sure if it's related or not, but I am also getting this error message coincident with the texture squishing:

CUICatalog: Invalid Request: requesting subtype without specifying idiom

Sigh.... things were just starting to look good for me 😟.

Just to note, I'm not doing anything funny with scaling, centerRect, etc, and the SKScene.scaleMode is .ResizeFill

I can also tell exactly what is happening WRT the "squish" effect: The texture in question is a square image, with alpha transparency around the texture. The sprite is sized to match the texture size (in the player char case, 128x128). It appears that the non-alpha area of the texture is being stretched to fit within that 128x128 size.