xenia
xenia copied to clipboard
xenia-project
Port to UWP, Xbox Series X|S and Xbox One
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.
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.
- [x] 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?
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.
Would love to see this still happen because of the new Goldeneye 007 unreleased leak... I would love to play it on my Series X console...
Would love to see this still happen because of the new Goldeneye 007 unreleased leak... I would love to play it on my Series X console...
Yeah maybe in 10 years buddy
This is not really the place for "I want" or "this would be incredible". Comments are for constructive content that may help resolve the issue. For agreeing, please use the reaction emoji.
6ce5330f5f240f7ea5bcd06a49794480a339860a changes the location where CoreDispatcher::ProcessEvents should be called to the more traditional one for UWP apps — the thread that will be performing CoreApplication::Run. Windowed apps of Xenia now receive OnInitialize and OnDestroy callbacks, which may be invoked from UWP callbacks, though I'm still not aware of all the details of that on UWP, but this commit makes communication between Xenia and windowing systems more flexible overall.
Thanks Triang3l sounds promising.
As a side note, i have installed retroarch on series x without putting it in dev mode. It requires the developer to white list the email associated with the xbox account, and then you just need to download the app from a webpage using the built in browser.
I think since the app is running on the main os and not dev side, that perhaps it has access to full resources.
Thanks Triang3l sounds promising.
As a side note, i have installed retroarch on series x without putting it in dev mode. It requires the developer to white list the email associated with the xbox account, and then you just need to download the app from a webpage using the built in browser.
I think since the app is running on the main os and not dev side, that perhaps it has access to full resources.
Agreed, maybe create a core in RetroArch ? It would allow all full resources, just make sure you can load, isos off USB drives...
Porting to RetroArch would be way more complicated than just to UWP as it has its own, custom interface for communicating with everything on the host.
I bet, just an idea. RetroArch on retail mode is not an easy task, to be able to install it. This would give full access to all resources, it's why I suggested it.
Nothing ventured, nothing gained..
I wasn’t suggesting a retroarch port. But dev mode has resource limits as described earlier in this thread. I think if the uwp is white listed for an account running on retail gui as opposed to dev mode, perhaps the 6gb limit and graphics limitations would no longer be a thing.
The resource limits apply only to shared resource access applications — declaring the expandedResources capability in the app's manifest grants it exclusive access to 6 CPU cores, 5 GB of RAM, and full GPU access via Direct3D 12. It's not anything specific to RetroArch, any app can declare that. This is also unrelated to deployment — the developer mode is needed for installing app packages directly without the Microsoft Store. Whitelisting only grants access to the unlisted RetroArch on the Microsoft Store as if you were its tester approved by the developer, because they are unable to release it publicly as console emulators are not allowed on the Microsoft Store.
UWP port is done guys I cant believe it https://github.com/SirMangler/xenia/releases/tag/0.1.0
UWP port is done guys I cant believe it https://github.com/SirMangler/xenia/releases/tag/0.1.0
Ad-hoc prototyped, not done, but that's nice still!