Welcome to the new immovable homepage for SDLMAME, SDLMESS, and SDLHazeMD! Feel free to link this page, as all releases will now occur here and the URL will not change.
The latest version is 0.120a. NOTE: if you
previously downloaded 0.120 without the “a”, delete the zip and the extracted
sdlmame0120 folder. This 0.120a is a complete replacement which will build and
work on all supported architectures.
The stable version is (also) 0.120a. NOTE: if you are upgrading directly from 0.117 or earlier, please note that you must delete all .cfg files and re-configure your controllers.
NOTE: I was misinformed. The WolfMAME patches do apply properly to SDLMAME of the same version (WolfMAME 0.119 works with SDLMAME 0.119, for instance). To apply, unzip the 3 patches (wolf119.zip, inpview-12-src-119.zip, and dipports113.zip) into your sdlmame directory and unzip all 3. Convert the diffs to your system’s native line endings with an appropriate tool if you are not building Win32 SDLMAME (I use a commandline utility called dos2unix on Linux), and do patch -p1 < [each patch].diff. I don’t think the order matters.
The latest version is 0.120. Note that this
fully-packaged version is deprecated due to the fast-moving nature of MESS
development, but I’ll update it on integer MESS releases. New in this version:
all the goodies from SDLMAME 0.120a plus PowerMac G3 support (G3 builds will run
on OS X 10.3.9) and the ability to use -resolution in windowed mode to set the
window’s initial size (and of course the usual MESS baseline updates).
Note that the SDLMESS components are an official part of the MESS Subversion repository and the checked-in version there is kept up to date, so that’s the recommended way to get SDLMESS while saving some bandwidth.
The latest version is 0.12a.
- What are these?
SDLMAME is a port of the popular MAME™. There are a few principles that guide it’s development: 1) run on Linux/Unix, Mac OS X, and other SDL supported operating systems with as few changes as possible to the base Win32 code. This means we can track changes faster than larger more conventional ports such as MacMAME, and we also maintain what I call “Firefox compatibilty” where learning a major app only needs to be done once per application, and it then applies across many operating systems. If you can use the command-line Win32 MAME, you already know how to use SDLMAME on any platform you may encounter it on. 2) MAME developers are important. By keeping quickly up to date, we make it easy for people on non-Windows platforms to make and submit changes to the core MAME code, and we offer native implementations of MAME’s multi-window GUI debugger on both Linux/Unix and Mac OS X.
- So what’s it run on?
Officially supported platforms include Linux (any CPU, 32 or 64 bits), FreeBSD (any CPU, 32 or 64 bits), Mac OS X 10.4 “Tiger” (10.3 “Panther” also is known to work but is not well tested) for both PowerPC and Intel. Win32 is also supported, but there’s not much reason to use SDLMAME on that platform, Aaron does a fine job with baseline.
- Great. How do I build it?
Full instructions are included in the SDLMAME.txt (or SDLMESS.txt or SDLHazeMD.txt) file inside the .zip.
- What’s “compile?” Command-line what?
Mac OS X binares are at MAME For Mac, MacSDLMESS (which is also where you can download a GUI for Macs so you can use SDLMAME/MESS without typing), and r0ni’s (G4 binaries). Fedora (Linux) RPMs, including u-releases in the “testing” repo, can be found at Dribble, Arch Linux packages at AUR, Ubuntu packages at Ludomatic, and Win32 builds can be found at ReDump.
- Got any compatible front ends for Linux? OS X?
Yup! I know of several that support SDLMAME on Linux: QMameCat, Loemu, WahCade (which also works on OS X), and XMAMEGUI (which is in Java and should actually work on all OSes). On the Mac, check out MameTunes, EmuLaunch, and MacMAMEInfoX.
- I have a cabinet or otherwise wish to run SDLMAME/SDLMESS on the Linux
framebuffer with no X?
This is now possible. Follow the instructions here, and you’ll need this patch to the SDL library itself (thanks Couriersud!)
- How’s this related to XMAME?
XMAME is not currently under development. SDLMAME may replace it entirely, or XMAME may come back as an extended version of SDLMAME. Either way, the existing XMAME codebase is likely dead (SDLMAME is based entirely from Aaron Giles’ original Win32 code and contains no XMAME code).
- What about MacMAME?
Brad has indicated in a forum post that he is updating MacMAME for personal use but it is unlikely he’ll make another release (in part because Apple has deprecated the Carbon framework used to build MacMAME - it will not be possible to build 64-bit Carbon apps). If you want a solid MAME for the Mac that’s not command-line you can check out MAME OS X.
- Who’s responsible for this stuff?
Olivier Galibert had the original idea and did most of the original port. R. Belmont did parts of the original port and most of the “new” port that you see here for download. Olivier wrote the Linux/GTK+ version of the multiwindow debugger, and Ernesto Corvi wrote the Carbon/Mac OS X version of the multiwindow debugger. Hans de Goede has contributed innumerable cleanups, enhancements, and speedups to the code, and Tim Lindner made the Mac OS X debugger even more pleasant to use. Many great improvements have been contributed by couriersud and Antoine Mine, and at this point almost all of the OpenGL code is by Sven Gothel. QA has been provided by MooglyGuy and Firewave, among many others.
- Is there a message board?
Yes. You can talk about SDLMAME and get help here.
- Performance is really bad in all modes.
First off, make sure the line “SYMBOLS = 1″ in the makefile has a # before it to turn it off. I try to keep it off in release builds, but I need it on in order to diagnose many of problems that are reported and sometimes accidents happen.
- Performance is OK in soft mode but bad in OpenGL mode
This normally occurs with ATI’s video cards and “fglrx” drivers on Linux. If possible, switching to the open-source ATI drivers will greatly improve performance. Otherwise there’s
not much we can do - the problem is on ATI’s end. - I want AdvanceMAME features in SDLMAME
SDLMAME is intended primarily for end users of ordinary PCs, just like the baseline Windows version. It can be and has successfully been used in cabinets (see also the question about the Linux framebuffer above), and I do include patches which make specialized builds easier, but at the end of the day all the monitor-banging effects of AdvanceMAME will not happen in SDLMAME. However, there is now a good opening for a version based on SDLMAME which incorporates AdvanceMAME’s features. Someone (not me) could probably have good success maintaining such a build.
