GroovyMAME Core?

Is there any chance of porting the GroovyMAME build of Mame to RetroArch at all?. It’s really probably the best version of Mame and fixes numerous historical problems that vanilla Mame has always had.

For instance here are a few things it improves upon vanilla Mame…

No screen tearing No audio stuttering Reduced input lag Smooth scrolling Correct refresh rates More accurate resolution selection algarythems

Those are all frontend improvements that are already handled by RetroArch, so it wouldn’t really have any greater effect than the existing libretro-mame cores, which have: no screen tearing, no audio stuttering, reduced input lag, smooth scrolling, etc. The refresh rate and resolution switching stuff is really intended for use on CRTs, while RetroArch is fundamentally geared toward modern displays (everything expects 60 hz and a consistent external resolution imposed by the display instead of imposing the game/system’s resolution on the display). Obviously, you can make RetroArch work just fine on a CRT, but it will be with a single resolution (I use 1920x240, which covers most but not all horizontally oriented games).

1 Like

Ah ok thats great i wasnt aware that RetroArch fixed these issues.

Will the Mame button configs be correctly mapped, as i have noticed that RA seems to have issues where mame is involved where buttons for a pad would bring up the mame menu screen, show fps, alter frame skipping etc??

Currently, the MAME core(s) is/are setup to have their button-mappings jump around on certain drivers to make them more usable on gamepads, but this can be awkward/confusing for people with abnormal setups. Radius is working on adding a core option to make them stay at the default mapping all the time.

You can use multiple resolution and refresh rates modes with RetroArch, just put them into separate configs and load them with command line args or from Configurations on the menu to switch to those modes. There’s no provision for automatic switching, you’ll just have to do it manually on a per-game/system basis.

The rate control that RetroArch does should keep scrolling smooth and audio stutter free when the refresh rate of the game is less than 5% different from your display’s now that the MAME core is reporting an accurate refresh rate to RetroArch, which allows it to adjust 57Hz to 63Hz to sync to a 60Hz display refresh rate. The Audio Maximum Timing Skew option lets you set a higher or lower ceiling for adjustment, for example 0.17 lets you sync 50Hz PAL to a 60Hz display, but it will have an inaccurate audio pitch and will run a bit faster since that’s a large adjustment. Be sure that your video_refresh_rate setting is accurate to your display’s actual refresh rate or else this might not work correctly, there’s a built-in refresh rate estimator in the menu that’s very accurate after 2048 samples that you can use set it accurately.

The best thing to do is create a few configs with custom resolution/refresh rate modes with a few common arcade refresh rates for stuff like 55Hz and let the rate control adjust the game’s refresh rate as needed to those modes. That way, there’s no need to set separate modes for something like 55.018Hz and 55.47Hz, since both can be adjusted to 55Hz with very negligible differences in audio pitch or speed.

Resolution switching on CRT’s is mostly unneeded if you use the superwide modes that hunterk suggested, as most in-game resolution switches happen on horizontal only and the superwide resolution lets RetroArch scale them accurately with the large number of horizontal pixels, which appears normal on the CRT due to how their deflection circuits work. Only case this doesn’t cover is when the vertical resolution changes, but that is very rare outside of PlayStation games that switch between 480i and 240p, which 31kHz CRT monitors can handle with a 480p mode and the shader.

1 Like

Revisiting this again, as Groovymame has large improvements in input latency thanks to the frame delay setting thats been implemented into the latest few versions of GroovyMame, with as little as 10.75ms…