Mesen Core


#1

After being asked several dozens of times if/when I was going to port Mesen to libretro (and seeing a lot of people saying it couldn’t be done because “lol C#”), I finally got around to doing so. It barely took a day (and less than a thousand lines of code), so now I’m left wondering why I didn’t get it done earlier :slight_smile:

Anyway, as of the latest commit, Mesen can be compiled for libretro (see the repository’s readme for info on how to build it). I’ve tested it on Windows with VS2017 (x86 & x64) and Linux on Ubuntu (x64 only) with both clang and GCC. It has no external dependencies, but it does require a C++14 compiler that supports the Filesystem API (which is C++17 I believe). On Linux, clang with LTO enabled tends to produce the fastest binaries. I imagine it could be compiled relatively easily for a lot of other platforms as well (just a matter of having access to a relatively recent compiler for the platform).

The core more or less supports everything Mesen itself does, including HD Packs - which means you can now play this neat Megaman 1 HD pack in RetroArch! (must be in system/HdPacks/romname/ folder) I also added options for most things that made sense in the context of libretro (ntsc filter, palette, overclocking, etc.), but if there is anything missing from the standalone version that would be useful, let me know. Some of the inputs supported by the standalone version are not currently supported in the libretro port (e.g: power pad, etc.). The most popular ones should all work (standard controller, zapper, and some more).

Performance-wise, it is most likely much slower than both FCEUmm & Nestopia UE - I would be surprised if this was able to run at full speed on a Rasberry Pi, for example (but you never know). It should be able to run at full speed on actual PCs, though, even relatively old ones. Compiled with VS2017 and using PGO to optimize the core, it runs roughly the same as the standalone version on my computer (around 350-450 FPS depending on the game).

I think I’ve ironed out most/all of the bugs I found - there are still a few rare issues on my end, but this might just be RetroArch itself acting up (hard to tell - I’ve never used it until now). Please let me know if you have any issues with it. Also, the only Linux environment I have is a VM, and RetroArch refused to run in the VM until I turned off hardware acceleration for it - so I have no idea how well/fast it runs on there.

EDIT: The core is now available on the buildbot, so you can download it from RetroArch


#2

Holy crap, man, that’s awesome! I’m super-excited for this :smiley:

Definitely possible. If you get stumped by anything, feel free to ask. We’re on IRC at #retroarch on Freenode and there’s a libretro discord server. You can also ask anything here and I’ll make sure it gets to the right eyeballs.


#4

Thanks!

For now, I think I’m mostly done (bug fixing aside). Eventually I might try to add support for some of the other input devices - but since some of them are full keyboards that require 80+ key bindings, I might have to limit them to stuff that people are actually going to use (e.g power pad, etc.). Beyond that, I might try to strip down the code for the libretro version to reduce dependencies some more - it just occurred to me that core has references to winsock & sys/socket (because of the core’s own netplay implementation), which isn’t ideal and could be removed very easily.

If you have any issues compiling it, let me know - aside from sockets, I’m fairly certain it has no other OS-dependent dependencies though, so it shouldn’t be too hard to compile.

Also, the core is currently compiled with need_fullpath = true. The header file suggested setting this to false, but Mesen’s core expects paths as strings (with a special syntax to refer to files inside of archives) for a number of reasons, so it was a lot simpler to implement this way. How big of an issue is it for need_fullpath to be set to true?


#5

It’s not a big deal. Many cores do it for the same reason. I think we’re working on being able to replace it in most cases with a filestream/VFS thing, but it’s still in-progress, so probably not worth worrying about it now.

The main thing that need_fullpath = true affects is softpatching, which isn’t a big deal, IMO, though there’s a guy on reddit who hassles us about it regularly.

We’ll send you PRs if we come up with anything that helps with the libretro-ization. For example, I think there’s a pretty simple way to hook up keyboards without mapping every key manually, so if we get something like that going, we’ll send it your way. :slight_smile:


#6

Thank you for your dedication!

:fist_right:t2::fist_left:t2:


#7

An already very complete core, even in beta !


#8

I’m trying to make a “libretro makefile” since building with solution files is a no go for our buildbot I’m almost there after a bit of struggling, but I still get this with both clang and gcc

../Utilities/FolderUtilities.cpp:4:10: fatal error: 'experimental/filesystem' file not found
#include <experimental/filesystem>
         ^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [<builtin>: ../Utilities/FolderUtilities.o] Error 1
make: *** Waiting for unfinished jobs....

#9

What versions of GCC/clang are installed?
I use clang 3.8/3.9 and gcc 5.4. If you’re using older versions, it’s possible the C++17 Filesystem API is not supported by them. If you’re using more recent versions, it’s possible you might need to remove the “experimental” part of things and compile with C++17 (e.g: --std=c++17) instead of C++14.


#10

I’m using msys2, seems they don’t have that filesystem stuff built in though (Windows)

gcc version 7.2.0 (Rev1, Built by MSYS2 project)

clang version 5.0.0 (tags/RELEASE_500/final)

Seems filesystem relies on some posix stuff that may or may not work

So it isn’t compiled in… darn

Well we have makefiles for MSVC too maybe @bparker can make one :stuck_out_tongue:


#11

The filesystem usage is limited to 5-6 small utility functions in that single file - it would be relatively easy to replace them with their equivalent OS-specific APIs (but I used the filesystem API in the first place to avoid OS-specific APIs as much as I could, to simplify porting the code to other platforms).

The FolderUtilities.cpp file originally used the Win32 API before I ported Mesen to Linux: https://github.com/SourMesen/Mesen/commit/8439290896480b3657d929b4a53c61a1154c08f4#diff-7936527c5f959bd42291f841bd797d2b

Edit: Also, assuming the build bot is running on Windows, and you have VS2017 Community installed, compiling from command line is extremely easy. e.g: “C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.com” Mesen.sln /Build “Libretro|x64”


#12

Thanks, we’ll try to figure something up Do you use discord?

Would you mind if we replaced the filesystem stuff with our filestream API in a fork? I’d like to deviate as little as possible from upstream, and actually we try as hard as possible to not have any file I/O on cores (but most cores still do their own I/O anyhow).

Most of the RA/LR devs hang out here nowadays:

Maybe you can join us to discuss alternatives?


#13

Really cool! The only real problem I have is that the sdl2 and D3D video drivers don’t work properly. SDL2 just crashes and D3D is really really slow.


#14

This is awesome news, thank so much for this.


#15

And another thing, is it normal that there is an 1 pixel thick line at the bottom when NTSC filter is enabled?


#16

This might not be a bug but, I also noticed that the Mesen core is too quiet compared to the other cores.


#17

Not sure if I have something wrong or not but it seems that any patched rom breaks controller support. This means any English translations or rom hacks the controller just doesn’t work in the game itself, the roms load just fine and I can use my controller to get to the quick menu and change settings but in game nothing.


#18

@Flooder
I’m not sure what would cause specific backends to crash and not others, since that’s not something the core is managing.

The NTSC filter issue looks like it is a Mesen bug in general - seems to have appeared in 0.9.3, I’ll take a look, thanks! For the sound, that’s the same as the default setting in the standalone build. Maybe worth adding a volume option? I think the FCEUmm core has one as well.

@lordmonkus
That’s probably a game DB related bug. It might be (incorrectly) setting all the inputs to be unplugged instead of using standard controllers - I’ll take a look. (Ideally which input to connect in each port would need to be an option, atm it relies on the game DB to select the correct types, so can’t use a zapper on a hacked rom, for example)


#19

Hopefully it’s an easy fix because so far I am loving this core very much, greatly appreciated.


#20

This is amazing, Mesen is possibly the most advanced NES emulator. Together with Retroarch with its convenience, shaders, retroachievements support and possibilities for porting to multiple platforms this could turn out to be the definitive way to play NES.


#21

FYI, the red line in the NTSC filter, low sound volume & input not working on games not in the game database should all be fixed.
At the moment, waiting to see if the buildbot actually finally manages to build it - if it does, the core should show on there with the fixes eventually.