MAMEdev MAME installation script

[GeorgeMcMullen]

See https://retropie.org.uk/forum/topic/19303/installation-of-mamedev-mame/81 for full conversation/history of script development.

This pull request is for a scriptmodule that will compile and install the latest MAMEdev version of MAME. It has been tested with the latest RetroPie on Raspberry Pi 3, Intel based Ubuntu systems, as well as cross-compiling for RPi3 on an Intel based machine. It has also been tested on a Raspberry Pi 0, but due to slow performance (on compiling and execution), it is removed via the rp_module_flags.

Big thanks to @cmitu and @joolswills for their help and guidance during the development of this scriptmodule.

[cmitu]

Big thanks to @mitu and @buzz for their help and guidance during the development of this scriptmodule.

That would be @cmitu and @joolswills on Github.

[GeorgeMcMullen]

Thanks. I edited my comment with the correct names.

[cmitu]

So I gave it a shot at compiling it and it took a really long time to build (on a PC). I didn't hit the 8Gb memory limit, but that may be because I had only 4 CPUs available and make uses just 4 processes.
It uses also a huge amount of disk space ( 2 to 3 Gb ).

Just a couple of observations:

• the sub-folders for art, sta, snap, etc. should be in parent (mame) folder under the system folder. That's what advmame and mame2003 already do (and possibly other mame-derived emulators, but I only have those installed).
• I'm not sure we need another mame system, we already have 5 folders for arcade related emulators (arcade, mame-libretro, fba, mame-advmame and mame-mame4all).

I haven't got a chance to run it yet, but I'll try to give it a go over the week-end.

[GeorgeMcMullen]

Thanks for taking a look, @cmitu .

Some questions:

• When you were compiling on a PC, were you cross-compiling for Pi, or compiling for x32 or x64?
• Do you have an estimate of how long the compilation took? Cross-compiling for me does take about a day on my old PC. Native PC compilation took less time, but I'll have to measure it. Compiling on the RPi 3 directly can take a day, and longer if you aren't cooling it with a fan as the CPU will throttle itself as it gets hot.
• As far as I can tell, advmame.sh creates [art, sta, snap, etc.] in $romdir/mame-advmame/. My mame.sh creates those directories in $romdir/$system/, where $system is defined as 'mame'. Perhaps that $system variable is confusing? Let me know. Mame4all.sh creates the directories in $md_conf_root/$system/, where $system is defined as 'mame-mame4all'.
• With regards to the additional mame system, my only argument would be that fba, mame-advmame and mame-mame4all require different ROM versions, which will get confusing if those versions are consolidated into a single folder. Conversely though, mame-libretro seems to be updated with the more recent versions of MAME, and thus those ROMs should be largely compatible. Perhaps a symbolic link could be used instead, except that then both scripts would need to check for existence before creating the subdirectory.

Looking forward to hearing how running goes. If you're running on a PC, most ROMs I've tried work well, as they would with a standard MAME install. If you're running on a RPi3, I suggest the earlier ROMs from the 80s (like Tron) and the old Coleco Table Top arcade ROMs (which is why I started down this path in the first place).

Thanks again,

- George

[cmitu]

When you were compiling on a PC, were you cross-compiling for Pi, or compiling for x32 or x64?

Just for x86_64.

Do you have an estimate of how long the compilation took? Cross-compiling for me does take about a day on my old PC. Native PC compilation took less time, but I'll have to measure it. Compiling on the RPi 3 directly can take a day, and longer if you aren't cooling it with a fan as the CPU will throttle itself as it gets hot.

Looks like on a i7-7820HQ CPU @ 2.90GHz (4 cores), it takes about 1h, which is not too bad.
You might want to run strip to minimize the binary size, it reduces the size with about 1/3.

As far as I can tell, advmame.sh creates [art, sta, snap, etc.] in $romdir/mame-advmame/. My mame.sh creates those directories in $romdir/$system/, where $system is defined as 'mame'. Perhaps that $system variable is confusing? Let me know. Mame4all.sh creates the directories in $md_conf_root/$system/, where $system is defined as 'mame-mame4all'.

It might be, I just noticed I had arcade/advmame set up with the sub-folders and I assumed it's there where it's stored.

With regards to the additional mame system, my only argument would be that fba, mame-advmame and mame-mame4all require different ROM versions, which will get confusing if those versions are consolidated into a single folder. Conversely though, mame-libretro seems to be updated with the more recent versions of MAME, and thus those ROMs should be largely compatible. Perhaps a symbolic link could be used instead, except that then both scripts would need to check for existence before creating the subdirectory.

You could add mame-libretro as a possible system, and you'll need to update the rompath in mame.ini.

To get the new mame system to display in Emulationstation, you need to add the following lines to platforms.cfg (updating the PR):

mame_exts=".zip"
mame_fullname="Multiple Arcade Machine Emulator"
mame_platform="arcade"
mame_theme="mame"

I ran a few ROMs through and there's 2 things that pop-up

1. You need to add $biosdir to the rompath in mame.ini. Users might copy there the BIOS archives to not clutter the gamelist, so make mame look there also.
2. Is there a setting to Pause the game while the MAME menu is active ? Maybe we can add it as default in mame.ini.

Looks good so far !

[cmitu]

@GeorgeMcMullen Small addition, you probably want to incorporate the advice from mamedev/mame#4953 to resolve a build issue on Ubuntu 19.04 - this issue will probably show up in other derived distros in time.

[GeorgeMcMullen]

Ok, added to platforms.cfg, added BIOS director, and unset the FORTIFY_SOURCE in ARCHOPTS.

I could not find any option to pause the game while the MAME menu is active. Seems that some people would like this option as well and that binding a key to two actions (TAB to menu and pause) does not work consistently. This will have to be taken up separately with the MAMEdev team, which I may do as well.

Still undecided as to the action on the ROM dir/system for mame with lr-mame. I would presume that it is unlikely that someone will have BOTH installed and it may prove confusing as to what is the proper directory for ROM storage. Seems people already have enough trouble figuring out where to put files, as straightforward as it is.

[dankcushions]

build error with current MAME on RPI4 FYI: mamedev/mame#6640

[GeorgeMcMullen]

Thanks! I will have to take a look, though it will take time as I don't currently have a RPI4. Guess it's time to get one. MooglyGuy's comment about disk space should be considered. I had that similar errors when I ran out of disk space a while back. First, check whether or not you have a good amount of space on the device to begin with. In case you don't know how:

df -h .

Also, if you were using my script or a variation thereof, you may want to check if the temporary swap file that was created is still in existence, as it will take up considerable space.

I presume that you're using the latest version of RetroPie also (as it is compatible with RPI4). I have not tested this either yet. My first check would be whether or not it is running a 32bit or 64 bit environment.

Let me know if you're able to make any progress, and I will loop back with any findings I have.

Thanks!

[GeorgeMcMullen]

Hey @dankcushions I saw your note about the build requiring more swap space. Glad to hear that you've made progress on it! I'd love to know what your swap parameters now are, so I can update the script accordingly. Thanks again!

[dankcushions]

these are all the changes i needed for a successful build on pi4, plus some suggestions. haven't attempted to use it yet, so may have some other changes after that!

[dankcushions]

currently this builds MAME + MESS, but I think that going forward it doesn't make so much sense to include MESS within retropie MAME installs, since we call the folders MAME, MESS. please instead use
local params=(NOWERROR=1 ARCHOPTS=-U_FORTIFY_SOURCE SUBTARGET=arcade)
this builds MAME for arcade only (no MESS). Perhaps a MESS module could be added later?

[dankcushions]

the binary name changes when doing an arcade-only target. i changed this to:

    # The MAME executable on 64-bit systems is called mamearcade64 instead of mamearcade. Rename it back to mamearcade.
    if isPlatform "64bit"; then
        echo 'mamearcade64'
    else
        echo 'mamearcade'
    fi

(i haven't tested this on x64, so this is my presumption based on the fact that ARM generates mamearcade)

[dankcushions]

for consistency, use Arcade emu - MAME (latest)

[dankcushions]

I tried this with pi4 2GB (stock speeds), and it was a slideshow (tested puckman and street fighter 2), but was something approaching playable (although not at all tolerable) with the following mame.ini settings:

samplerate 11025
autoframeskip             1

i don't think these should be made the defaults for pi as different games will have different performance, and these do sacrifice quite a lot of visual and audio fidelity, so it's really up to the user.

if you the lower the video mode (from 1080p to 700x400, for me - lower video modes were glitching on my TV), it is suddenly MUCH faster even without those tweaks; full speed for pacman (98.4%), and only a little slow for SF2 (87.95%). it also didn't appear to be maxing the CPU for either - 50 and 60%, respectively. that gives me hope that there's something that can be optimized, here. if you run at full 1080p the CPU usage balloons to 100%. i wonder why a (simple?) video scaling operation is sapping so much performance? tagging @MooglyGuy

i was able to configure my controller via the UI. would be nice to do this automatically, perhaps using a similar method to https://github.com/RetroPie/RetroPie-Setup/tree/master/scriptmodules/supplementary/emulationstation/configscripts. the controller config file, /RetroPie/roms/mame/cfg/default.cfg, is XML which would complicate things.

[GeorgeMcMullen]

Thanks for all of this awesome information. One of the reasons why I had kept it as just MAME and not arcade vs. MESS, was that my original motivation for getting this up and running on RPi was to play all the old VFD/LCD handheld games, along side a couple of very old arcade games, both of which are really only compatible with the more recent versions of MAME.

I agree with your assessment on the video performance. With my own setups I have MAME at a lower resolution (either 320x240 or 640x480). That works rather well with many of the older games on a Raspberry Pi 3. I had tested all the way down to a Raspberry Pi 0, but even at the lowest resolution and most simple games, it runs like molasses. This was even true for the VFD/LCD games, which don't have any video emulation to perform. All the graphics are SVGs embedded with the ROMs, rendered natively by MAME. I went all the way back with MESS v0.166, when they were raster based images and it was still slow.

Then I disabled video output, and performance suddenly was snappy on a Raspberry Pi 0. Unfortunately of course, without video, you can't really play the game, but I could tell by the sound that there was minimal lag in my input and movements to game play. So I believe that CPU emulation, sound, and input are all running well. There must be something in the BGFX video rendering engine that is not optimized for Raspberry Pi, though it seems to be configured to use the GPU. According to https://bkaradzic.github.io/bgfx/examples.html#drawstress the draw performance is pretty low. I wonder if you're able to change the refresh rate to 30Hz and if that would affect performance.

For VFD/LCD games on Raspberry Pi, I believe I have frame_skip set to 9, which doesn't affect game performance all that much. There really isn't any animation on the old VFD/LCD games to worry about. Looking at the MAME documentation, you can adjust frame skip dynamically by hitting F8/F9. Perhaps there's a sweet spot for you.

Another thing to look out for when trying lower resolutions and compatibility with your TV is if your TV is NTSC/PAL compatible. My TV is only compatible with NTSC based resolutions on the lower resolutions.

On a separate note, you may also be interested in lr-mame, which is one of the experimental packages. That may help with the configuration of your controllers.

I'll go through and review your other comments on the code suggestions, though it will take a little more time. Thanks again!

[dankcushions]

Thanks for all of this awesome information. One of the reasons why I had kept it as just MAME and not arcade vs. MESS, was that my original motivation for getting this up and running on RPi was to play all the old VFD/LCD handheld games, along side a couple of very old arcade games, both of which are really only compatible with the more recent versions of MAME.

i think for the MESS side, i think it should be a separate module since a) the compile times are so high and b) 'MESS' roms don't make sense in the 'arcade' or (arguably) 'mame' folders. i see our lr-mess module seems to add folders for a subset for MESS-supported systems: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-mess.sh#L49 - i don't think that's practical with the 100s of systems MESS supports. i would suggest a catch-all 'mess' folder. @joolswills do you have a view?

[GeorgeMcMullen]

Thanks @dankcushions I'd be interested to hear the perspective from the RetroPie team as well.

@dankcushions , how long was the compile time for MAME with only arcade enabled?

I'll take a look at the lr-mess module to see how it manages the ROM folders. Most of the recent ROM archives seem to encompass both the MAME and MESS archives in a single folder.

I guess there could be three modules, MAME, MESS, and then MAME+MESS.

[GeorgeMcMullen]

Some interesting performance of BGFX on RPI4:

https://www.raspberrypi.org/forums/viewtopic.php?t=264207

[dankcushions]

@dankcushions , how long was the compile time for MAME with only arcade enabled?

approx 8 hours

Some interesting performance of BGFX on RPI4:

idk if this is strictly relevant as it seems MAME is sapping CPU simply upscaling an image. no 3d or shaders as far as i can tell. is it BGFX or SDL2 MAME uses to render main image to screen? whichever it is, it seems like it's not utilising the pi's GPU correctly. perhaps not being compiled with the right flags?

[GeorgeMcMullen]

I did a little playing around with the options to see if I could figure out how MAME is rendering video on the RPI and it looks like it's not using BGFX (in fact, I couldn't even force it to use BGFX). By default, it seems to use an internal software renderer and then outputs that to SDL2. I did though see a little performance boost by using the following option:

-video accel

Would you mind trying it on your RPI4.

When I enabled the OpenGL drivers (with KMS and Fake KMS) using raspi-config, I unfortunately didn't see any performance boost, and it had some bad side effects otherwise (Emulation Station didn't run).

Side note: I've been reading that there is a new RPI4 1.2 that has some fixes in terms of USB and performance. Do you know which one you have? Of course, I'd love to see MAME run smoothly on all RPI versions, but it might be useful to know if there is a difference.

[dankcushions]

I did a little playing around with the options to see if I could figure out how MAME is rendering video on the RPI and it looks like it's not using BGFX (in fact, I couldn't even force it to use BGFX). By default, it seems to use an internal software renderer and then outputs that to SDL2. I did though see a little performance boost by using the following option:

-video accel

Would you mind trying it on your RPI4.

this is the eureka moment! with this option pacman and sf2 are full speed with no frameskip and full sample rate! this is great GREAT news! i can't wait to see what else current MAME can handle.

so, with that in mind, i think we need it to be:

    addEmulator 0 "$md_id" "arcade" "$md_inst/${binary_name} %BASENAME% -video accel"
    addEmulator 1 "$md_id" "$system" "$md_inst/${binary_name} %BASENAME% -video accel"

however, i think we should have this for rpi only (if isPlatform "rpi"; then) is we can't guarantee what's best for other platforms.

what's also curious is that there are other options for this that may end up being even faster: https://docs.mamedev.org/commandline/commandline-all.html

-video <bgfx|gdi|d3d|opengl|soft|accel|none>

i will carry on my investigation and benchmark these. will return with findings.

[dankcushions]

ran about 1 min of each game and then looked in the runcommand.log for the performance

--video bgfx is a non-starter due to this error:

Executing: /opt/retropie/emulators/mame/mamearcade -video bgfx "sf2"
../../../../../3rdparty/bgfx/src/glcontext_glx.cpp (82): BGFX 0x00000002: Failed to query GLX version

i don't know if this is worth fixing, but i would imagine it's fixable.

Option	puckman	sf2	donpachi	ddp3	tekken2
accel	96.21%	99.85%	99.99%	50.70%	50.11%
opengl	99.00%	98.58%	100.00%	50.70%	50.13%

i think some of these are clearly CPU bound so it doesn't matter what the graphics are doing. i didn't bother testing --video soft as that is apparently the default, and we know how bad that is.

so, on balance, it seems opengl may be a LITTLE faster. i tried again on puckman and got 99% with opengl, 99% with accel. it probably doesn't matter what we go for but i would guess that sdl2 uses opengl ultimately anyway, so maybe opengl cuts out the middleman, i don't know...

[GeorgeMcMullen]

Wow that's awesome! I'd been reading about improvements to the OpenGL driver for V3D (the GPU on the RPI4) in Buster (see https://www.raspberrypi.org/blog/vc4-and-v3d-opengl-drivers-for-raspberry-pi-an-update/). Looks like it has resulted in some definite improvements. I'm going to do some additional tests on a variety of devices (Pi3, Pi0), with Buster to see if there are improvements across the board.

There is a config option for the video parameter in mame.ini. The script edits this configuration (configure_mame), so I can add the option there (detecting for RPI vs. Intel). It will probably be easier for users to modify that if they need to vs. the EmulationStation config files.

I'll have to poke around SDL2 to see what "accel" is actually doing. Perhaps it is using OpenGL?

Side note: I may have found a small bug in MAME with the accelerated mode. If you experience issues running MAME on subsequent multiple runs, that may be because it might not be closing out the display properly. I'll be running some tests with a fix on that as well, but that not affect this script.

[GeorgeMcMullen]

So I did a little bit more research with a clean RetroPie 4.6 / Buster install. It looks like on RPI 0/1/2/3, OpenGL is disabled (set to Legacy, non GL desktop driver. Thus trying to run mame with -video opengl exits as it's unable to open the display.

On an RP4, it's enabled by default. This is probably because of the recent work to update the driver.

I tried to enable it on my RPI3, but upon reboot, Emulation Station doesn't load. I can run Mame with -video opengl, but it doesn't seem to provide much more of a boost from -video accel.

I'll have to take a look at SDL2 and see exactly what it's doing there. Must be some kind of magic. I also need to do some tests on a RPI0. Very curious if that will provide a performance boosts.

Something else that might be interesting to try is enabling pixel doubling on your Pi. It's more of an accessibility feature, but I wonder if it can offload some of the scaling as it probably is performed natively in the GPU. I also read that it can make the system unusable if you don't have a high resolution monitor, so make sure you're able to SSH into the device (or edit the config.txt on the SD card) just in case.

[GeorgeMcMullen]

Quick question for @dankcushions, can you run mame with -verbose? And post the output for the following:

mame -verbose [game name]
mame -verbose -video accel [game name]
mame -verbose -video opengl [game name]

It should show some info on how it is rendering, and if using SDL, what SDL flags are enabled. I've found that running default still uses the SDL accelerated renderer, but when I add -video accel it adds an additional flag for SDL_RENDERER_TARGETTEXTURE. In both cases, it looks like the SDL_RENDERER_ACCELERATED is also enabled. So I wonder what SDL is doing with the TEXTURE rendering. It also says it's using opengles2 as a renderer. I also tested with my RPI 0, but didn't see any significant performance increase. Oh well.

Here's a section of my output using -verbose:

Leave sdlwindow_init
Enter sdl_info::create
Leave renderer_sdl2::create
window: using renderer opengles2
renderer: flag SDL_RENDERER_ACCELERATED
renderer: flag SDL_RENDERER_TARGETTEXTURE

If you are looking to have some additional fun, perhaps you might want to look at specific compiler flags that might optimize things further, check this out. I'm going to see if these help at all.

https://gist.github.com/fm4dd/c663217935dc17f0fc73c9c81b0aa845

[cmitu]

If you are looking to have some additional fun, perhaps you might want to look at specific compiler flags that might optimize things further, check this out. I'm going to see if these help at all.

https://gist.github.com/fm4dd/c663217935dc17f0fc73c9c81b0aa845

Specific system compiler flags are added automatically by the setup script, when installing from source. They're set here.

[GeorgeMcMullen]

Awesome. Thank you @cmitu ! I could have sworn I saw processor specific flags somewhere, but wasn't finding it in the MAME repo. I should have looked in the RetroPie repo.

There are a couple of minor differences though I don't know the effect:

• On RPI1/2, the setup script is still using -mcpu, which is evidently deprecated but probably still available
• On RPI3/4 the setup script doesn't use -mneon-for-64bits, but I believe Raspbian is still a 32-bin OS

[joolswills]

-mcpu is not deprecated on arm.
use -mneon-for-64bits is deprecated for GCC 10. But it's not an option we want anyway imho. It's not an aarch64 specific option though.

[GeorgeMcMullen]

Thanks @joolswills and @cmitu

While we have your attention, do you have any opinion on @dankcushions idea of having separate MAME vs. MESS script modules?

[cmitu]

IMHO should be just one module that installs the binary and maybe a 'shallow' module that configures MESS (which relies on the MAME scriptmodule to install the binary).

Since MESS supports a myriad of systems, it's not practical to auto-add all the systems when installing it, so maybe have a GUI (implement gui_mess) that toggles systems and creates the configuration (if needed) and ROM folders.

[joolswills]

Funnily enough I was thinking about a GUI for the libretro mess. But yeah I agree with @cmitu

[joolswills]

The older Raspberry Pi's cannot do opengl on the closed source driver. Just opengles.

Which is why performance is probably bad using opengl as it will be software rendered.

Probably best to use gles on all.

[GeorgeMcMullen]

Probably best to use gles on all.

There's no option for opengles/opengles2 with -video, only [none, soft, accel, opengl or bgfx]. When using -video accel on my devices (RPI 0, 3, 3+), the renderdriver is set to opengles2. Setting renderdriver to opengles (not opengles2), performs worse, of course.

According to @dankcushions logs, when using -video accel on the RPI4, it sets the renderdriver to opengl automatically.

[cmitu]

Maybe with -renderdriver opengles2 -video accel you can select GLES2 (instead of OpenGL) ?

[GeorgeMcMullen]

@dankcushions would you be able to try the above options as @cmitu suggests and let us know how it performs? Also, try running it with and without verbose. I believe running in verbose mode hampers performance as it's trying to update the console. Thanks!

[dankcushions]

on a pi4:

-renderdriver opengles2 -video accel

Enter init_monitors
Adding monitor screen0 (1920 x 1080)
Leave init_monitors
Enter sdlwindow_init
Using SDL native texturing driver (SDL 2.0+)
Loaded opengl shared library: <default>
...
Leave sdlwindow_init
Enter sdl_info::create
Leave renderer_sdl2::create
window: using renderer opengles2
renderer: flag SDL_RENDERER_ACCELERATED
renderer: flag SDL_RENDERER_TARGETTEXTURE

-renderdriver opengles2 -video opengl

Enter init_monitors
Adding monitor screen0 (1920 x 1080)
Leave init_monitors
Enter sdlwindow_init
Using SDL multi-window OpenGL driver (SDL 2.0+)
...
Leave sdlwindow_init
Enter sdl_info::create
OpenGL: Broadcom
OpenGL: V3D 4.2
OpenGL: 2.1 Mesa 19.2.0-rc1
OpenGL: texture rectangle supported
OpenGL: non-power-of-2 textures supported (new method)
OpenGL: vertex buffer supported
OpenGL: pixel buffers supported
OpenGL: framebuffer object supported
OpenGL: GLSL supported, but disabled
OpenGL: max texture size 4096 x 4096
Leave renderer_ogl::create

it also says Setting SDL renderdriver 'opengles2' ... but given the above, i guess it doesn't matter.

benchmarks with above:

Option	puckman	sf2	donpachi	ddp3	tekken2
accel	99%	99.2%	100%	51.37%	50.11%
opengl	99%	98.58%	100%	50.7%	50.08%

same for both. for simplicity i think we should use -video accel for all platforms. it seems to use opengl over gles if available, but there doesn't seem to be an appreciable difference between the two so i don't think we need to micromanage it.

[GeorgeMcMullen]

Thanks @dankcushions ! Seems for simplicity's sake we should make it -video accel for all RPI platforms. I couldn't find any concrete information about how the different video, renderdriver, and videodriver parameters interact. Hopefully we'll get more data as time goes on and other people start to use it. I've committed the change.

[dankcushions]

thanks, but ALL platforms, not just rpi :) according to the docs, if set it will use SDL2's 2d acceleration "if possible" which should always be an improvement on linux, and presumably falls back to 'soft' if not possible.

[GeorgeMcMullen]

thanks, but ALL platforms, not just rpi :) according to the docs, if set it will use SDL2's 2d acceleration "if possible" which should always be an improvement on linux, and presumably falls back to 'soft' if not possible.

I was looking at the MAME source code trying to figure out how video/videodriver/renderdriver are all interconnected. There are some specific Linux flags which I'll check to make sure I don't break anything. Also will do some testing on my Ubuntu system to see how X11 and SDL acceleration interact.

[GeorgeMcMullen]

So evidently, MAME on x86 Ubuntu will use opengl as default, but not use OpenGL texture rendering. When using the video accel flag, it will then use OpenGL with textures. I agree, until I can find information on why it should not be enabled on all platforms, I've removed the check for RPI.

[joolswills]

Thanks for your work on this. I'm happy to merge. I may tweak it a bit later but looks good to me. Thanks.

[GeorgeMcMullen]

Awesome! Thank you very much! I'm looking forward to it getting merged and seeing what tweaks you add to it.

Thank you @joolswills @cmitu and @dankcushions for all your help, guidance, and feedback on the script!

[cmitu]

You should squash the commits into a single one, it's better for merging/history.
Thanks for the contribution!

[GeorgeMcMullen]

Thanks. Hmmm. I tried following these directions, but seems like it didn't squash the commits into a single commit. https://gist.github.com/longtimeago/f7055aa4c3bba8a62197 Still looking into it.

[dankcushions]

i use this method: https://stackoverflow.com/a/5201642

[GeorgeMcMullen]

Thanks @dankcushions that did the trick. Much better.

[GeorgeMcMullen]

Hi @joolswills and @cmitu

I noticed that in a recent commit for lr-mame there is a getDepends call for libgles2-mesa-dev / libglu1-mesa-dev.

I checked on my RPI3+ with Buster and found them already installed. Was wondering if you'd want those lines copied to my mame.sh script.

Otherwise, I've squashed all the commits into a single commit. Thanks!

[joolswills]

Thanks for your work on this. I may tweak a few things, but looks good. Cheers.

[GeorgeMcMullen]

Awesome! Thank you so much. Just updated my RetroPie install and I see it in my list of experimental packages. Beautiful!

[joolswills]

Just to note I built rpi binaries for buster (rpi2/3/4).

[GeorgeMcMullen]

Wow! Awesome. Works like a charm. Thank you!