Xenia: Port to UWP, Xbox Series X|S and Xbox One

Created on 24 Nov 2020  Â·  13Comments  Â·  Source: xenia-project/xenia

Feature request.
Lots of 360 games will never be ported to xbox series x due to expired licenses. Would love to play games like godfather for 360 on my series x in dev mode.

enhancement platform-windows

Most helpful comment

That's an interesting thing to try, though relatively low-priority for me personally currently, but shouldn't be very difficult.

What currently needs to be done is:

  • [ ] Graphical user interface

@Razzile is working on a beautiful Qt-based GUI for Xenia, we are not sure yet though whether it will look and feel native enough in UWP environment, possibly a new frontend will be needed. It already has some separation between common utility parts and Qt-specific code, so maybe even in case the views will need to be replaced, a significant portion of viewmodels will stay.

  • [ ] Cleanup of used Windows API functions — only use what is allowed for the UWP API partitions

Started yesterday — memory mapping has already been ported to the FromApp functions which don't support executing and writing the same pages simultaneously in a73592c2ef050ea4ee31eb9100bb075fdfe7dc92. There are some other FromApp functions though, but recent headers have wrappers for desktop names of certain functions, possibly with UWP's security requirements.

Platform #defines for different API partitions / device families are another story, by the way — these are even more complicated than Xbox Live/Xbox Game Pass subscriptions :)

  • [ ] Windows.Gaming.Input

Polling-based just like XInput, though also has connection/disconnection events. Seems not to have controller number lights (though needs some research), instead each controller is associated to a Windows.System.User, which isn't very helpful though. Another issue is that unlike XInput which takes 4 of whichever devices were connected, and those may be steering wheels, flight sticks, etc., Windows.Gaming.Input exposes different types of devices through different arrays, and we'll have to merge them somehow without giving priority to some types of devices over another (unless the Xbox 360 does that), including when Xenia is started with input devices already connected, thus probably (but haven't checked) not receiving the connection events for the existing devices. Gamepad keyboard input also needs some research, though it isn't even properly supported on Xenia with XInput yet.

  • [ ] Overall event-based application life cycle

Xenia's entry point architecture was designed to run a main function from the beginning to the end of the process, with a xe::ui::Loop created (that for some reason also works in a separate thread) by the OS-agnostic entry point. All this needs to be revisited, at least (as a quick change) to split the entry point into initialization (accepting the OS-specific context — not sure what it would contain on UWP, but for something like the ANativeActivity* on Android — as an argument) and shutdown, with the xe::ui::Loop created by the OS-specific initialization function, that would probably asynchronously receive events from the OS-specific application code.

  • [ ] Application suspension

When the OS asks Xenia to be suspended, we'll need to somehow more or less safely (with regards to synchronization primitives) suspend all game threads, and also stop doing anything in the emulator until resumed.

  • [ ] Environment integration

Xenia should use the default directories for everything it writes, maybe separate depending on what the OS provides (haven't done research on this yet — but on Android there are separate data and cache directories, for instance, and it would be more suitable to place the shader cache in the cache directory as it may be cleared separately without touching the saves/configuration through Android settings). Maybe logging should also be disabled by default, as the data directory's purpose is unlikely to include that.

Currently the minimum supported Windows version to run an UWP version of Xenia would be 10.0.17134.0 (1803) since it offers a way to map memory at a specified address, which is necessary to map the physical memory of the Xbox 360.

All 13 comments

That's an interesting thing to try, though relatively low-priority for me personally currently, but shouldn't be very difficult.

What currently needs to be done is:

  • [ ] Graphical user interface

@Razzile is working on a beautiful Qt-based GUI for Xenia, we are not sure yet though whether it will look and feel native enough in UWP environment, possibly a new frontend will be needed. It already has some separation between common utility parts and Qt-specific code, so maybe even in case the views will need to be replaced, a significant portion of viewmodels will stay.

  • [ ] Cleanup of used Windows API functions — only use what is allowed for the UWP API partitions

Started yesterday — memory mapping has already been ported to the FromApp functions which don't support executing and writing the same pages simultaneously in a73592c2ef050ea4ee31eb9100bb075fdfe7dc92. There are some other FromApp functions though, but recent headers have wrappers for desktop names of certain functions, possibly with UWP's security requirements.

Platform #defines for different API partitions / device families are another story, by the way — these are even more complicated than Xbox Live/Xbox Game Pass subscriptions :)

  • [ ] Windows.Gaming.Input

Polling-based just like XInput, though also has connection/disconnection events. Seems not to have controller number lights (though needs some research), instead each controller is associated to a Windows.System.User, which isn't very helpful though. Another issue is that unlike XInput which takes 4 of whichever devices were connected, and those may be steering wheels, flight sticks, etc., Windows.Gaming.Input exposes different types of devices through different arrays, and we'll have to merge them somehow without giving priority to some types of devices over another (unless the Xbox 360 does that), including when Xenia is started with input devices already connected, thus probably (but haven't checked) not receiving the connection events for the existing devices. Gamepad keyboard input also needs some research, though it isn't even properly supported on Xenia with XInput yet.

  • [ ] Overall event-based application life cycle

Xenia's entry point architecture was designed to run a main function from the beginning to the end of the process, with a xe::ui::Loop created (that for some reason also works in a separate thread) by the OS-agnostic entry point. All this needs to be revisited, at least (as a quick change) to split the entry point into initialization (accepting the OS-specific context — not sure what it would contain on UWP, but for something like the ANativeActivity* on Android — as an argument) and shutdown, with the xe::ui::Loop created by the OS-specific initialization function, that would probably asynchronously receive events from the OS-specific application code.

  • [ ] Application suspension

When the OS asks Xenia to be suspended, we'll need to somehow more or less safely (with regards to synchronization primitives) suspend all game threads, and also stop doing anything in the emulator until resumed.

  • [ ] Environment integration

Xenia should use the default directories for everything it writes, maybe separate depending on what the OS provides (haven't done research on this yet — but on Android there are separate data and cache directories, for instance, and it would be more suitable to place the shader cache in the cache directory as it may be cleared separately without touching the saves/configuration through Android settings). Maybe logging should also be disabled by default, as the data directory's purpose is unlikely to include that.

Currently the minimum supported Windows version to run an UWP version of Xenia would be 10.0.17134.0 (1803) since it offers a way to map memory at a specified address, which is necessary to map the physical memory of the Xbox 360.

When the OS asks Xenia to be suspended, we'll need to somehow more or less safely (with regards to synchronization primitives) suspend all game threads, and also stop doing anything in the emulator until resumed.

Am I right in thinking that this will also be related to xenia crashing on emulator shutdown as I remember someone mentioning this was caused by being unable to force guest threads to stop or something

Thank you for a very detailed response. Most people when i ask these kinda questions. Blow me off, and say, we don’t care, not the main purpose of our app, etc, etc. I guess i can hope, someday. At least the way you have written what needs to be done, there may be others who want to help and contribute, as there may others who wouod like the same thing.

From what i am reading, the series x is pretty robust, with dev mode access, lots of emulators via retroarch can and have been ported over. With playstation 2 in the possible but near future.

Xbox 360 was my fav system, and i am not one of those people who likes to clutter the room with every system. And as i mentioned so many games will never be ported over due to licensing issues.

Regardless, this gives me some hope. It may be hard to get a series x right now. But if the reason it is low priority for you right now is lack of a system, we can probably round up people willing to chip into getting a series x to you. I don’t have one myself, waiting for a 2 tb model. However, If you have ever been to microsoft’s backward compatibility pages, thousands of people daily request games to be ported. If they knew it would be as easy as buying the dev account for their xbox series x, sending over the xenia uwp over to the series x and their 360 image, you would make thousands of people very happy.

Regardless, thank you for the detailed response. You are doing amazing work.

One important factor for running on the Xbox Series X|S is whether they expose the new GPU features, or if they're still on the Xbox One level. While Xenia supports all Direct3D 12 configurations, rasterizer-ordered view support is crucial to GPU emulation accuracy and performance. I don't have a console right now (and I don't have plans to get one because I already have a pretty powerful PC), so I can't check, but the official blog post says "We currently do not have additional features for apps on the new Xbox family of consoles that are not already a part of the Xbox One X", which is not reassuring. However, anything is better than nothing of course (and in the future, Microsoft can possibly expose more functionality if they currently do not) — also considering UWP on Windows PCs provides full Direct3D 12 anyway, so Xbox is not the only potential target.

The reason for being low-priority for me is that I'm currently working on two bigger projects within Xenia (Vulkan and Android), but Android's lifecycle management has some similarities to UWP, and I'll need Android GUI frontend for it as well, so many architectural changes will carry over.

Never say never, as Phil Spencer says, of course — this issue can be considered the central place for discussing UWP porting and tracking the progress.

I believe if you want to have GPU access, when i. Dev mode you characterize the app from application to game, and it opens up GPU features access. At least that's what i have seen on youtube.

I believe if you want to have GPU access, when i. Dev mode you characterize the app from application to game, and it opens up GPU features access. At least that's what i have seen on youtube.

Are you referring to the expandedResources capability? That would allow us to take exclusive access to the console with more memory and processor time available, but it doesn't add new APIs. UWP uses a completely different graphics driver than game titles, and Microsoft needs to update it separately — having RDNA 2 features in the title driver doesn't automatically imply support of anything beyond what GCN 1 offers in the UWP one.

There are hardware constraints, too, in terms of which system resources UWP apps can access. The maximum allotted memory for apps is 1GB, while games get 5GB. Apps can share 2-4 CPU cores and have up to 45% of the GPU. Games can use 4 exclusive and 2 shared CPU cores, but have full access to the GPU.

Only 64-bit (x64) apps are permitted (there’s no support for 32-bit (x86) apps). While apps are limited to DirectX 11, games get full DirectX 12 features.

https://www.howtogeek.com/703443/how-to-put-your-xbox-series-x-or-s-into-developer-mode/

There are hardware constraints, too, in terms of which system resources UWP apps can access. The maximum allotted memory for apps is 1GB, while games get 5GB. Apps can share 2-4 CPU cores and have up to 45% of the GPU. Games can use 4 exclusive and 2 shared CPU cores, but have full access to the GPU.

Yes, that's what the expandedResources capability overcomes. It's still an UWP app though in this case, not a title with all the XDK/GDK functionality.

Gotcha, so you think it is still feasible?

Gotcha, so you think it is still feasible?

Yes, but maybe without ROV if the feature set is still on the Xbox One level.

When the OS asks Xenia to be suspended, we'll need to somehow more or less safely (with regards to synchronization primitives) suspend all game threads, and also stop doing anything in the emulator until resumed.

And that could also be a great feature on its own on any platform. The ability to suspend the current game at any point, dump current status to a file, and load it at a later point to resume playing where we left off, better than any games' checkpoint functionality. (something like in xemu original Xbox's emulator)

Dumping the current status with Windows host kernel objects (or even pthread objects? though not sure) may be a bit problematic though 🤔

I don't see this happening either. Xenia can not be compared to other emulators like that. We do not emulate hardware _only_ (like a VM where suspend and state save to disk is broadly available. The guest clock is abstracted so if we figure out how to safely suspend guest threads, it would be transparent to the guest.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CGWatkins picture CGWatkins  Â·  4Comments

Razzile picture Razzile  Â·  3Comments

Margen67 picture Margen67  Â·  3Comments

thx3ever picture thx3ever  Â·  3Comments

zerr10 picture zerr10  Â·  3Comments