The NEW Build Your Own Arcade Controls
Software Support => GroovyMAME => Topic started by: shbon on November 12, 2024, 01:54:56 pm
-
I’ve just started investigating GroovyMAME to see if it can improve my existing MAME cab setup (which currently uses a modest CPU/GPU combination), in terms of smooth frame delivery and input lag.
My current setup is MAME 0.271 on Arch Linux / X11 / BGFX - Vulkan (vulkan-intel 24.2.6) or OpenGL - GLSL (mesa 24.2.6). The computer (i5 8th Gen / UHD 620) doesn’t support G-Sync / Freesync, but the LCD I use is Freesync capable.
I set custom refresh rates (CVT 1.2 Reduced Blanking) using https://github.com/kevinlekiller/cvt_modeline_calculator_12 (https://github.com/kevinlekiller/cvt_modeline_calculator_12) and xrandr on the LCD before launching MAME:
mame <rom> -waitvsync -video bgfx -bgfx_backend vulkan (+ a CRT shader and some portaudio settings...)
This setup gives tear-free video and (mostly) stutter-free video/audio and well sync’d audio.
I’m aware of two issues:
1. I believe I’ve got two separate clocks running, one for the game throttle and one for the v-blank wait. Monitoring with MangoHud, the frame delivery is pretty smooth and consistent but I can see a frame rate glitch every 30 secs or so, presumably when the phase shift between the two clocks gets critical and a v-blank is missed?
2. I’ve probably got additional input lag from using waitvsync and (maybe) using BGFX too.
Now I know the correct answer for my setup is just get a new computer that supports VRR and run standard MAME with -lowlatency :banghead:, BUT I wanted to see if I could use GM to squeeze any more efficiency out of my current setup. So I’ve installed the latest GM Linux release.
My questions:
1. I assume that the following config is the minimum that I actually require to get GM running properly with my setup?
monitor lcd
lcd_range 40.00-120.00
modesetting 1
(I seem to need -modesetting otherwise switchres creates the custom refresh rate with xrandr but doesn’t apply it...)
2. I notice in the logs that GM sets both -waitvsync and -syncrefresh (as part of -autosync). Monitoring GM with MangoHud, I still seem to get the same frame rate glitch every 30 secs or so. Is this expected behaviour? (I had assumed that GM ‘fixes’ MAME’s -syncrefresh behaviour: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=312#p312 (http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=312#p312). Maybe that doesn’t apply to MAME/SDL?)
3. With the default -video opengl, the frame delivery also seems less consistent than I’m used to seeing via MangoHud. For a 60.606061 Hz game, it does average 60.6 Hz / 16.5 ms but the 1% / 99% can be 57 Hz / 64 Hz. On my current MAME / BGFX setup I often see 60.6 Hz and 1% / 99% of 60Hz / 61Hz. Is this also expected behaviour?
4. With -autosync -frame_delay 0 and -video opengl, how does GM’s theoretical input lag compare to MAME with -waitvsync -video opengl on Linux?
5. I understand that -video bgfx will only work with GM and -frame_delay 0 (https://forum.arcadecontrols.com/index.php/topic,164449.msg1732267.html#msg1732267 (https://forum.arcadecontrols.com/index.php/topic,164449.msg1732267.html#msg1732267)), but how does GM’s input lag with -autosync -frame_delay 0 -video bgfx compare to MAME with -waitvsync -video bgfx on Linux?
6 . With -frame_delay [1-9] and -video opengl (and no shader), in brief testing, I couldn’t determine whether anything had actually changed and there’s no evidence is the (-verbose) logs either. I do think playing a game (e.g. bgaregga) ‘feels better’ but it might be placebo! Can I assume that if GM is running OK at -frame_delay 9 that the appropriate input lag reduction is being applied?
7. With -frame_delay 0 and -video opengl and a CRT shader I get obvious stuttering, even though I can’t see any CPU/GPU bottleneck and the same GLSL shader applied in my MAME setup runs comfortably. I assume then that GM needs quite a bit more CPU/GPU headroom over MAME, even with -frame_delay 0? What’s the main extra processing that GM is doing?
Thanks for reading.