it’s off-topic for this thread, but what issues do you have with the MAME core?
Well i will say i haven’t tried it in about 6-8 months but last time a lot of the ‘hotkeys’ MAME uses conflicts with some hotkeys RA uses, the RA core has 1-2 more frames of input lag than the standard commandline MAME release, and setting up folder structures and stuff like getting MAME bezels to work etc.
It nothing major just makes it more of a hassle to use instead of the commandline release of MAME…which just works
The hotkey conflict is essentially unavoidable, since MAME has a bajillion hotkeys and so does RetroArch. If you need to use MAME’s hotkeys, though, you can always use game focus mode in RA to pass all keyboard events to the core.
The extra lag thing turned out to be not really a thing, AFAIK, and was based on differences in how input is handled in a pause+frame advance situation. I don’t think RA is any faster (esp now that MAME have added their low-latency option; bgfx used to be a couple of frames slower before that, IIRC), but it shouldn’t be any worse, either.
Bezels/artwork, config inis, etc. can be loaded through the MAME structure that the core creates in the ‘saves’ dir (EDIT: see GemaH’s post below for more details), but the artwork will look low-res and chunky that way. We do support loading MAME artwork/layout files at full res with the GL driver’s “video layouts” feature now, but we don’t support automatic loading by game title (yet).
By all means, use whatever you like and works for your needs/setup–and there are a couple of things that don’t work in the libretro core, such as the debugging interface for some reason (console/MESS loading does work just fine, despite rumors to the contrary)–but the core is in pretty good shape these days.
2 Likes
The MAME native artwork and ini folders must be in the System/mame directory to work, not the saves folder. I think you have to manually create them. I use the regular MAME artworks in many games with no low res issues this way.
In the Saves/MAME folder you get the cfg, diff and nvram folders.
3 Likes
Thanks for the info. Other than MAME 2003 Plus is there any plans to have a fork of up to date releases of MAME than support the ‘run ahead’ feature?
PS. Sorry to get off topic
No problem, I split it off 
Runahead has some very strict requirements for savestate integrity that are apparently difficult to impossible to achieve with MAME, and I think, based on some public comments, that they’re philosophically opposed to the concept, so it’s not likely they’ll make any changes in that direction any time soon.
I’m not sure f BizHawk could add runahead in tandem with their “waterbox” savestates, but if so, that might work, since it’s not reliant on the cores’ own savestate integrity.
whats waterbox savestates, as ive not heard of this!?
I don’t know the details, but apparently it’s saving the state higher up in the chain (I guess maybe like the states you can save with a virtual machine…?), so the core doesn’t even need to be aware of what’s going on.
1 Like
[FYI]
Apparently the linux x86_64 mame core on buildbot dated from 2019_12_01 is broken:
Compiling it from actual source (last commit 2019_11_17) results in a working core.
Can this be fixed? Thanks in advance.
Hmm, I just did a fresh pull with a self-compiled RetroArch and it worked fine. It didn’t work with the snap package, though, due to a libc version incompatibility. Is that what’s happening here, by chance?
Was it measured ? Is it global ? From time to time i see people telling fbneo-libretro has the same input lag than mame-libretro, does that mean fbneo-libretro has those extra frames over standalone too ?
1 Like
I can’t speak for emersonnovais, but this is what i get:
OS: Linux Mint 19.2 x86_64 Linux 4.15.0-72-generic / Cinnamon 4.2.4
Retroarch: PPA libretro/testing (Git version: 643b3a7 - Build date: Jan 2 2020)
core size = buildbot = 293,7MB vs self compiled 359,9MB
(by comparison 0.212 buildbot core = 316,4MB)
[ERROR] (only the part that differs from working core)
retroarch: relocation error: /home/user/.config/retroarch/cores/mame_libretro.so: symbol _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev version GLIBCXX_3.4.26 not defined in file libstdc++.so.6 with link time reference
I get the same error.
It’s never been measured, AFAIK, except with the frame-advance method. That is, using RA+mame-libretro with RA’s frame-advance vs RA+mame-libretro’s own internal frame-advance and/or mame standalone’s frame-advance. The first one (RA+mame-libretro with RA’s frame-advance) took an additional frame to respond vs the others, but that was just related to the way the frame-advance affected the held input state as it was passed to the core. It doesn’t exist in actual usage.
2 Likes
seems MAME is compiled with a newer gcc than what ubuntu comes with. I had to add this ppa :https://launchpad.net/~jonathonf/+archive/ubuntu/gcc-9.0?field.series_filter=bionic and then do an update, and MAME now work
3 Likes
Ah, yeah, upstream made some changes that require building with gcc98…
It still compile with gcc-8 here
Sorry for not understanding correctly:
The problem was with the mame_libretro.so from buildbot already compiled.
Makes switching to a new compiler necessary to update for the “end-user” as well?
I don’t know how to spell it comprehensible in english, do the “end-user” needs the compiler installed for the compiled binary to work?
You need to just upgrade to gcc-9-base, that’s what I did.
Mame “current” seems to be version 229 still (230 was released about a week ago). I thought current Mame core was in sync with the standalone? Was something changed? v.230 had some nice updates in Hyper Neo-Geo 64 games btw.