I have started working on porting Libretro to UWP.
So far, I have:
Code is available on Aftnet/LibretroRT on GitHub
What is the best way to contribute back upstream?
eyyy, thatās looking awesome 
Iāll make sure Twinaphex sees this and we can all figure out how to keep things rolling. Great job so far!
Hi there,
great job. I do want to stress that I greatly appreciate seeing this running, and that I am definitely very appreciative of your efforts.
Would you be willing to port RetroArch to UWP instead? I donāt think we really have the manpower or the resources to support more than one libretro frontend upstream, already supporting and maintaining all versions of RetroArch is a mammoth task. Adding a totally separate libretro frontend that we will have to maintain is something we donāt really have the resources for.
The upshot of a real port of RetroArch would be - far more features, etc. We are willing to give you something for this too just to show it is being appreciated and that we arenāt taking your contributions for granted.
First of all, I would like to thank you for your kind words. I am honored to hear you say this.
Rather than any given front end, I thought my contribution could be the WinRT bindings themselves, the supporting code to translate between the C style Libretro API and the WinRT bindings, and work to adapt cores to use them.
Libretro could then start publishing cores as Nuget packages to make it easy to create front ends on UWP. This work would be a stepping stone to porting RetroArch to UWP.
As for porting RetroArch itself to UWP, I have some reservations: RetroArchās UI is geared towards use on a TV with a controller, whereas my goal in porting it to UWP is to create a front end that:
Basically something more like OpenEmu than RetroArch. Of course I would be maintaining this front end on my own.
I want to stress I do not mean the above as a criticism: what the team has achieved is awe inspiring and a key part of preserving gaming history at this point.
So you donāt want to port it? We still need an UWP port and since you have demonstrated your are able to do it, we think it would probably be best if we give you a reasonable amount for this (100 Euros or so) and you could maybe port it for us instead. 100 Euros might not seem like a lot and it probably is pocket change to you, but for an opensource project like us, it is a non-trivial amount. A 100 Euros would probably be the same that we are spending each month on bounties as-is.
I disagree with your opinion about RetroArch. OpenEmu has zero āadvantageā over RetroArch in my opinion at this point, and as to it not being suitable for mouse + keyboard, I think is untrue and that if this is still the case, it wonāt be like that forever. There is zero reason why RetroArch would not be suitable for UWP. And RetroArch has features that would take years of time to replicate in your standalone frontendā¦ And our gamepad/TV centric interface would be best for a platform like Xbox One. There is no reason why LIbretroRT would exclude or negate the need for RetroArch on UWP.
I hope you consider this offer. It is well-intentioned, and it is the most we can give at this point given all our other expenditures this month and the next.
Making your own frontend is fine, too, of course. Libretro and RetroArch have a lot of overlapping goals, and while a separate frontend would not help RetroArch, it grows the libretro ecosystem, and thatās good, too.
A WIMP UWP libretro frontend is something that a lot of people have wanted for a long time. However, Twinaphex is correct, of course, that creating a separate frontend with the features that people associate with libretro is a big job.
Porting RetoArch to UWP is also a huge undertaking, given all the features it contains.
At first glance (and I mean it, this is what I know about the UWP app model combined with glancing at the RetroArch source - I may be wrong), some of the big issues weād need to find a solution for are:
RetroArch would also need to change UI patterns to accomodate being run in a sandbox: instead of browsing through the file system using the built-in UI, weād need to display the OSās native file open window, as that is the only way an app is allowed to access locations outside the sandbox. This is a feature, not a bug, since itās how you guarantee the user is actually giving consent to the app to access a resource.
Quite honestly, I donāt think Iām up to the task of tackling all of the above and more.
This in addition to the fundamental issue, the one which prevents the Libretro ecosystem as a whole instead of just RetroArch from running in UWP or other similarly sandboxed environments: file access while running in the sandbox.
Right now cores expect to be able to access arbitrary locations on the file system, which is not possible when running sandboxed (this is not UWP specific, sandboxing in MacOS works the same way). They take the gameās path from retro_load_game and fopen etc. on their merry way.
The cleanest way I see of solving this is to augment the Libretro API to have file access brokered by the front end, which is what I needed to do to get my app working.
How about we work together on clearing the file access sandboxing issue, which is work that would be needed for a RetroArch UWP port (or to enable sandboxing in MacOS) anyways?
This sounds awesome, I will look into the code and see how to help myself. Thank you guys so much for taking interest into the uwp project
This is really cool to see. Best of luck, and keep up the good work
I want to help so I have two questions:
Is it compilable now? I know it says it has at least one sega genesis core running, but I couldnāt compile retroarch on visual studio?
Where can I find the issues to help with, usually I look in the issues section, but I couldnāt find them here?
Sorry if my question is stupid, I am still a beginner
gamingForEveryone brings up a god point.
Can you compile RetroArch in Visual Studio (I only see makefiles in the source)?
If not, the first course of action would be to migrate them over to CMake and make the Win32 version of RetroArch compile in Visual Studio. Thankfully C and C++ support has improved a lot in recent releases.
There are vcxproj files for various Visual Studio versions here:
I used them, But unfortunately they are not in uwp form. And I have no idea how to convert to uwp, lol.
From what I understood of the code, you are turning each core into its own uwp project inside the solution
Yes we have Visual Studio solutions for several different versions, they are in the pkg/msvc directory in the source.
I have a question, one of the folders in pkg/msvc/ says xbox one and there is a solution for it. What does it do? it doesnāt seem to do anything when I try to compile it
If you are talking about my project, that is exactly what I do.
I also added a couple of callbacks to the Libretro API so that the front end does rom file access on the coreās behalf using UWP APIs
sweet, I am going somewhere
Oh btw, How do you compile your code, everytime I try to compile it using āCreate app packageā, I just get opgl screen
The project with the actual front end is Test