Author: Colin Cornaby

I’ve published a fork of the Gameworks PhysX to my Github that includes support for Vision Pro.

https://github.com/colincornaby/PhysX-Gameworks-Apple

I’ve also collected several other patches into the fork – including the patches we use for H’uru to build PhysX for other Apple platforms. This includes:

• Patches to fix compilation issues in modern versions of Xcode
• Support for Apple Silicon Macs

These changes were submitted to Gameworks repository several years ago but were never accepted.

This fork is specific to the Gameworks version of PhysX. The Omniverse version of PhysX does not support any Apple platform. There is a community fork that adds some Apple build targets – but Vision Pro does not seem to be supported at this time.

Thank you to the other authors whose work went into this fork. I’ve preserved the original author metadata in the commits.

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.