Mac World Machine?

I can roughly sketch out the changes for the next version of World Machine, code named “Dragontail Peak” into three categories of focus. Let’s call the first category by the really boring name of “framework changes”… What does that mean?

Available for Mac and Linux.

That’s right! For the first time in its history, WM will be supported running on a platform other than Windows. Dragontail Peak will run natively on Apple Silicon Macs as well as x64 on Linux.

This is probably the longest unfulfilled feature requst at ~20+ years old 😛 I’ve personally owned a macbook for a decade now but not been able to run my own software on it.

It’s time. I feel like the tide has really shifted against the windows app hegemony. A lot of that has to do with the way the web has essentially become most people’s operating system. And while the web is not yet a good platform for high performance graphics, more people than ever are using linux and mac.

Neither of these is going to be ready instantly for the the first public dev build. I have to figure out a workable build and packaging strategy for releasing 3 platforms at once.. but the actual code-side work is done.

Porting to the QT framework 5 years ago for the LTE-version of World Machine took care of a lot of the porting work, but I don’t have to tell you there was a ton remaining still that went into this. Some of the issues in no particular order:

• WM has always used MSVC as a compiler. Making everything correctly compile on GCC and Clang as well took quite a lot of changes, as they all interpret the C++ standard differently and accept different subsets with nonstandard extensions.
• Lots of legacy direct use of Win32 APIs for things like threading
• Hidden reliance on x86/Windows behavior. Moving to ARM requires you to be more precise about synchronization needs, and some of the threading code had baked in assumptions that leveraged x86’s more permissive memory model. It also manifested in obscure stuff like the fact that on windows, a ‘long’ C datatype is a synonym for an ‘int’. On Mac/Linux they are sized at 64 and 32bit respectively, which will immediately break anything that used them interchangibly.
• Running on the mac requires an OpenGL Core profile. The LTE port took care of removing the old immediate-style code, but a Core profile meant a lot of things got stricter or deprecated. The good side of this change is that the core profile generally puts you in the less-buggy path for most drivers, on ALL platforms. The bad news about the Mac is that OpenGL works well but is frozen at an older version and is officially deprecated. OpenCL is really really deprecated. More to come on that later..

Linux

Confession: I’m a linux noob. I’ve used the terminal plenty over the years — hard to be a developer without that — but linux has never been my daily driver and I’ve never used a linux desktop other than a couple random experiments.

I converted my mostly obsolete old AMD 1950x workstation (not even supported by Windows anymore) to run Ubuntu. I have to say I’m actually pretty impressed by the experience of desktop linux. It’s come a very long way since the old days. As I told the alpha testers, the hardest part was figuring out which distro to use, and I stuck with Ubuntu as a good ‘It just works’ default.

It’s alive within desktop linux! Everything works pretty much as expected.

The biggest thing I still need to figure out is packaging. How do people even ship commercial apps on linux? I hear that Flatpak is the way to go, but I have as of yet not investigated how to get things packaged for that, much less set up the build automatiation.

But the hard part is done, and the alpha builds live interchangably across platform now, and that’s pretty awesome.