Libretro port to UWP

General Development
#5

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.

1 Like
#6

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.

2 Likes
#7

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:

  • Plugins don’t work the same way: you can’t just execute binaries you acquire after installation - RetroArch does just that to load cores
  • Networking: what API are you using for network communication? If not Winsock, I’m afraid we’d need to rewrite the network stack
  • Rendering: are you rendering RetroArch’s UI using DirectX? OpenGL? Vulkan? To make RetroArch work in UWP we basically need to render to a SwapChainPanel, even if we don’t want to use XAML for the UI.

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?

#10

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

2 Likes
#11

This is really cool to see. Best of luck, and keep up the good work

2 Likes
#15

I want to help so I have two questions:

  1. 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?

  2. 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

#17

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.

#18

There are vcxproj files for various Visual Studio versions here:

#19

I used them, But unfortunately they are not in uwp form. And I have no idea how to convert to uwp, lol.

#20

From what I understood of the code, you are turning each core into its own uwp project inside the solution

#24

Yes we have Visual Studio solutions for several different versions, they are in the pkg/msvc directory in the source.

#25

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

#27

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

1 Like
#28

sweet, I am going somewhere

#29

Oh btw, How do you compile your code, everytime I try to compile it using “Create app package”, I just get opgl screen

#30

The project with the actual front end is Test

#34

The “Xbox1” folder is for the original Xbox.

1 Like
#35

We don’t want or need cmake for anything. I consider it a net negative to using it, not a positive. If you design stuff intelligently, you don’t need anything more than plain Makefiles for most things. Cmake/ninja/genie is all a solution in search of a problem, we don’t need it and we won’t be jumping on that particular gravy train bandwagon anytime soon (read: never).

The MSVC projects all use Griffin, manual solution maintenance is not an issue for them. Look into what Griffin is and you will see why.

I don’t think we need to talk here about our build system, though, that is of no concern here.

#36

If you tell me that Visual Studio solutions are automatically kept in sync with the makefiles that is good enough for me. I just need to be able to use Visual Studio to work on the project if I take it on.

I’m actually leaning towards helping you port Retroarch: growing the Libretro ecosystem to include UWP is a good thing.

A few things I want to ask:

  • Does it mean UWP becomes a supported platform on par with Win32 for cores too? Will Libretro maintain and publish UWP binaries for cores the way it does for Win32 going forward?
  • Are you OK with extending the Libretro API?
  • Are you OK with me helping you do the port then work on my own front end? My end goal would be to eventually use the prebuilt UWP core binaries for my own project
#40

Umm, just to make a couple of things clear -

For MSVC builds, we build with C++, however, the source code is still predominantly C.

I don’t want even more C++ code. I already detest the few parts that are in C++ to begin with and the plans are to get rid of that at a certain point in time if we can. I want C code.

C#? No way, don’t want that either.

The issue is that we will have to maintain this code after the person who wrote it is gone. More C#/C++ code is not stuff I want to maintain, period. I don’t want it and it’s not going to happen. It would have to be written as C code instead that can also be compiled in C++ mode, just like the rest of RA’s codebase.