Apple revealed their new Game Porting Toolkit today at WWDC. This Toolkit is designed to allow Windows game developers a way to easily and quickly determine how well their game could run on macOS, with the ultimate goal of facilitating the creation of Mac game ports.
We are ecstatic that Apple chose to use CrossOver’s source code as their emulation solution for the Game Porting Toolkit. We have decades of experience creating ports with Wine, and we are very pleased that Apple is recognizing that Wine is a fantastic solution for running Windows games on macOS. We did not work with Apple on this tool, but we would be delighted to work with any game developers who try out the Game Porting Toolkit and see the massive potential that Wine offers.
So, Apple basically repackaged Wine. Interesting they’re going the same route as Valve, just less open about it, and since it’s not core to the company’s business, it probably won’t be nearly as good and aggressive at getting new games to work as Valve’s Proton does, both through Valve itself and countless modified versions of Proton from 3rd parties.
To be entirely honest, they also provide a 3+MB patch: https://github.com/apple/homebrew-apple/blob/main/Formula/game-porting-toolkit.rb
Which is significant in terms of software development.
But, it would be nice if this was actually merged into Wine proper itself.
Another effort from Khronos group to bring Vulkan on Metal:
https://github.com/KhronosGroup/MoltenVK
(Apple is bringing DirectX 12)
I find it fascinating that Apple is ‘NOW’ giving some credence and utilization of wine technology ‘AFTER’ it has moved away from x86 processors. After all, ‘Wine is Not an Emulator” and it was not envisioned as such. But that is its destiny!
I must admit, Wine has worked quite seamlessly through the hackintosh era. But even more amazing is how Crossover and the greater open source community has made it work excellent on the M1. I know it wouldn’t run everything I could think to try flawlessly, But I do rate it as “excellent” because for the 1% of the time I have to run a WindowsOnly App, I just seamlessly run it. No emulator boot-up or dusty windows partition. Oh and anyone remember Darwine? The dream has come to fruition in a new way.
I like to see the enhancements and uptake of Wine because it is an amazing project, and more Wine usage will only make it better. But unlike Blender, which has been going through a similar uptake, if Wine became absolutely flawless and perfect in every way tomorrow, Microsoft will still be in charge of the underlying Windows ecosystem, and they will use this position to sabotage Wine from underneath if it starts to challenge them. E.g. UWP would have done this if it hadn’t crashed and burned in the market. Wine is like running a race where your opponent, Microsoft, has control of the track in real-time. No matter how good you are, your opponent can still make you lose.
I think modern applications should be designed to be OS neutral, and Wine should only be used for older programs that won’t be ported because the people in charge of them don’t care anymore. We want to break the Microsoft stranglehold on computers, not strengthen it.
kbd,
Yea, it was microsoft’s intention for UWP to kill of the “legacy” win32 ecosystem in favor of a walled garden they controlled. I think we’re fortunate that the new walled garden failed, but unfortunate that world is so reliant on legacy win32 applications to keep microsoft in check.
O/T: anyone else affected by the hellscape outside right now?
https://abcnews.go.com/US/wildfire-smoke-map-us-cities-states-impacted-canadian/story?id=99865946
It’s midday and yet so dark.
This seems similar to what they did with khtml to make webkit back in the day, which is similar to what Valve has done. They likely will develop it internally, pulling in patches from upstream in Wine, and feeding back almost useless large code dumps back out to the public. It’d be nice if they’d maintain some kind of useful open source effort (they did for a while with webkit), but I’d be surprised if they did. It’s not really the way Apple does things. Happy to use open source, less happy to participate as a citizen.
This isn’t really missing part of the games story on macOS though. The missing part is Vulcan (well, and 32 and 64-bit x86 support, to some degree). Was there something in here about a first party effort to get DXVK working on Metal, or are they counting on community efforts to make that happen?
To be clear, 32-bit windows apps can already run on macos in wine (despite no easy way to run 32-bit macos apps/games – which is stupid).
Also, I just realized that Apple solved the DXVK problem more directly by implementing their own D3D to Metal translation. I wonder how complete that is, and whether proton will be ported to use that. That’d be a real boon to Steam on macOS.
Apple’s Porting Kit is not Wine. The Wine bit – which works well on current devices incidentally, you don’t need to wait – allows a developer to evaluate the performance of their app on a Mac.
The porting itself requires the developer to migrate the gaming code to Metal.
Hopefully everyone also understands that this whole ‘porting kit’ exercise is not about the Mac. The value of games on the Mac is limited. This is about the Vision OS.
ikristoph,
Is the blog/article wrong?
After reading this, it’s hard for me to conclusion that the Game Porting Toolkit is not based on CrossOver and wine.
That’s true for native ports, but not when using crossover (which Game Porting Toolkit is reportedly based on) because crossover supports directx on macos.
I don’t know who’s right, but because you seem to be contradicting codeweavers announcement, do you have links to more information about this? I’d like to have evidence one way or the other. If you are right that apple’s toolkit requires code to be ported to metal, then what’s the point? That’s where most of the porting work lies and I cannot see how game developers who by and large weren’t porting their games to macos before are going to do it now. The whole point of crossover/wine/proton are to run the applications without relying on ports to native APIs.
It _is_ wine. Though primarily DXVK and MoltenVK
I also liked this news. Instead of reinventing the wheel it is just better to support an open source project. Apple can support Wine with code, more developers and even with money (not sure if that is going to happen). But in general terms I think it is good for the Wine project. Or, what do you think it can wrong??
Emulation is good for THEIR uses, but They Despise it for what the users want with it.