Blog

I’m trying to get back into blogging and as part of that I’m going to start posting my personal projects for the month. It’s something to keep me posting regularly and also a nice way to hold myself accountable for progress.

I’m working on a few things right now:

• I made improvements in OpenAL-Soft for detecting surround speaker configurations on macOS. Next I’m going to work on adding Spatial Audio support on Apple platforms. I’ll be integrating CoreAudio’s Spatial Audio mixer into OpenAL.
  • This one is kind of odd because OpenAL can do its own 3D to stereo down mixing. But getting raw positioning data to feed into OpenAL seems to be guarded by a privacy permission.
• I’ll look at building Nvidia PhysX 4.1 for visionOS. This continues the effort to get Plasma running on visionOS.
  • Plasma doesn’t use the Omniverse vision of PhysX which drops 32 bit support. Uru Live is still distributed for 32 bit Windows. So this work will be on the Gameworks version of PhysX.
• The Mac port of Plasma has issues around display and resolution detection and will require some refactoring. This is the last major functional issue with Plasma on Mac.
• The Metal version of Plasma does not properly handle bump maps. Cyan used a primitive bump mapping algorithm that worked with fixed function Direct3D.. I’ve written both a modern bump mapper and a bump mapping shader that emulates their bump mapping. I’ll keep on moving this forward in the Mac engine. This is the last rendering feature missing from the Metal pipeline.
  • It’s always tricky to work on old games because you risk changing the artist’s original intention. While the modern bump mapping looks amazing – it does look different. The old algorithm didn’t support independent light contributions – and it ignored an entire channel of the bump map. But it’s also the material appearance an artist fine tuned.

As the Mac version of Uru Live becomes complete I’d like to see it roll out to users. But I don’t have any updates that I can share yet. While there are open source servers, Cyan controls the official servers for Uru. There have been some conversations around merging some changes that could include the Mac client into the official Cyan repository and patch server.

I’ve been really impressed by the games sessions so far at WWDC 2023. One of my complaints about Metal has been with the really small amount of community documentation – it can be difficult to find resources specifically on porting from DirectX. It looks like a problem Apple is really beginning to tackle.

Automated conversion from HLSL based shaders is also a really good improvement. I’d love to see them support SPIRV shader conversion as well for personal reasons, but DirectX/DXIL is clearly the best starting point.

Of course the big news is DirectX 12 to Metal translation – through a new Game Porting Toolkit and D3DMetal.

(more…)

On the first internal test of Uru for Mac, I got some weird feedback from testers. As the player character was walking, the game wasn’t responding smoothly to the mouse. As the player moved the mouse to turn the player, the player would turn in fits and starts.

(more…)

Mark Gurman posted an update saying the M2 Extreme chip had likely been cancelled. I’m going to assume what Gurman is reporting is accurate, because it generally is.

Workstation chips are expensive to design and produce. CPUs like the Xeon are sustainable because Intel splits the development cost over a wide range of customers. It didn’t seem sustainable for Apple to design a workstation chip just for the Mac market. According to Gurman, this is likely a factor in the cancellation of M2 Extreme.

If Apple is refocusing the Mac Pro on customization and modularity. I think that’s a very good thing. But Apple should go a step further – and bring support for third party GPUs back to Apple Silicon.

(more…)

I’m still learning SwiftUI.

Learning something new is hard. I taught myself programming by typing random commands into HyperCard on a Mac SE. After that, I did REALbasic. When I was 14, I started learning Cocoa using whatever Apple tutorials and sites I could find online. It was a struggle. No one had taught me about classes, polymorphism, or memory management. I wrote a lot of bad code long before I wrote a lot of good code. But I stuck with it because Cocoa seemed like something special. And it was.

Digging into SwiftUI this week gives me same feelings of being lost in something new, and looking at the future.

New things can make everyone uncomfortable sometimes. I’ve worked in AppKit for 18 years and UIKit for 10 years. I know right now there are probably a lot of programmers that haven’t even graduated high school yet that can write far better SwiftUI than I can. It’s hard to go from being an expert one day to being a novice the next. I think a lot of developers might feel that way right now too.

---

Earlier this week, The Verge posted an article arguing that Apple should make nearly all of their Mac apps Marzipan apps. The idea was that it might hurt the Mac in the short term, but in the long term would make the Mac a better platform.

I use a Mac to get my work done every day. I spend more time with a Mac than I do nearly anything else in my life. It’s not that I don’t like the iPad. I love my iPad Pro. But I don’t want to see the tool I use every day get worse. I don’t want to have to see the Mac lose for the iPad to do well.

SwiftUI is amazing because it doesn’t feel like there are any losers. It makes the Mac better. It makes the iPad better. It makes the iPhone better. Heck, it even makes the Apple Watch and Apple TV better. I’m thinking about ways to ship apps for the TV and Watch, and I never would have considered that before. I even have Mac apps I might bring to iPad. I didn’t want to give up the power of AppKit on the Mac, and I didn’t want to maintain two separate code bases. Now I don’t have to choose.

AppKit and UIKit are going to be around for a while. Carbon was finally removed in Catalina, 13 years after its deprecation. And AppKit and UIKit are probably a long way from even reaching deprecation. It’s very likely both these APIs will be around in some form for at least a decade, probably longer.

SwiftUI is also very young. It’s amazing which you can try for free, for a 1.0 API, but it’s still 1.0. Features that are missing will be added. I expect other Apple frameworks to also become become more reliant on and cleanly integrated with Combine and SwiftUI as time goes on.

But none of that diminishes how powerful SwiftUI already is today, and how effortlessly it can integrate into the code I ship. All with the platform features I need to support.

This is going to be new for everyone. I’m probably going to write some bad code, and I’m probably going to say some stupid things on Twitter. I’m not always going to be a smart guy on the internet (assuming I was before.) But that’s ok. Because it’s all part of getting somewhere better.

John Gruber today posted some reliably sourced rumors about Apple’s cross platform efforts. Most notably, he’s placing any changes in 2019, and not at WWDC 2018, and casting doubt that what Apple is doing is UIKit on the Mac. (And if you follow me on Twitter, you’re likely aware that I feel that UIKit on Mac would be a bad move.)

• “XKit” not assured. I read iMore’s article first and got quite excited about the prospect of an “XKit” framework, a unified framework that would replace UIKit (but I think was reading the original, pre-Gruber update article.) It’s worth noting that Gruber’s rumor says nothing about a new UI framework, only a new UI API and declarative toolkit, which is very open ended. API could mean anything between a new class (a la NSNib), or a full set of new frameworks. Later in his post, Gruber speculates that this new API and declarative tool could abstract UIKit and AppKit, or be part of a new UI framework, which is fairly non committal. The Gruber post also does not imply there are dramatic UI changes being made to macOS or iOS to support this new API, but I could see a declarative toolkit opening previously untapped creative avenues. Certainly Apple will want to dogfood such an API on a few applications, which could mean a few new crossover applications, possibly in both directions.
• Declarative control API. Apple wouldn’t be the first to have one, and declarative UIs are typically written in a markup language, meaning it wouldn’t necessarily be in Swift (or Obj-C). Android has Layout XML, and Microsoft has XAML. I think Apple’s Xib format is also very similar, but I don’t know of any developers writing Xib by hand, and I think the format is too cumbersome to write by hand. Xib also does nothing to abstract the platform differences.
• Auto Layout. A declarative control API also sounds a little bit like Auto Layout, although Auto Layout is missing is a way to declare controls themselves and not just the relationships between controls. It’s possible whatever Apple is working on is being built on Auto Layout. (Did you know that Auto Layout already has a declarative UI language? It’s uhhhhh…. interesting.)

Other things to watch for:

• Tooling. A declarative control API, especially using a markup language like XML, opens up a lot of tooling possibilities. Apple could extend Interface Builder to create these declarative APIs, but I would love them to return to more powerful standalone UI tools. When Microsoft unveiled XAML, they also unveiled a tool called Sparkle, which eventually became Microsoft Expression. The demo video is 13 years old now and is a little dated in a few ways, but I think is still worth a look. Even if Apple doesn’t come in with a high end tool, it would make it easier for a third party developer to come in and fill the void.
• Dynamic Swift. There is room for this new technology to be all Swift based, but generally I’d still guess like other platforms this is still a better fit for a markup language. The Swift team has been hinting at more dynamic features, and I wouldn’t count on this getting us closer towards being able to deal with our declarative UIs using static style programatic development. I think this will still look like loading the declarative API from an archive format at runtime. It’s speculation. But Swift feels like way too heavy of an option for writing declarative API.

All in all we don’t know much about Marzipan, or whatever it is called now. But my hunch is it’s a tool to help us deal with UIKit and AppKit, and not a tool to replace it. Although changes to keep us from having to deal with NSView vs UIView would still be welcome.