The absence of Bootcamp is preventing me from switching to M1 or M2... Will there ever be a solution?

[bobcomer]

There is no market for the desktop "experience".

I disagree just about as much as one can disagree with you.

Only for an established desktop ecosystem with all apps.

Same thing, though those big monitors and other desktop accoutrements sell well to.

And you don’t win the mobile market by switching to a less efficient silicon architecture.

You don't understand -- I'm saying ARM wont always be the most efficient.

The market is macOS on Apple Silicon and nothing else.

That's has no basis in reality, especially when MacOS sells so little.

 

[spiderman0616]

You could get a 2nd hand intel-based iMac and use Boot Camp. Surely you can get one cheap and run Windows 10 on it?

Good point

 

[Gudi]

I disagree just about as much as one can disagree with you.

No, you don't. You already stated that it's all about the (legacy x86 Windows) software for you. If you only needed the look and feel of a desktop, you could already switch to Samsung DeX or macOS.

Same thing, though those big monitors and other desktop accoutrements sell well to.

Not without Windows. Not as accessories to a Samsung Galaxy phone.

You don't understand -- I'm saying ARM wont always be the most efficient.

Apart from the technical difficulties to compete with a CISC processor that needs to be 32-bit backward compatible against a 64-bit only RISC processor, which only runs an OS that adapts to the silicon and not the other way around. There is still the tiny problem that all the money in the world goes into smartphones and not even Intel wants to be stuck on x86. Apple bought all 3nm production capacity from TSMC, with which they will make even more money to enhance their chip lead.

Intel x86 chips will slightly improve at their own pace, but never close the gap and overtake Apple Silicon on energy efficiency. A new yet unknown technology will emerge in 10 years time, but it won't be the return of x86. Much as Apple Silicon isn't the second coming of PowerPC compatibility.

That's has no basis in reality, especially when MacOS sells so little.

There are more than two billion active iPhones, iPads, Macs, and other Apple devices worldwide. They all run on Apple Silicon. If you take into account that half of the global population lives on less than US$6.85 per person per day, this planet is already saturated with Apple computers. There's no explosive growth, because we're already hooked on iPhones. Apple is the largest technology company in history of mankind. There is a glass ceiling, because mankind is limited in numbers. Who ever wants to dethrone Apple on energy efficiency must win a "David and Goliath" uphill battle.

 

[bobcomer]

No, you don't. You already stated that it's all about the (legacy x86 Windows) software for you. If you only needed the look and feel of a desktop, you could already switch to Samsung DeX or macOS.

No, still disagree. I like the big monitor, a mouse, and a real keyboard. That's why I have a desktop at work and 3 at home, intel iMac, Windows, and Mac Studio.

Not without Windows.

Mac Studio, mac Mini, iMac, Mac Pro? They fill that same role. It's true they don't sell as well as windows desktops but they do sell.

Not as accessories to a Samsung Galaxy phone.

Not yet.

Intel x86 chips will slightly improve at their own pace, but never close the gap and overtake Apple Silicon on energy efficiency. A new yet unknown technology will emerge in 10 years time, but it won't be the return of x86. Much as Apple Silicon isn't the second coming of PowerPC compatibility.

You never know...

There are more than two billion active iPhones, iPads, Macs, and other Apple devices worldwide. They all run on Apple Silicon. If you take into account that half of the global population lives on less than US$6.85 per person per day, this planet is already saturated with Apple computers. There's no explosive growth, because we're already hooked on iPhones. Apple is the largest technology company in history of mankind. There is a glass ceiling, because mankind is limited in numbers. Who ever wants to dethrone Apple on energy efficiency must win a "David and Goliath" uphill battle.

You do know there's more android phones than iPhones world-wide, don't you? There's where the growth and the loss will come from, and Windows, MacOS, Linux will still be alive on non-phones. Just because they have a CPU doesn't make a phone as capable as a computer.

 

[theluggage]

Inflexibility is not a virtue. How many corporations relied on IBM mainframes, until they threw them all away and switched over to PCs?

You're talking about a slow process that started in the 1970s (...and before microcomputers there were minicomputers that were cheaper and smaller than mainframes & could be used by a small group of people) and never really finished (last I looked, IBM still sell mainframes).

The latest revolution - mobile devices and ubiquitous wireless broadband - only really kicked off ~2010 so it is early days. If anything, that is moving the balance back towards a modern version of the mainframe (cloud services) + smart terminal/thin client (mobile/tablet/thin laptop) model. These trendy large language models? They eat data, and the data lives in the cloud, so that's where the AIs will live.

Yep, it has, but there hasn't been a fast and capable enough mobile processor that could run x86/64 Windows applications yet. (not really even close yet)

...but it's only the "x86 Windows applications" part of that which makes that even partially true. The M1 is a mobile processor (it's in the iPad) and it can run Arm64 Windows applications perfectly well - and while it wouldn't be the first choice for running x86 Windows apps it can do it, with caveats...

If you're talking about phones and tablets, I think it's fairer to say that there aren't many x86/64 Windows applications that could run usefully on a phone or tablet - not because the processor isn't fast enough but because the desktop UI is unusable on a phone. Part of "software lock in" isn't technical - its user training. I think Microsoft and Intel failed in the mobile market because their unique selling point didn't transfer - all those x86 legacy apps were as much use as a chocolate teapot on a 4" touch screen, and if you have to learn a new UI why not learn a new application? Apple and Google created ecosystems of new, phone-friendly apps and web services that were actually useful on mobile devices and which didn't really care what processor they ran on (Android mainly run Dalvik bytecode - and x86 Android devices do/did exist), and while iOS Apps used ARM binaries, until 2020 they were developed and tested by compiling for x86 and running in a container on a Mac. There's not a lot of point in Intel creating better mobile devices that are close to ARM efficiency - they'd have to beat ARM to have a market advantage.

I think we're moving to an era when processor architecture will only be of interest to programmers writing operating systems and language runtimes. Software that doesn't run in a browser will be distributed as bytecode and translated on installation or JIT. Future OSs simply won't permit applications to access "bare metal" architecture-dependent stuff, everything will have to use OS frameworks. That's hardly an extraordinary claim - Apple App Store guidelines pretty much require that, and the App store already supports bytecode-based, translate-on-download distribution, while modern MS software uses the bytecode-based Common Language Runtime - not quite processor-independent yet, but heading there. Then there's the whole Linux/Unix world which has always been focused on source-code rather than binary compatibility. Although there were plenty of exceptions where porting was a big deal, for a lot of Mac software the transition to ARM was close to "tick the ARM box in XCode and re-compile" - if Apple switch ISAs again I suspect the vast majority of apps will just re-compile, if they haven't already shifted to bytecode.

So I think we're heading to a future where x86 is only needed for legacy Windows applications which are (if slowly) going to dwindle in importance, and new software will be increasingly platform independent. Doesn't mean Windows will be going away any time soon - it has a huge headstart and, of course, it will be a supported platform for newer software, but I think we're past "peak Windows". Microsoft's long-term future is probably in (cloud) services and persuading their huge customer base to take those up.

Thing is, if Microsoft did produce a native Apple Silicon version of Windows at the moment, it would blow every other windows-on-ARM system out of the water (even their new ARM development system is outperformed by the similarly-priced M2 Mini, although MS are more generous with RAM and storage) especially if they could incorporate Rosetta 2 tech into their x86 translators (ISTR Apple Silicon includes features to optimise x86 translation). Sounds good, but that would mean Microsoft completely burning their traditional bridges will Dell/Lenovo/HP etc. in favour of something that only Apple could make (so HPDellnovo would double down on x86). I don't think Apple would want to facilitate that either because, although they'd enjoy the sales, they'd be losing potential services customers to MS.

 

[Gudi]

You do know there's more Android phones than iPhones world-wide, don't you?

Just like there are more PCs than Macs, which makes it harder for Microsoft to compete. It's the exact same story all over again. Apple introduced the Macintosh and Windows copied only the OS and licensed it to OEMs to quickly gain marketshare. Google did the same with iOS, except their license is even free. Nothing on the side of the clones comes from the same company. Not only is there no coherent strategy between hardware and software development. The market leaders on mobile and desktop are also fierce competitors.

Take the Samsung DeX, it's only a feature of some high-end Galaxy phones. Other Android phones don't have it and while you can run the Android version of MS Office, you have no backward compatibility to x86 Windows apps. So you're pretty much stuck with what Android tablets can already do today. Chromebooks on the other hand offer desktop-like web apps and web services plus the PlayStore. Everyone's solution is the hardware of an desktop plus touch-based tablet apps.

Only Microsoft could even attempt to transition its entire Windows software ecosystem over to ARM, with a similar solution as Rosetta 2 on the Mac. But nobody else wants to become dependent on the old WINTEL monopoly ever again. It's a blessing for the industry that you can fork your own branch of Android and design your own ARM cpus if necessary. And Microsoft and Intel themselves suffer from the fact, that there are already established players in the mobile market, which won't make room for them

Apple is the only company, which can truly merge desktop and mobile computing and use both platforms to their own advantage on custom silicon with their own programming language and in combination with the Apple Watch and services like Apple+. Everyone else only holds a partial leadership over a tiny niche of the overall computing market.

Just because they have a CPU doesn't make a phone as capable as a computer.

Phones have always been more capable and widespread than other (desktop) computers. There's still no GPS and no barometer on my iMac and only one selfie camera with no optical zoom. I can't even unplug it and walk around with it. No orientation sensor will turn the picture back upright when I hold it upside down. A terrible computer really.

 

[bobcomer]

...but it's only the "x86 Windows applications" part of that which makes that even partially true. The M1 is a mobile processor (it's in the iPad) and it can run Arm64 Windows applications perfectly well - and while it wouldn't be the first choice for running x86 Windows apps it can do it, with caveats...

True, but those caveats are pretty big, at least with my work flow and right now. It will get better, I have no doubt of that. So a desktop Arm machine will eventually be able to take over a desktop role for a lot of things. Drivers would still be a problem, especially with older manufacturing hardware. And as I told Gudi, if it runs well all I need to run, I really don't care if it's ARM or intel, but I don't think ARM will be able to outperform intel on the desktop, ever -- at least until they stop using mobile chips in desktops.

If you're talking about phones and tablets, I think it's fairer to say that there aren't many x86/64 Windows applications that could run usefully on a phone or tablet - not because the processor isn't fast enough but because the desktop UI is unusable on a phone.

Agreed, the UI just doesn't fit for the job, that is the biggest hurdle. I know if I have to type in a whole sentence on my phone, it's a total PITA, and forget about complex data entry/ forms.

Part of "software lock in" isn't technical - its user training.

Could be, I never really had to deal with that situation, worst I've had to do is answer questions about specific tasks,

I think Microsoft and Intel failed in the mobile market because their unique selling point didn't transfer - all those x86 legacy apps were as much use as a chocolate teapot on a 4" touch screen, and if you have to learn a new UI why not learn a new application? Apple and Google created ecosystems of new, phone-friendly apps and web services that were actually useful on mobile devices and which didn't really care what processor they ran on (Android mainly run Dalvik bytecode - and x86 Android devices do/did exist), and while iOS Apps used ARM binaries, until 2020 they were developed and tested by compiling for x86 and running in a container on a Mac. There's not a lot of point in Intel creating better mobile devices that are close to ARM efficiency - they'd have to beat ARM to have a market advantage.

It seems so. I actually like Windows Phone, I even have one in my stack of old phones, but the lack of apps was a killer, and that's something Apple and Google made sure of. Apps for the masses.

I think we're moving to an era when processor architecture will only be of interest to programmers writing operating systems and language runtimes. Software that doesn't run in a browser will be distributed as bytecode and translated on installation or JIT. Future OSs simply won't permit applications to access "bare metal" architecture-dependent stuff, everything will have to use OS frameworks. That's hardly an extraordinary claim - Apple App Store guidelines pretty much require that, and the App store already supports bytecode-based, translate-on-download distribution, while modern MS software uses the bytecode-based Common Language Runtime - not quite processor-independent yet, but heading there. Then there's the whole Linux/Unix world which has always been focused on source-code rather than binary compatibility. Although there were plenty of exceptions where porting was a big deal, for a lot of Mac software the transition to ARM was close to "tick the ARM box in XCode and re-compile" - if Apple switch ISAs again I suspect the vast majority of apps will just re-compile, if they haven't already shifted to bytecode.

Agreed, and I look forward to those days.

So I think we're heading to a future where x86 is only needed for legacy Windows applications which are (if slowly) going to dwindle in importance, and new software will be increasingly platform independent. Doesn't mean Windows will be going away any time soon - it has a huge headstart and, of course, it will be a supported platform for newer software, but I think we're past "peak Windows". Microsoft's long-term future is probably in (cloud) services and persuading their huge customer base to take those up.

Hard to tell, all I now is I still need them and will for the foreseeable future. Cloud is still a problem for a lot of the world because of the lack of a decent internet connection, but Microsoft has been using VM's for a LONG time and they're pretty good at it, hence your terminal scenario...

Heck, my home connection isn't reliable enough, and my business connection isn't fast enough. The state I live in can be so backward at times.

 

[bobcomer]

Just like there are more PCs than Macs, which makes it harder for Microsoft to compete.

Different markets.

Take the Samsung DeX, it's only a feature of some high-end Galaxy phones. Other Android phones don't have it and while you can run the Android version of MS Office, you have no backward compatibility to x86 Windows apps. So you're pretty much stuck with what Android tablets can already do today. Chromebooks on the other hand offer desktop-like web apps and web services plus the PlayStore. Everyone's solution is the hardware of an desktop plus touch-based tablet apps.

Yep, and that's why I don't use it It's pretty much useless for what I want to run.

 

[Gudi]

Different markets.

Again! The iPhone already replaced: calculators, alarm clocks, dictaphones, calendars, cameras, camcorders, satnav, maps, walkman, gameboy, books, newspapers, wallets, plane tickets, car keys and many more. You might think, you're in a different market, but I want to hear what the iPhone thinks. 🦻📲

 

[bobcomer]

Again! The iPhone already replaced: calculators, alarm clocks, dictaphones, calendars, cameras, camcorders, satnav, maps, walkman, gameboy, books, newspapers, wallets, plane tickets, car keys and many more. You might think, you're in a different market, but I want to hear what the iPhone thinks. 🦻📲

Again, it's a different market PC vs. phone, and I think this discussion has run its course. We have very different views and that is okay.

And the iPhone doesn't think, at least not yet. I'm not sure I'd want one that did, but I may be surprised about that.

 

[l0stl0rd]

Bootcamp for ARM is about as likely as eGPUs coming back.

Parallels is not a real option, because gimped OpenGL and DirectX.

Just buy a Minisforum PC or similar like I did

 

[mi7chy]

Bootcamp + AARCH64 isn't going to change anything. Recently dual booted my M1 MBA with Linux and there's barely if any mainstream software for AARCH64.

Better picking up a x64 sidekick as the other person suggested. I like the looks of this one but would prefer an AMD 7840U. Get it without the bundled SSD and WIFI and add your own. Intel WIFI 6E AX210/211/411 modules are around $20 and use your own NVMe SSD.

 

[l0stl0rd]

Bootcamp + AARCH64 isn't going to change anything. Recently dual booted my M1 MBA with Linux and there's barely if any mainstream software for AARCH64.

Better picking up a x64 sidekick as the other person suggested. I like the looks of this one but would prefer an AMD 7840U. Get it without the bundled SSD and WIFI and add your own. Intel WIFI 6E AX210/211/411 modules are around $20 and use your own NVMe SSD.

I saw that looks great and has Oculink for eGPUs which is interesting.
Wish there was 32 GB option.

 

[Nicole1980]

Here's what I dont get and havent had anyone explain to me clearly: Apple, using Rosetta 2, is able to emulate x86 Mac soft really well on M1 Macs. How is that different from being able to emulate x86 windows software really well?
In both cases, the code is x86, so in theory theres no difference, right?

 

[bobcomer]

Here's what I dont get and havent had anyone explain to me clearly: Apple, using Rosetta 2, is able to emulate x86 Mac soft really well on M1 Macs. How is that different from being able to emulate x86 windows software really well?
In both cases, the code is x86, so in theory theres no difference, right?

Actually that first sentence is wrong, it emulates X64 Mac Software, not x86 (32-bit) software. Windows on Arm emulates both x86 and x64 Windows software, which makes it quite a bit more complex.

 

[deconstruct60]

Here's what I dont get and havent had anyone explain to me clearly: Apple, using Rosetta 2, is able to emulate x86 Mac soft really well on M1 Macs. How is that different from being able to emulate x86 windows software really well?
In both cases, the code is x86, so in theory theres no difference, right?

What the software calls is different. Mac apps sit on top of the macOS operating system software libraries. And those libraries sit on top of the macOS kernel. It is layers. Rosetta recompiles only the top application layer into Arm code. (the new binary is stuffed onto disk in a transparent way to causal end users). Most of the libraries are also recompiled by Rosetta2. However where both make calls to the operating system that is 'handled' to transition over to presenting data for the native Arm macOS kernel.

It is a bit of stretch to describe this are actually emulating. The program is recompiled into Arm binaries with some 'extra stuff' sprinkled in as necessary to get around substantive semantic gaps how Arm processors work and x86 work. Rosetta2 can deal with dynamically compiled code (it can take a dynamic opcode fragment , convert it and jump in/out of it. But the bulk of execution is just with Arm binaries that just get compiled once.)

Rosetta2 has limitations though. It doesn't do the following:

a. kernel extension/driver code. ( it won't emulate anything at the OS kernel level).
b. no hardware Virtualization ( it won't emulate any program that tries to run a virtual machine )
c. AVX/AVX2 code ( it only does a subset of x86 code. the AVX is the modern version of the vector/SIMD opcodes to doing vectorized math , AI/ML tasks , and some encryption stuff among other things. There is a separate set of x86 code that cover similar domain of tasks called SSE, SEE2 ,SSE3, SSE4 ( and one reason why X86 is so constipated bloated with overlapping stuff. )

So at the operating system's kernel level Rosetta 2 basically 'quits'. To quit correctly basically needs to know where the OS boundary starts. And it only constructed to know where the macOS boundary is (as well as some the library boundaries where want to trap earlier into the unmodifed Arm code libraries for performance reasons.)

It does do a subset of x86 (32-bit) stuff that overlaps with the x86_64 user level opcodes. (e.g., simple 32-bit math operations). But isn't going to do 32-bit level kernel/OS level stuff.

[ Rosetta (the first. which wasn't technically Apple technology) I think had fewer legacy opcode gaps coverage. And for some simple driver classes I think there was workaround. That one did do a lot less bulk, upfront recompiling and storing a new version. ]

Apple has done some boundary mapping for Linux so Rosetta2 with some file space cross mounting and some adjustments to a guest Linux. Similar issues there too though. Doubtful any x86 driver is going to work. Linux or apps that try to nest another virtualization layer on top of the guest isn't going to work either.

[ The Linux thing for Apple probably has a substantive "eat your own dog food " factor as Apple Web services has lots of Linux instances to do development on. Probably pretty likely the hypervisor and virtualization framework for Linux will aways be incrementally better than that for Windows over the long term. ]


The latter is where start to run into some Windows issues. Windows has its own virtualization/emulation stuff for dealing with old cranky legacy 32 bit stuff ( Windows 11 has dump some of the really old , old , old legacy compatibility stuff).


Technically, if Apple wanted to throw a lot of money down a money pit for an app nobody was going to actually explicitly pay for they could possibly do something. Same thing with the AVX family opcodes though too.
Windows already has a converter from x86 to Arm that has been built to deal with all the cruft that is portable across standard Arm implementations. So it would be a duplicative effort that generates no revenue for Apple. So not only money down the drain, but no deep widespread need for it anyway.

 

[mcnallym]

Or to put very simplified terms so may not 100% correct but allows simplification.

Windows Applications make calls to Windows OS libraries/frameworks.
Mac Applications make calls to Mac OS libraries/frameworks.

The libraries talk to the OS which talks to the hardware in very very simple terms.

Mac OS doesn’t have Windows Libraries/Frameworks hence why Windows Apps don’t run in Mac OS even on Intel Macs unless bootcamp and run windows or run a virtual machine with Windows OS that then runs the windows apps. At which point windows apps call Windows libraries and not communicating to Mac OS.

All Rosetta2 does is recompile the too Layer of the Mac app into an ARM binary so can run on Apple Silicon. Thus the app can make the calls into the Mac OS library/framework. there is no windows libraries present still for a windows app to call in Mac OS.

Rosetta2 does not present a virtual x86/x86-64 CPU and OS the application which is what would need to do to support x86/x86-64 windows applications.

as stated at top this is very simplified down to make easier understanding.

above explanation from deconstruct60 gives more detail and accuracy But have dumbed down/simplified to try and make as clear as possible.

 

[anselpela]

Yeah, buy a PC.

I used boot camp for years. It was...fine. But I'm not going to lose sleep over it, and certainly wouldn't give up using Apple Silicon for it. Just get a PC.

 

[eltoslightfoot]

Yeah, buy a PC.

I used boot camp for years. It was...fine. But I'm not going to lose sleep over it, and certainly wouldn't give up using Apple Silicon for it. Just get a PC.

Hey! That‘s what I actually ended up doing. Apple is certainly not going to go through the work of adding it to AS.

 

[Ethosik]

Buy the right tool for the job and prioritize your needs. Don't expect a 'bootcamp' solution (that's a thing from the past). Buy a PC, a console or a Steamdeck for gaming and see if you have some money left for a Mac (or stick with your old Mac). Or buy a Mac (or stick with your old Mac) and see if you have some money left for a PC, a console or a steam deck. As I said, it is about prioritizing your needs .

Agreed. Buy the tool for the job.

With how recent games are handling the 13900k and 4090, I’m thinking of ditching PC for consoles. I’m tired of bad PC ports and treatment.

 

[leman]

Actually that first sentence is wrong, it emulates X64 Mac Software, not x86 (32-bit) software. Windows on Arm emulates both x86 and x64 Windows software, which makes it quite a bit more complex.

Rosetta 2 can translate both 32-bit and 64-bit x86 code to ARM64. It's just that macOS does not support 32-bit applications (it simply lacks the system frameworks and environment to link and run 32-bit application code) — but you can run 32-bit x86 code on a modern Mac (including Apple Silicon). This is how wine runs 32-bit windows applications for example.

I also wouldn't describe Windows on Arm transpiler as "more complex". In order to improve performance, Microsoft's transpiler will knowingly produce wrong code. Apple's solution is rock solid and runs pretty much anything, Microsoft's is more of a hit and miss. I hope that since Microsoft officially supports running on Apple Silicon now, they will leverage the x86 hardware emulation capabilities of M-series to improve the performance and the stability of their x86 transpiler.

 

[bobcomer]

Rosetta 2 can translate both 32-bit and 64-bit x86 code to ARM64.

Okay, but I thought 32-bit code had gone away a long time ago. I stand corrected.

 

[leman]

Okay, but I thought 32-bit code had gone away a long time ago. I stand corrected.

“Code” and “application” are two different things. Both Intel and ARM Macs still support execution of x86 32-bit code, but an application is more than just code as it assumes existence of certain system libraries and execution environment. MacOS has deprecated 32-bit x86 applications. But you could still run an older 32-bit app if you developed a wrapper that loads and links the code in that app which emulating the required frameworks.

This might seem like an academic distinction - and for most users it is, as an end result does not change - their 32-bit apps won’t run. But this distinction becomes important when we look at software like wine. In fact, it Valve wanted they could probably support running many older 32-bit games on Steam without too much hassle as the API surface used by most is fairly limited.

 

[bobcomer]

“Code” and “application” are two different things. Both Intel and ARM Macs still support execution of x86 32-bit code, but an application is more than just code as it assumes existence of certain system libraries and execution environment. MacOS has deprecated 32-bit x86 applications. But you could still run an older 32-bit app if you developed a wrapper that loads and links the code in that app which emulating the required frameworks.

This might seem like an academic distinction - and for most users it is, as an end result does not change - their 32-bit apps won’t run. But this distinction becomes important when we look at software like wine. In fact, it Valve wanted they could probably support running many older 32-bit games on Steam without too much hassle as the API surface used by most is fairly limited.

I actually understand that distinction, but really thought Apple had disabled that. I haven't seen it discussed anywhere and don't do any development on MacOS. (or ARM for that matter)

 

[Colstan]

I actually understand that distinction, but really thought Apple had disabled that. I haven't seen it discussed anywhere and don't do any development on MacOS. (or ARM for that matter)

It's how CodeWeavers added 32-bit game support to CrossOver, back in a February update.

Presenting CrossOver 22.1 — The hallmark of this holiday | CodeWeavers Blog

By Jana Schmid | Hallmarks of the CrossOver 22.1 release for macOS, Linux and ChromeOS and 25% limited time offer.

www.codeweavers.com

"The hallmark of this release is 32-bit DirectX 10/11 games on macOS. Games that are now playable include Command and Conquer Remastered Collection, Total War ROME II - Emperor Edition, BioShock Infinite and Magicka 2."