Home Page Forums MAME Non-Windows MAME Support SDLMAME 0.106u10 now available

Your eyes aren't deceiving you - that\'s really u10 , which just came out a few hours ago.

In addition to all the core additions in u10, this edition of SDLMAME adds support for the new rendering system, support for PowerPC Macs (only tested on Tiger), and support for Windows (although in that case you're ahead to just use Aaron's official version).

Frontends are still needed, especially on the Mac. Anyone? :-)

While trying to build SDLMAME for Mac, I encountered an error in xmlfile.c. Coincidently, I'm getting the same error while compiling xmame: the compiler is unable to find expat.h because it is included as a system header (<expat.h>). Changing it to "expat.h" fixes it.

After that, building stops while trying to link file2str. I tried to comment that out from the make file, but then I get all sorts of other errors.

This is on my Intel iMac. I will try to compile it on my Titanium Powerbook later in the afternoon.

Oh, for Mac builds you need to uncomment both BUILD_EXPAT and BUILD_ZLIB normally. Try that. I'm checking out the actual distribution on my Intel Mini right now.

Also, unless Apple patched it, GCC 4 doesn't enforce <> vs. "" anymore - they do the same thing.

Yeah, that did it.

Thanks!

One other note: make -j2 is much faster on dual-core /multi-CPU systems (on my Core Duo Mini it's close to a real 2x speedup) but the makefile's not totally SMP safe so sometimes it won't build chdman or something. A quick plain "make" will take care of that.

Sorry, I don't understand: will that speed up the compilation by 2 or the emulation?

Also, here are five observations I made that I hope you'll find useful:

• SDLMAME runs fine (albeit slow) on my iMac G4 and uses the new interface font
• SDLMAME runs great on my Intel iMac, but still uses the old user interface font (but it is somewhat anti-aliased)
• on the Mac side, CHD files are in a special folder ("Hard Disk Images"). I believe that on the Windows side they reside along all the other ROMs, as I'm unable to find a config file line where to indicate a folder containing my CHDs. Is there any way to make SDLMAME look in the appropriate folder?
• could the inclusion of expat and zlib compilation be conditionalized in the makefile if one sets the architecture to macosx?
• when starting PPC SDLMAME, the emulation window immediately gets focus; when starting Intel SDLMAME, you'll first have to click in the emulation window so that key strokes are sent to SDLMAME (this could however be a consequence of different setups/versions of the SDL library or my two Macs)

Outstanding work, thanks a lot!

Automatically forcing EXPAT/ZLIB on macosx is totally possible, and a good idea. (You may have noticed that PPC builds automatically force the X86 DRCs off regardless of the user setting).

That (make -j2) speeds up the compilation only. The font should be the same in all instances, but it does look pretty blocky if you manage to get 320x240 full screen (my Mini doesn't support modes below 640x480, although it partially makes up for that by having a ton of options above that). I think you'll find if you force a higher resolution (or play a higher-res game) on the iMac the font will look like the new one.

As far as CHDs, they're supposed to be in a folder with the game's ROM name inside the ROM path. This is a fairly recent thing - the PC used to allow more flexible placement of them. (I expect when Brad gets MacMAME updated it'll be somewhat more strict as well). I was considering making the default configuration more MacMAME-friendly, but the config files are just so different even from 0.103 now that it would cause more trouble than it solved.

I will look into possibly having a separate CHD path though.

I finished compiling SDLMAME for Win32/mingw and thought I'd share my experience.

(I do understand a Win32 user is better off with the regular build, and SDL is for testing.. I just figured I'd give it a shot.. Not looking for help, just wanted to mention what happened. I do understand that the idea of SDL is portabilty, and figure SDLMAME's target audience is Mac/Linux...)

It compiled just fine, only a few warnings, but trudged through. I didn't save the output, but should have. Perhaps the warnings were in fileio.c, come to think of it.. Anyhoo..

However, the binary wouldn't find roms anywhere.. It would open up the window (or screen) briefly; the time was dependant on the size of the rom. (larger roms would show the percentage longer as if it were loading more) With a zipped rom in the folder, it would tell me the zip was corrupt (but same zip would work fine with regular mame) and list the files it couldn't find. Unzipped and just in a folder, it wouldn't tell me the zip was corrupted (sort of obviously), but still listed the files it couldn't find.

I recompiled, substituting src/sdl/fileio.c with src/windows/fileio.c from the regular mame and it worked just fine, finding roms no problem. I had a look at the sdl/fileio.c and tried a few things, but nothing I hacked around with helped.

Building with the included makefile on my Debian Etch (x86) system results in:

However it builds and works fine if I add -lX11 to the link line for the mame binary.

Interesting. Ok, I'll add that.