Category: Uncategorized

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.

I’ve been thinking about what a unified Apple API could look like. One of the biggest issues is that iOS devices and Mac devices are very different, and even some iOS devices like the AppleTV aren’t even similar to devices like the iPhone or iPad.

One option Apple has is creating a new, massive API that exists on both iOS and Mac. This is a tremendous undertaking. It’s taken Microsoft many years of public iteration on their Universal Windows API, and adoption has not been quick. And Windows Universal apps are frequently targeted for not feeling like native desktop applications, which is something Microsoft has trying to improve on in the years since Windows 8.

A brand new API would also have to deal with the platform differences. Is there a good way to force an iOS application developer to think about menus on the Mac as they build their iOS app? Would a Mac app built on this framework simply have it’s menus go missing when it runs on iOS? It doesn’t seem like there is a good option here that doesn’t require losing a lot of what Mac users love, or complicating iOS.

I was thinking through the timing of this transition, and remembered that Apple will be ending support of 32 bit applications at the same time. One of the biggest problems with the 32 bit runtime on Mac is the fragile base class problem. I won’t get deep into the specifics, you can read more here. But, the fragile base class problem would prevent Apple from making serious changes to the core classes that made up AppKit, or prevent them from changing the class hierarchy.

But now that Apple could change the class hierarchy, what if we’re wrong about how we think about a shared framework? What if it’s not a layer on top of AppKit and UIKit, but a layer underneath?

Classes like NSImage and UIImage could be refactored to have a common ancestor, maybe just named Image. When you create an Image you get the platform specific version under the hood, but you can ignore that and work with Image’s shared cross platform functions. When you need something only currently available on the Mac, like image representations, you just downcast your image to an NSImage, and you have all your AppKit functionality back.

This would solve the hand wringing of losing advanced Mac features because you don’t actually lose anything. And as Mac features are pulled into the common layer as needed, iOS gains the advanced features as well.

It doesn’t let you write code once and have it run perfectly on both platforms. But I’m not sure that’s the point. I think Apple will want to avoid the mistake Microsoft did, and make developers still think about and specialize their apps on both platforms as necessary, much like they do with the iPad and iPhone. But not having to worry about things like NSImage or UIImage or NSView vs UIView could seriously turbocharge moving code between platforms.

This sort of setup would also prevent the sort of fallout we saw from the ongoing pure Swift vs Obj-C debate. AppKit and UIKit would continue to exist, just with a shared heritage. There wouldn’t be a need to fight about which API is best, all APIs would win.

I’m really happy to see Apple’s announcement on the Mac Pro today. Last November I wrote:

“Even if you think the Mac Pro is going to be updated, Apple’s lack of a mention of it (or the iMac) implies that Apple is still misjudging the expectations of the pro community. When you’re a Pro, you don’t like uncertainty around the tools you need to earn a living. Would you risk your business on a vendor that doesn’t have a clear plan on continuing to support your workflow?”

“Even a “we’re working on” for the Mac Pro would have gone a long way towards re-assuring a community that depends on Apple’s roadmap for a living.”

Apple announcing they are working on a new Mac Pro is the right move. It’s something they should have done in 2016 or 2015, but it’s better late than never.

With the announcement that they’re working on a 2018 completely redesigned Mac Pro, here are some things I’d love to see:

Returning to a traditional design

The 2013 Mac Pro looked great, but the design was just problematic. A tower goes on the floor where I don’t need to look at it. With a monitor and speakers already on my desk, I’d be hard pressed to find room for a Mac Pro. The Mac Pro should be built to go on the floor, which probably implies a tower design. The round can design was attractive, but it wasn’t practical.

Off the shelf PCIe graphics

The GPU is the quickest aging component of my Mac. On my Mac Pro the GPU is typically outdated after two years (my 2008 Mac Pro has gone through four GPU configs.) I shouldn’t need to change out my pro level hardware every two years.

Apple and the rest of the PC industry have also all adopted the UEFI standard, which should open up a Mac Pro to a world of PC graphics cards without flashing (assuming the drivers are available on the Mac.) Support for off the shelf standard GPUs would help me get a lot more out of the machine. Yes, standard PC cards would have a bunch of unsightly video ports in addition to the onboard Thunderbolt ports. But I could use those video outputs with compatible monitors if I needed to preserve my Thunderbolt ports for data devices.

Plenty of pros also use other kinds of PCIe cards, and have to shell out the extra expense to buy Thunderbolt enclosures to house these cards in.

Multiple GPUs

Apple talked about single GPU workflows. I’d also like to see two GPUs still be an option. Four PCIe slots, like the classic Mac Pro, would be especially great, as we have obscure workflows at work that really need four GPUs.

Could this cause problems with the Thunderbolt ports not knowing which video card to use? Sure. But that’s easily solvable with a setting in Displays that lets you pin a display to a GPU.

Use Existing Standards

The 2013 Mac Pro has an user upgradable SSD (read the manual) that is also proprietary, and Apple won’t sell you their SSDs. OWC has come out with their own replacement SSDs, but they don’t usually ship with the same performance. If the storage is going to be upgradable, make sure I actually have options to upgrade it with. Use the M.2 standard. Offer a few M.2 slots. Sell Apple SSDs with Apple performance even if I have to go to the Genius Bar to order.

Don’t bother with SATA or optical drives. That’s the past.

Optimize macOS

There is a software side to this too, mostly around Metal. We’re clearly not getting other API’s like Vulkan at this point, so Metal needs to be solid. It needs to be fast, and needs to be reliable, which it isn’t necessarily right now. And with so many employees now working from home many businesses are worried about managing those employees but with a simple internet activity tracker all of those worries disappear so have a good look into that if you have remote staff.

It’s also strange Apple is complaining about software not adapting for multiple GPUs when they make it so difficult. DirectX 12 makes it easy for apps to use multiple GPUs at once, even if those GPUs are from different vendors. Multiple GPUs aren’t a bad idea, Apple has just done such a bad job making that happen.

Bonus Points

Dual CPUs could be nice. But with the Xeon now up to 16 cores it’s less necessary. But dual CPUs does also double the maximum amount of RAM possible.

A rack mount server configuration? Ok ok, probably too much to ask for the return of the Xserve. But Apple is missing a really good rack mountable build server option right now. Maybe just a quad core Mac Mini would work.

I’m still waiting to see what Apple does with desktop Macs this year, but I knew I also wanted a 5k display, so I ordered the new Ultrafine 5k without a Mac to go with it. I wanted to get the display under the promotional pricing, but ordered it before I noticed Apple extended the promotional pricing until March.

The reason I kept the order instead of cancelling it is this support document, which states that the 5k Ultrafine Display will work on older, Thunderbolt 2 machines with an adapter, but at a resolution of 4k. I have a 2013 Retina MacBook Pro, but Apple states that a 2014 MacBook Pro or higher is required for the display to work at all. My hunch was that Apple was being conservative. The 2013 MacBook Pro I use is identical to a 2014, which was just a minor CPU speed bump. So for this review, I’ll be doing something a little unusual, and using the display with something outside the support range. (more…)