I loved this idea of using the black sprite node however it still presented issues for me when transitioning between two "scenes" that contain SKTileMapNodes.
So what I do is have a wrapper node that is a subclass of SKSpriteNode. When I want a tiled background, I create an instance of this class that internally creates an SKTileMapNode that is never actually presented. Once that SKTileMapNode is created, I then create a texture from it and initialise my wrapper object using that texture.
From then on, it is a simple SKSpriteNode that obeys the alpha like all good SpriteKit nodes should, and I don't have to do any fiddles with black nodes.
p.s. I can't believe (though I should by now) that Apple have not been able to bring themselves to fix this after 6 years.
Post not yet marked as solved
This problem still exists today in the latest version of macOS Catalina. I've spent the past week trying to find a reason why my iOS app that I'm porting to macOS has all these issues when I run it full-screen on my brand new Macbooks Air 2020 (core i7, 16GB).The app runs fine until I set it to full-screen. I note that my app is a SceneKit app, with a SpriteKit overlaySKScene. The SceneKit assets all seem to perform fine, but the SpriteKit assets spasmodically draw with the wrong textures, and this only happens when the app is utilising full-screen.I've employed some of the tecniques in the link provided above (I'd found it independantly), notably:self.view.window!.styleMask = NSBorderlessWindowMask
self.view.window!.level = Int(CGWindowLevelForKey(Int32(kCGMainMenuWindowLevelKey))) + 1
self.view.window!.opaque = true
self.view.window!.hidesOnDeactivate = true
let size = NSScreen.mainScreen()!.frame.size
NSMenu.setMenuBarVisible(false)
self.view.window!.setFrame(CGRect(x: 0, y: 0, width: size.width, height: size.height+1), display:true)This certainly makes a big difference, the glitching of textures stops 99.9% of the time, however I'm left with about 20 unused pixels at the bottom of the screen.Given this question was asked in 2016, and the linked SO post suggests the issue was corrected in 2016, I'm wondering why I'm still seeing it in 2020. I note that the same problem occurs on my older Macbook Pro (2013, core i5, 2.3GHz) running Mojave.I don't accept that it's just that the hardware isn't up to it. If the app can run smoothly in the iOS simulator, which adds an extra layer of OS level code to the app, then it should be able to run natively on the machine, no matter the window size.I note that in the solution above, if I comment out the line:NSMenu.setMenuBarVisible(false)then the problem resurfaces. There is some odd optimisation being done by macOS around (near) full screen apps and the way they use the menu bar screen real-estate that cripples SpriteKit apps (and possibly others).Games on Apple Arcade seem to run OK, so there must be a way for this all to work. It would be nice not to hack up a workaround though.Here are some screenshots showing the issue.First, with the above solution and the menu bar set to not-visible, all runs beautifully, but I can't get the window to position itself so that it actually covers the entire screen. You can still see Xcode running behind it:Next, the image below shows what I get by commenting out the line so that even though the menu bar isn't in fact visible, it's causing a serious drop in the frame rate, and then as the final image shows, when ever I actually do something in the app that triggers some SpriteKit animations, the SKSpriteNodes within the SpriteKit overlay are drawn for a few frames using the wrong textures:
Post not yet marked as solved
Correct. I just ran it up, and indeed it is there. At last!You can download it from the member center. Just remember to keep is separate as you won't be able to submit builds from this beta version.Test on 11.1 SeedBuild and submit from 11 GM.
Post not yet marked as solved
Agreed. Still not present. I'm beginning to think we are being forced to wait for iPadOS to drop. Infuriating. They want us to submit updates, but we actually can't because we have no way to test.
Post not yet marked as solved
Unfortunately, this doesn't work with the GM Seed if you want to test the 7th generation iPad (the 10.2" model). It's just not there in the list.
Post not yet marked as solved
Me also. Makes it rather hard to test.
