6 ms·

Native vs. emulation: World of Warcraft game performance on Snapdragon X Elite

104 points by geekman7473 10mo ago

MuffinFlavored 10mo ago
How hard would it be for Blizzard to just recompile WoW to support arm64?
- vbezhenar 10mo ago
  They support arm64
- teraflop 10mo ago
  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.
- pxc 10mo ago
  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.
- wyldfire 10mo ago
  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.
  - MangoToupe 10mo ago
    > * 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.
    - jama211 10mo ago
      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.
      - mobilio 10mo ago
        few days ago there was thread here about Valve and 20 years FPU bug... https://news.ycombinator.com/item?id=46009962 https://news.ycombinator.com/item?id=46009962 WoW was released 21 years ago AFAIK
        dgellow 10mo ago
        now I feel old...
        Wowfunhappy 10mo ago
        …the thing is, this is the type of bug I could also imagine happening under emulation. Or just following an OS update.
        jama211 10mo ago
        That was a fantastic read, thank you for this
    - kergonath 10mo ago
      > 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.
cosmic_cheese 10mo ago
Interesting, I didn't know they'd added an Windows/ARM build. Makes some sense though, WoW has always been one of the best about broad platform/arch support… macOS/PPC and Windows/x86 versions were both available from day one and have stayed in lockstep the whole time, and it was among the first games to make both the PPC → x86 jump and x86 → ARM jump on Macs. Have heard that they had Linux builds internally early on too.
- eptcyka 10mo ago
  Wine has almost always worked, back when I played.
  - cykros 10mo ago
    I recall seeing that it ran better on wine than on windows on the same hardware. Never tested myself as I'm more a runescape/ragnarok online sorta guy myself...
  - CursedSilicon 10mo ago
    There was a native Linux client available when the game was still in alpha. Circa 2002/2003 Blizzard leans heavily on making sure their software is portable!
artimaeis 10mo ago
It offers native x86, Windows on ARM, and Apple Silicon versions. I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that. https://us.support.blizzard.com/en/article/76459 https://us.support.blizzard.com/en/article/76459 This is neat, and exciting that Windows emulation tooling is progressing! It seems like there’s a lot of work hardware vendors would need to do in order to make Win/Arm viable for game devs. I really wonder if that’s ever going to happen.
- mahmoudimus 10mo ago
  Windows ARM builds are available on their CDN.
- AndrewDavis 10mo ago
  > I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that. It has been around for a while, circa 2021. They made a forum post when they released it. For reasons unknown the link no longer works but here it is on the wayback machine. https://web.archive.org/web/20210512205620/https://us.forums.blizzard.com/en/wow/t/windows-10-arm64-support-now-available/961628 https://web.archive.org/web/20210512205620/https://us.forums...
geekman7473 10mo ago
TL;DR the author attempts to measure the ratio between native and emulated performance using Microsoft Prism on Windows. His measurements suggest that the emulated performance is very close to native performance. Though I am not skeptical of the authors methodology, I do suspect that the ARM64 build of WoW may not be as "optimized" as the x64 build. This is because in some of his workloads the emulated game actually outperformed the native game.
jauntywundrkind 10mo ago
I'm tentatively excited for the new Snapdragon X2 Elite. Or I would be if any of us could ever afford RAM prices ever again. The high end model has a 192-bit memory bus, a 3 channel design. 12+6 cores but very big/big more than less big/little. 53MB L3 cache is quite healthy. 80TOps NPU (int8). 9533 MT/s 192-bit memory for 228GB/s which is nipping right at Strix Halo & Nvidia Spark's heels. 12x PCIe 5.0, 4x PCIe 4.0, and "3x USB-C" 40Gb/s (hopefully not some shared bandwidth cop out). And some kind of pretty big GPU. The specs here are quite promising. And Qualcomm has started taking Linux drivers somewhat more seriously. Linux & mesa drivers are arriving now for previous Snapdragon X Elite & looking pretty promising. That said, this whole Device Tree world is hell, and never going to be good, and Qualcomm direly needs to get religion there & get some ServerReady type ACPI + UEFI compatibility standardized in the products, and stop OEMs from shipping these awful embedded-style non-PC things. I'm excited to see ARM finally actually show up with something competitive. Alas though, those RAM prices. What a sad buzzkill, and man this is going to take forever to work out.
- arjie 10mo ago
  I have always had trouble acquiring the actual devices at a competitive price. It is cheaper to get an M-series Mac Mini than a Snapdragon X Elite box and the former smokes the latter. The one advantage of the non-Macs is usually that their Linux support is good, but the Ideacentres or whatever that ship the S X E don't have very much support. Despite being fairly eager to try out this device, I could not bring myself to spend the money on what would remain in the closet after I failed to boot a Linux, any Linux.
DeathArrow 10mo ago
The emulated version beats the native version some times. Either the emulator is very good or the ARM build isn't optimized too much.
- ack_complete 10mo ago
  The compiler is also a factor, as MSVC's ARM64 backend is less mature than the x64 backend, while the xtajit(64) emulators in Windows were written by emulation veterans. But even then, I've typically seen a ~25% penalty between a native optimized ARM64 build and an emulated optimized x64 build. Major optimized code paths being disabled or suboptimal in the ARM64 port would definitely be more plausible, especially in licensed third-party libraries.
vintagedave 10mo ago
I’m curious if WoW is using any newer x86 instruction sets like AVX. I’ve been testing some math benchmarks on ARM emulating x64, and saw very little performance improvement with the AVX2+FMA builds, compared to the SSE4.x level. (X64 v2 to v3.) It was unexpected. It’s the first Windows build with Prism and the first time they’ve introduced AVX(2) support, so I wonder simply if the performance isn’t there yet. I’ve found very little info online about this.
- ack_complete 10mo ago
  AVX(2)'s main advantage is 256-bit width, since many of its operations are simply concatenated 128-bit ops (weird for ops like VPALIGNR), and cross-lane operations are expensive. NEON, on the other hand, only supports 128-bit ops, so AVX operations need to be split by the emulator. I'd expect more of a gain from enabling FMA, but that's assuming the program actually got built to use FMA -- it needs to either use it explicitly or have relaxations to allow the contraction. Oryon has 4 x 128-bit NEON pipes with 3c latency fadd and 4c latency fmul/fma, so it easily ends up latency bottlenecked unless there are plenty of independent calculations.
PeterStuer 10mo ago
Does WoW still use Blizzard's in house anti-cheat engine (Warden)? Interesting how the emulated version did not trip this.
- ktallett 10mo ago
  I didn't know it did for quite a while. I have regularly emulated WoW on Linux since 2013 and not had any significant issues.
- ohnoesjmr 10mo ago
  The anti-cheat streams executable code into the client, and that code is mostly for detecting tampering with the game, injected modules, etc. Not sure they care about it running in an emulated environment. They do effectively allocate an executable memory region, copy the machine code that was streamed into it, and jump to it. I guess in this case the emulation is an actual vm, rather than "rewrite x86 instructions into arm" (don't know much about this subject, but assumed that was how rosetta worked)
  - mort96 10mo ago
    Rosetta 2 rewrites x86 instructions into ARM, but it does this on the fly for generated instructions too. When you put x86 machine code into a buffer and then jump to execute it, Rosetta 2 dynamically translates those generated instructions into arm before executing them. At least that's what I gathered around the time it was released. It seems to hold up; JITed x86 applications work great under Rosetta 2.
    - vbezhenar 10mo ago
      In my experience they don't work great. JVM straight up crashed when Rosetta 2 was released and few years later it worked but with huge performance drop. Better than nothing, for sure.
- Thaxll 10mo ago
  It's a userspace anti cheat so it's not a problem.
KeplerBoy 10mo ago
I'm somewhat surprised that WoW runs on high settings on iGPUs these days.
- jajuuka 10mo ago
  How well it runs scales with how new the content is. They illustrated this in the article, but they didn't test the current expansion content and high traffic areas. I imagine main hubs like Dornogal or the current raid tier will require dropping the graphics very low to not have a slide show. Bumping up the resolution has a significant impact as well.
  - rkpiotr 10mo ago
    With player hubs, it's always a stutter, but it also depends on the network connection - you can have someone with the best rig showing 10 FPS and someone on a laptop with 30-40 FPS at the same time. Mass mobs combat in Karazhan is a pretty good raid tester - in raids, the FPS won't be as low as that (AVG), but the 1%/0.1% lows will be quite close. For systems with weaker and weaker CPUs, even the AVG FPS will come closer and closer as the game will get a single-core "world state" bottleneck more easily. I did some comparison benchmarks before for this, including a world boss world quest with lots of people ;) Also, regressions in WoW are a nightmare to handle. You go to the latest raid, the FPS is fine, but someone next to you has a slideshow.
saubeidl 10mo ago
I wish ARM wasn't so messy for Linux, with out of date device trees etc. All I want is something like a Macbook Air, but running Linux - long battery life, acceptable performance, an OS that respects me.
- jsiepkes 10mo ago
  This is also why I don't get why people are so enthusiastic about ARM. While there is nothing technically preventing manufacturers from using extensible standards and technologies like ACPI, UEFI, etc. with ARM, pretty much no one does. Meaning these devices are closed and pretty unusable with Linux.
  - jeroenhd 10mo ago
    ARM support is still mediocre, but it's improving with the new Snapdragons. Every generation seems to make running normal Linux on those things a little bit less of a pain. Funnily enough, the device with probably the best "normal" desktop protocol support is the old Windows RT tablet, which features an ARM SoC that runs UEFI and ACPI and everything. It's locked down to Microsoft's secure boot keys, unfortunately, but thanks to Microsoft abandoning the device, there are exploits you can use to bypass that.
    - kcb 10mo ago
      The Thinkpad x13s is pretty good for a mostly normal arm Linux laptop. The SOC is still pretty usable and it's functionality on Linux is also pretty complete. The main thing lacking is the speakers are very low to protect them from blowing out without a proper driver.
  - wkat4242 10mo ago
    Linux had the chance to fight against what GNU called "TiVoisation" but Linus said TiVo did nothing wrong. So now we have a world full of devices running open software but which are locked down. And a Linux foundation run by corporates. To me it is clear this was indeed a huge problem. Linux might not have become as big as it is now if it had taken GPL3 on board but it would have made it a lot harder for manufacturers to do what they're doing.
xinayder 10mo ago
You should add the newest zones, Dornogal and K'aresh (or Manaforge Omega raid) to the zone list. They are very heavy on graphics. Besides, I'd look forward to testinf with the nea ARM emulation layer Valve is developing.
jajuuka 10mo ago
I've been very curious about this since they added Windows on ARM support. Admittedly there hasn't been a really performant SoC to see how it stacks up to Apple Silicon. The Apple Silicon version runs so well I had hoped they brought that same performance jump to Windows on ARM. One thing I noticed about the Apple Silicon version was that it loads the game world significantly faster than x86. Even with lots of heavy addons. I'm curious if that mirrors to Windows ARM. Also curious if Battle.net client has the same bug as Apple Silicon where it consistently needs to run a game "update" after closing the game. The client is still x86 even on macOS so I'm wondering if this is an translation issue that could be fixed with a proper native client.
fleroviumna 10mo ago
[dead]

104 points by geekman7473 10mo ago

MuffinFlavored 10mo ago

How hard would it be for Blizzard to just recompile WoW to support arm64?

vbezhenar 10mo ago
They support arm64
teraflop 10mo ago
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.
pxc 10mo ago
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.
wyldfire 10mo ago
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.
- MangoToupe 10mo ago
  > * 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.
  - jama211 10mo ago
    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.
    - mobilio 10mo ago
      few days ago there was thread here about Valve and 20 years FPU bug... https://news.ycombinator.com/item?id=46009962 https://news.ycombinator.com/item?id=46009962 WoW was released 21 years ago AFAIK
      - dgellow 10mo ago
        now I feel old...
      - Wowfunhappy 10mo ago
        …the thing is, this is the type of bug I could also imagine happening under emulation. Or just following an OS update.
      - jama211 10mo ago
        That was a fantastic read, thank you for this
  - kergonath 10mo ago
    > 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.

cosmic_cheese 10mo ago

Interesting, I didn't know they'd added an Windows/ARM build. Makes some sense though, WoW has always been one of the best about broad platform/arch support… macOS/PPC and Windows/x86 versions were both available from day one and have stayed in lockstep the whole time, and it was among the first games to make both the PPC → x86 jump and x86 → ARM jump on Macs. Have heard that they had Linux builds internally early on too.

eptcyka 10mo ago
Wine has almost always worked, back when I played.
- cykros 10mo ago
  I recall seeing that it ran better on wine than on windows on the same hardware. Never tested myself as I'm more a runescape/ragnarok online sorta guy myself...
- CursedSilicon 10mo ago
  There was a native Linux client available when the game was still in alpha. Circa 2002/2003 Blizzard leans heavily on making sure their software is portable!

artimaeis 10mo ago

It offers native x86, Windows on ARM, and Apple Silicon versions. I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that. https://us.support.blizzard.com/en/article/76459 https://us.support.blizzard.com/en/article/76459 This is neat, and exciting that Windows emulation tooling is progressing! It seems like there’s a lot of work hardware vendors would need to do in order to make Win/Arm viable for game devs. I really wonder if that’s ever going to happen.

mahmoudimus 10mo ago
Windows ARM builds are available on their CDN.
AndrewDavis 10mo ago
> I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that. It has been around for a while, circa 2021. They made a forum post when they released it. For reasons unknown the link no longer works but here it is on the wayback machine. https://web.archive.org/web/20210512205620/https://us.forums.blizzard.com/en/wow/t/windows-10-arm64-support-now-available/961628 https://web.archive.org/web/20210512205620/https://us.forums...

geekman7473 10mo ago

TL;DR the author attempts to measure the ratio between native and emulated performance using Microsoft Prism on Windows. His measurements suggest that the emulated performance is very close to native performance. Though I am not skeptical of the authors methodology, I do suspect that the ARM64 build of WoW may not be as "optimized" as the x64 build. This is because in some of his workloads the emulated game actually outperformed the native game.

jauntywundrkind 10mo ago

I'm tentatively excited for the new Snapdragon X2 Elite. Or I would be if any of us could ever afford RAM prices ever again. The high end model has a 192-bit memory bus, a 3 channel design. 12+6 cores but very big/big more than less big/little. 53MB L3 cache is quite healthy. 80TOps NPU (int8). 9533 MT/s 192-bit memory for 228GB/s which is nipping right at Strix Halo & Nvidia Spark's heels. 12x PCIe 5.0, 4x PCIe 4.0, and "3x USB-C" 40Gb/s (hopefully not some shared bandwidth cop out). And some kind of pretty big GPU. The specs here are quite promising. And Qualcomm has started taking Linux drivers somewhat more seriously. Linux & mesa drivers are arriving now for previous Snapdragon X Elite & looking pretty promising. That said, this whole Device Tree world is hell, and never going to be good, and Qualcomm direly needs to get religion there & get some ServerReady type ACPI + UEFI compatibility standardized in the products, and stop OEMs from shipping these awful embedded-style non-PC things. I'm excited to see ARM finally actually show up with something competitive. Alas though, those RAM prices. What a sad buzzkill, and man this is going to take forever to work out.

arjie 10mo ago
I have always had trouble acquiring the actual devices at a competitive price. It is cheaper to get an M-series Mac Mini than a Snapdragon X Elite box and the former smokes the latter. The one advantage of the non-Macs is usually that their Linux support is good, but the Ideacentres or whatever that ship the S X E don't have very much support. Despite being fairly eager to try out this device, I could not bring myself to spend the money on what would remain in the closet after I failed to boot a Linux, any Linux.

DeathArrow 10mo ago

The emulated version beats the native version some times. Either the emulator is very good or the ARM build isn't optimized too much.

ack_complete 10mo ago
The compiler is also a factor, as MSVC's ARM64 backend is less mature than the x64 backend, while the xtajit(64) emulators in Windows were written by emulation veterans. But even then, I've typically seen a ~25% penalty between a native optimized ARM64 build and an emulated optimized x64 build. Major optimized code paths being disabled or suboptimal in the ARM64 port would definitely be more plausible, especially in licensed third-party libraries.

vintagedave 10mo ago

I’m curious if WoW is using any newer x86 instruction sets like AVX. I’ve been testing some math benchmarks on ARM emulating x64, and saw very little performance improvement with the AVX2+FMA builds, compared to the SSE4.x level. (X64 v2 to v3.) It was unexpected. It’s the first Windows build with Prism and the first time they’ve introduced AVX(2) support, so I wonder simply if the performance isn’t there yet. I’ve found very little info online about this.

ack_complete 10mo ago
AVX(2)'s main advantage is 256-bit width, since many of its operations are simply concatenated 128-bit ops (weird for ops like VPALIGNR), and cross-lane operations are expensive. NEON, on the other hand, only supports 128-bit ops, so AVX operations need to be split by the emulator. I'd expect more of a gain from enabling FMA, but that's assuming the program actually got built to use FMA -- it needs to either use it explicitly or have relaxations to allow the contraction. Oryon has 4 x 128-bit NEON pipes with 3c latency fadd and 4c latency fmul/fma, so it easily ends up latency bottlenecked unless there are plenty of independent calculations.

PeterStuer 10mo ago

Does WoW still use Blizzard's in house anti-cheat engine (Warden)? Interesting how the emulated version did not trip this.

ktallett 10mo ago
I didn't know it did for quite a while. I have regularly emulated WoW on Linux since 2013 and not had any significant issues.
ohnoesjmr 10mo ago
The anti-cheat streams executable code into the client, and that code is mostly for detecting tampering with the game, injected modules, etc. Not sure they care about it running in an emulated environment. They do effectively allocate an executable memory region, copy the machine code that was streamed into it, and jump to it. I guess in this case the emulation is an actual vm, rather than "rewrite x86 instructions into arm" (don't know much about this subject, but assumed that was how rosetta worked)
- mort96 10mo ago
  Rosetta 2 rewrites x86 instructions into ARM, but it does this on the fly for generated instructions too. When you put x86 machine code into a buffer and then jump to execute it, Rosetta 2 dynamically translates those generated instructions into arm before executing them. At least that's what I gathered around the time it was released. It seems to hold up; JITed x86 applications work great under Rosetta 2.
  - vbezhenar 10mo ago
    In my experience they don't work great. JVM straight up crashed when Rosetta 2 was released and few years later it worked but with huge performance drop. Better than nothing, for sure.
Thaxll 10mo ago
It's a userspace anti cheat so it's not a problem.

KeplerBoy 10mo ago

I'm somewhat surprised that WoW runs on high settings on iGPUs these days.

jajuuka 10mo ago
How well it runs scales with how new the content is. They illustrated this in the article, but they didn't test the current expansion content and high traffic areas. I imagine main hubs like Dornogal or the current raid tier will require dropping the graphics very low to not have a slide show. Bumping up the resolution has a significant impact as well.
- rkpiotr 10mo ago
  With player hubs, it's always a stutter, but it also depends on the network connection - you can have someone with the best rig showing 10 FPS and someone on a laptop with 30-40 FPS at the same time. Mass mobs combat in Karazhan is a pretty good raid tester - in raids, the FPS won't be as low as that (AVG), but the 1%/0.1% lows will be quite close. For systems with weaker and weaker CPUs, even the AVG FPS will come closer and closer as the game will get a single-core "world state" bottleneck more easily. I did some comparison benchmarks before for this, including a world boss world quest with lots of people ;) Also, regressions in WoW are a nightmare to handle. You go to the latest raid, the FPS is fine, but someone next to you has a slideshow.

saubeidl 10mo ago

I wish ARM wasn't so messy for Linux, with out of date device trees etc. All I want is something like a Macbook Air, but running Linux - long battery life, acceptable performance, an OS that respects me.

jsiepkes 10mo ago
This is also why I don't get why people are so enthusiastic about ARM. While there is nothing technically preventing manufacturers from using extensible standards and technologies like ACPI, UEFI, etc. with ARM, pretty much no one does. Meaning these devices are closed and pretty unusable with Linux.
- jeroenhd 10mo ago
  ARM support is still mediocre, but it's improving with the new Snapdragons. Every generation seems to make running normal Linux on those things a little bit less of a pain. Funnily enough, the device with probably the best "normal" desktop protocol support is the old Windows RT tablet, which features an ARM SoC that runs UEFI and ACPI and everything. It's locked down to Microsoft's secure boot keys, unfortunately, but thanks to Microsoft abandoning the device, there are exploits you can use to bypass that.
  - kcb 10mo ago
    The Thinkpad x13s is pretty good for a mostly normal arm Linux laptop. The SOC is still pretty usable and it's functionality on Linux is also pretty complete. The main thing lacking is the speakers are very low to protect them from blowing out without a proper driver.
- wkat4242 10mo ago
  Linux had the chance to fight against what GNU called "TiVoisation" but Linus said TiVo did nothing wrong. So now we have a world full of devices running open software but which are locked down. And a Linux foundation run by corporates. To me it is clear this was indeed a huge problem. Linux might not have become as big as it is now if it had taken GPL3 on board but it would have made it a lot harder for manufacturers to do what they're doing.

xinayder 10mo ago

You should add the newest zones, Dornogal and K'aresh (or Manaforge Omega raid) to the zone list. They are very heavy on graphics. Besides, I'd look forward to testinf with the nea ARM emulation layer Valve is developing.

jajuuka 10mo ago

I've been very curious about this since they added Windows on ARM support. Admittedly there hasn't been a really performant SoC to see how it stacks up to Apple Silicon. The Apple Silicon version runs so well I had hoped they brought that same performance jump to Windows on ARM. One thing I noticed about the Apple Silicon version was that it loads the game world significantly faster than x86. Even with lots of heavy addons. I'm curious if that mirrors to Windows ARM. Also curious if Battle.net client has the same bug as Apple Silicon where it consistently needs to run a game "update" after closing the game. The client is still x86 even on macOS so I'm wondering if this is an translation issue that could be fixed with a proper native client.

fleroviumna 10mo ago

[dead]