But to answer your question as if they had not yet: it's never "just" recompiling. It's:
* recompile (and fix any warnings/errors indicated by the compiler)
* re-test ... the entire game
* fix the bugs that are encountered in test
* release/publish the game for Windows ARM64
Whatever this effort is, it's much much more than "just" recompiling. You could imagine motivated individuals on the engineering team chipping away at this list of their own accord. But following through with a product requires significant effort and coordination that often is weighed against the potential revenue that this new market could provide.
A really fun thing is that arm and x86 have different char signedness: char is signed on x86, unsigned on arm. This has tripped me up more than a few times when I try to compile software that's only been tested on x86 for an arm machine.
Now WoW already supports Apple Silicon on macOS so most of that was already taken care of, but I'm betting there's a lot of Windows-specific code in there too.
That seems a bit absurd. Surely many parts of the game won't likely have bits of code that interact with architecture in unique ways. Especially if you wrote the game in relatively portable code to begin with (as WoW almost certainly was).
I mean idk, maybe windows arm64 is a uniquely nasty target. But i'm skeptical.
> Surely many parts of the game won't likely have bits of code that interact with architecture in unique ways.
I came across a performance-killing bug that made the game unplayable (less than 1fps on a Mac Studio). It happened in a couple of dungeons (I spotted 2). From my tests it was caused by a specific texture in the field of view at a certain distance. There was no problem on Intel Macs, AFAICT. My old MBP was terrible but did not get any performance hit.
This is what can happen any time you don’t test even a tiny corner of the game. Also, bear in mind that this depends on graphics settings and you get a nightmare of a test matrix.
It seems that "native vs. emulated" here means "arm64 binaries vs. x86 binaries, both running on Windows". So the comparison that the OP is making wouldn't be possible if Blizzard didn't already support aarch64.
As others have said in this thread, they did.
But to answer your question as if they had not yet: it's never "just" recompiling. It's:
* recompile (and fix any warnings/errors indicated by the compiler)
* re-test ... the entire game
* fix the bugs that are encountered in test
* release/publish the game for Windows ARM64
Whatever this effort is, it's much much more than "just" recompiling. You could imagine motivated individuals on the engineering team chipping away at this list of their own accord. But following through with a product requires significant effort and coordination that often is weighed against the potential revenue that this new market could provide.
A really fun thing is that arm and x86 have different char signedness: char is signed on x86, unsigned on arm. This has tripped me up more than a few times when I try to compile software that's only been tested on x86 for an arm machine.
Now WoW already supports Apple Silicon on macOS so most of that was already taken care of, but I'm betting there's a lot of Windows-specific code in there too.
They've supported macOS through all of PowerPC, Intel, and now ARM. I'm sure Windows on ARM should be trivial for them.
They did the work your parent comment describes for macOS on PowerPC, macOS on Intel, and macOS on arm. They can do the work, but it's still work.
1 reply →
> * re-test ... the entire game
That seems a bit absurd. Surely many parts of the game won't likely have bits of code that interact with architecture in unique ways. Especially if you wrote the game in relatively portable code to begin with (as WoW almost certainly was).
I mean idk, maybe windows arm64 is a uniquely nasty target. But i'm skeptical.
> Surely many parts of the game won't likely have bits of code that interact with architecture in unique ways.
I came across a performance-killing bug that made the game unplayable (less than 1fps on a Mac Studio). It happened in a couple of dungeons (I spotted 2). From my tests it was caused by a specific texture in the field of view at a certain distance. There was no problem on Intel Macs, AFAICT. My old MBP was terrible but did not get any performance hit.
This is what can happen any time you don’t test even a tiny corner of the game. Also, bear in mind that this depends on graphics settings and you get a nightmare of a test matrix.
2 replies →
I mean you can release it with loads of parts untested and just _hope_ there aren’t bugs there, it’s definitely an option. It’s risk vs reward there.
4 replies →
They did, and that's what this article is benchmarking.
Specifically, it's comparing the native ARM64 version against the emulated x86_64 version, both running on an ARM64 CPU.
It seems that "native vs. emulated" here means "arm64 binaries vs. x86 binaries, both running on Windows". So the comparison that the OP is making wouldn't be possible if Blizzard didn't already support aarch64.
They support arm64