first its just an app on your pc… hmm… we could call it xbmc!
then later when it barely looks like it started they could pick an even dumber name… Jodi!
It’s cooler than the headline implies. It’s not just hints at future support. It appears that it is a 360 emulator running the emulator that they built to run Xbox games on the 360.
I wonder if that has anything to do with the proprietary nature of the Nvidia chip in the original Xbox. It was able to do things outside of normal direct X and normal Nvidia drivers (it had extra instruction sets compared to the consumer version of the same chip for instance). Given all the layoffs and time it may be that there’s just no more documentation on that and it was actually easier to do the nested emulator thing than it was to try to reverse engineer whatever proprietary bullshit was going on 25 years ago.
Yo dawg, I heard you like emulation…
Genuine question for those with experience of VMs and virtualisation…
Is this not really inefficient? Like, running a VM on a platform like Windows or Linux introduces some mega overheads… surely having another level of abstraction would make things real slow, even on decent hardware?
I’m just someone with a surface level knowledge so happy to be educated.
The only accurate answer is basically going to be “it depends, we’ll need to see how they’re doing it.” You’re correct that virtualizing an entire system is inefficient. Outright attempting to emulate the entire Xbox would likely be a struggle, even on good hardware. But a translation layer (like WINE) can be extremely efficient, because it allows you to simply translate things from one system to another.
For example, DirectX is a proprietary Microsoft driver, developed for both Xbox and Windows. It’s what allows for things like native Xbox controller support on a Windows PC. It’s also a large part of why Xbox games were fairly straightforward to port to PC, meaning games could release on both the Xbox and PC to hit both markets.
Linux doesn’t natively run DirectX, because it’s proprietary. So anything relying on DirectX will fail if you try to boot it directly on Linux, the same way a Linux program would fail if its dependencies were missing. But Linux can use a translation layer like WINE to translate a program’s DirectX API calls into something that Linux can use.
So a program boots in WINE, and attempts to call DirectX’s API. WINE simply takes those API calls, and translates them to a Linux-native equivalent for your OS to use. Notably, WINE is not emulating the entire Windows OS. It is simply translating the API calls back and forth so the program and Linux can talk to each other. The program likely doesn’t even know it’s running on Linux. It thinks it’s talking to DirectX’s API, because it is getting successful inputs and outputs.
You don’t need to virtualize the entire OS, when you can simply translate from A to B and back again. This can be extremely efficient, because it allows you to boot only what you need, instead of booting the entire Windows OS. If your Linux install only takes up 60% of the resources that Windows would, and then WINE takes up an additional 30%, that means you’re still running 10% faster than native Windows.
Hey this is magic information - thank you for your reply.
Depends on too many factors to list, and how much of each layer is true emulation vs getting the WINE treatment. With the age of the platforms in question though you can take a 40% performance hit at every step and still only get 200fps running uncapped.
