MAME 0.144 for Mac OS X

[CMPXCHG8B]

[deleted]

[BPzeBanshee]

I kind of beat you to it and got hold of the download just before the edit. Works fine for me on my 10.6 32-bit machine from '08. In fact I could've sworn there was some kind of performance improvements in terms of speed (but then I was playing one of the Cave SH3 games whose driver you hadn't removed) compared to the Windows version.

Are you going to go like the SDLMAME website and only issue 64-bit releases for the u-interim builds?

EDIT: Can someone confirm if Guwange Blue's stage 5 boss is meant to expand to something horribly pixellated when he goes Hulk-style? I've played against him in MAME with original, and in Blue on the port and I swear he hasn't done that before. Not sure if it's something to do with this release or the "Raiden II" team not noticing it in the year or so that they had it to themselves.

[CMPXCHG8B]

[deleted]

[BPzeBanshee]

That must be a 64-bit processor then. Some older Mac systems don't boot a 64-bit kernel, but since the CPU is still 64-bit compatible, they can run 64-bit applications just fine (which can address +4GB of RAM). This all has to do with XNU/Darwin and PAE, and is far too technical to explain here.

If it's a Core 2 Duo or any of the Mac Pros, then it's 64-bit. There is absolutely no way that build would have ever ran on a 32-bit machine, because there was no 32-bit code. Everything was 64-bit, including the DRC (dynarec) backend). I just confirmed that with lipo, the libraries and app are x86_64...

Either way, I've edited the original post to include a universal build. Details are above.

-CMPX

Well holy shit, you learn something new every day. I was absolutely certain this was a 32-bit model for quite some time now until you said otherwise and upon a bit of "iMac 8,1" search and "E8235" (model of Mac and CPU) I got this. Thanks for the heads up!

This thing only has 2 GB though which considering the architecture was a bit lame but oh well. If there was anything more specific you wanted me to test with for this I'll gladly try and help where I can, the only issue being the stupid price requirements for Xcode if I'm to compile stuff on OSX (which I thought was meant to be free but finding where to get it from Apple always leads to a developer purchase scheme page).

[CMPXCHG8B]

[deleted]

[BPzeBanshee]

Excellent! Looking forward to future progress with this!

Is this eventually going to be ported into MAME's default source somehow? And will stuff like MAME Plus! diffs and such be able to be applied to it to give the extra functions that the respective forks have?

I'm not really familiar with this side of compiling and programming myself, but if the internals of it are so radically different maybe you should personalise it a bit? XCODE-MAME has a certain ring to it.

[CMPXCHG8B]

[deleted]

[BPzeBanshee]

Is this eventually going to be ported into MAME's default source somehow?

I highly doubt it, if R. Belmont's response to my inquiries on mameworld about a potential Mac port (read: Cocoa-ized native Mac application) were any indication. The general attitude was that I should be building a front-end, not another "doomed to fail" powered-by-MAME application. Though I would love nothing more for the MAME guys to actually contact me one day and say "Hey, we'd love to host your binary on our website as an official Mac version".

From what I've heard of him, R. Belmont's head really does deserve to get chopped off at times, but I'm sure if you keep at it you'll teach him a thing or two.

And will stuff like MAME Plus! diffs and such be able to be applied to it to give the extra functions that the respective forks have?

The what?

I'm not familiar with these "diffs". Are you referring to code diffs (created by diff, applied with patch) or something else? I manage my MAME collection entirely by hand, and I don't use frontends. Hell, I don't even know what clrmame is or what on earth it's supposed to do.

Oh, I meant like additional stuff like MAME Plus! features. I'm a bit unfamiliar with the specific terms myself to be honest.

I'm not really familiar with this side of compiling and programming myself, but if the internals of it are so radically different maybe you should personalise it a bit? XCODE-MAME has a certain ring to it.

Actually, the only difference is the way it's assembled. The end result should be the same since I haven't changed anything internally (yet). Once I get CLANG/LLVM 3.0 compiling the code properly (that'll be interesting), then there will likely be some huge differences in the way the code is assembled and organized (which may or may not impact performance in a positive or negative way- I'm going to find out in either case though), but you'd only know that if you were staring at the disassembly.

Theoretically, what I want to do (probably in the new year or late December) will strip out all the SDL code and replace it with wrappers for Objective C (and Cocoa) equivalents. It will also involve gutting a fair portion of the core emulator code as well since I want to replace bloody well everything- input configuration, machine configuration, jumper selections, anything you get when you mash [TAB] in-game, etc. At that point most of what will remain will likely be relating to the CPU cores, sound cores, machine hardware, and drivers. All the front-end and operational stuff will go Mac native.

The best way to explain what I want to do is analogous to what Alun Bestor did for Boxer (boxerapp.com). He took DOSBox (dosbox.com), an x86 DOS emulator (which works kinda OK on Mac) based around SDL- gutted the majority of everything relating to user interfaces, input, etc- then built his own app around the core of DB. The result is Boxer, and it's an awesome product- I'd highly recommend it. He touts Boxer as "Powered by DOSBox", and I'd like to morph my little project into something "Powered by MAME". R. Belmont might disagree, but I see no other way to produce a tightly integrated and highly polished Macintosh product.

-CMPX

This sounds like a very good thing for Mac users. Surely if you're going to rip out several parts of the core though won't it become difficult to keep in sync with newer changes that happen further down the track? (sorry for the stupid questions btw)

[Stormwatch]

Protip: use the old MacMAME as the model for your interface, not MAME OS X.

For example, the Esc key made the game pause, not close; for that you had to use Cmd+W, I think. That was different from the original MAME, but it's what you'd expect from a Mac application. And that's an important thing: when you make a Mac application, make it look and behave like a Mac application, damnit! And that goes for any operating system: all of them have their own interface guidelines, and if you don't respect them, your application feels alien to the system - the sign of a lousy, inferior port.

Also, make everything accessible from the menu bar. Say, if I want to freeze a game's state, or change the frameskip, or activate some filter... I want to find it all there, rather than having to remember which unusual button combination does this and that.

[CMPXCHG8B]

[deleted]

[Barrakketh]

I have yet to see a compiler that doesn't assume .c is C and .cpp is C++.

I think GCC actually expects cc instead of cpp. Even if you pass something like -std=c++0x (which is obviously for C++) it won't use the same flags or link against against the C++ libraries, leading to lovely errors like this if you assume otherwise:

Code: Select all

test.o:test.cpp:(.text+0xf4e): undefined reference to `typeinfo for char const*'
test.o:test.cpp:(.text+0xf56): undefined reference to `__cxa_throw'
test.o:test.cpp:(.text$_ZN4nall6substrEPKcjj[__ZN4nall6substrEPKcjj]+0xc): undefined reference to `__gxx_personality_sj0
'
test.o:test.cpp:(.text$_ZNK4nall13xml_attribute5parseEv[__ZNK4nall13xml_attribute5parseEv]+0xc): undefined reference to
`__gxx_personality_sj0'
test.o:test.cpp:(.text$_ZNK4nall11xml_element5parseEv[__ZNK4nall11xml_element5parseEv]+0xf): undefined reference to `__g
xx_personality_sj0'
test.o:test.cpp:(.text$_ZNK4nall8optionalIjEclEv[__ZNK4nall8optionalIjEclEv]+0x14): undefined reference to `__cxa_rethro
w'
test.o:test.cpp:(.rdata$_ZTIN4nall11xml_elementE[__ZTIN4nall11xml_elementE]+0x0): undefined reference to `vtable for __c
xxabiv1::__si_class_type_info'
test.o:test.cpp:(.rdata$_ZTIN4nall13xml_attributeE[__ZTIN4nall13xml_attributeE]+0x0): undefined reference to `vtable for
 __cxxabiv1::__class_type_info'
collect2: ld returned 1 exit status

The solution, of course, is to use g++ directly instead of treating gcc as a front-end.

[BPzeBanshee]

Oh, I meant like additional stuff like MAME Plus! features. I'm a bit unfamiliar with the specific terms myself to be honest.

What features do they have? I'm having a remarkably hard time figuring out: A) the actual project webpage, and B) what the heck it does over anything else. I know what I want, but I have no idea what anyone else wants, so if there's something specific worthwhile to point out- I'd love to hear about it.

After reading what you said and Googling it myself I had problems with it too. There's a lot of deriatives and varied builds of it that's for sure. I mentioned MAME Plus! because Shmupmame makes use of it as a base for having custom autofire buttons among other things (so I'm told), and newer versions have got video settings and stuff within the TAB screen.

Other people have been nagging for stuff like the hiscore.dat and the patch that removes the copyright nag screen for builds of MAME posted in the Too Close For Comfort thread. I was just curious if any of this was actually possible with this Mac project since it sounds like it's going to be so radically different in the internals that it might not work or even be required.

[Zaarock]

I know what I want, but I have no idea what anyone else wants, so if there's something specific worthwhile to point out- I'd love to hear about it.

Autofire options? I can't think of any MAME usable on OS X where you can set up autofire on the emulator itself.

[MR_Soren]

Sounds great, I will download this tonight. Thanks!

[CMPXCHG8B]

[deleted]

[waxfang]

Oh thank you thank you thank you...downloading now!

Happy Turkey Day!

edit: tried messing with this to see if I can get it to play nice with a front-end in the meantime til there's a GUI (MacMameInfoX works with vanilla 0.144 for me), is there any way to take the mame binary out of the Package Contents and have the front end point to that? Not a big deal, just comes in handy for erryday use.

I tried various combinations of the MAME file + dylibs which Terminal says are missing when I try to create the list XML, but I think the whole thing is [obviously] coded to work with that package, and not as a binary, right?

Either way, don't mind me. Awesome work!

[CMPXCHG8B]

[deleted]

[waxfang]

Awesome, will give that a shot, can't believe I didn't think of that. Either way, it's certainly no big deal to use MAME's menu, just a little kludgy with large libraries.

Either way, frigging awesome work. About time the Mac stops being a second class citizen as far as (non-NES/SNES/Gen) emulators go.

Also, FWIW off the top of my head, I got Futari 1.0, all versions of Pink Sweets, and ESPGaluda 2 up and running with little to no slowdown on a relatively ancient c2d iMac (2.4/4GB RAM/256MB Radeon/10.6.8 ). I keep getting ROM/CHD errors on the others (Deathsmiles, Futari 1.5, etc), but that's my problem, obviously.

[waxfang]

OK, just pulled the "Contents" folder out, and it worked like a charm!

If anyone wants to do this -
Install & run MacMameInfoX - http://www.vastheman.com/download/macmameinfox.php

Exit MacMameInfo, then right click on CMPX's MAME.app bundle, then Show Contents.

Option-click and drag the contents folder to MacMameInfo's folder that it creates in your Documents folder (makes a copy just in case you decide to go back).

In the prefs, point to the mame build inside the contents folder and rebuild the game list XML.

Worked without a hitch on mine, and now you have a GUI in the meantime...I kinda hate MMinfo's storage scheme (puts cfg files in your library/application support, roms/etc. are in that directory in Documents, etc.), but it seems to be the most stable/headache-free front end I've found, and doesn't look like a cobbled together windows app, a la M+GUI.

[null1024]

I keep getting ROM/CHD errors on the others (Deathsmiles, Futari 1.5, etc), but that's my problem, obviously.

It's just naming issues with those. I can't remember what I renamed to what [MAME was looking for one name like "u3-asdf", and the zip had something pretty similarly named like "u3.asd" or something, so renaming the similarly named files made it work].

Take note that those aren't the actual names.

[waxfang]

Yeah, I figured that out last night when I audited them -- there were a couple u2/u4 files that just needed to be renamed gamename_u2/u4, and other than some checksum errors when re-checking them, they seem to work fine.

[TheSoundofRed]

Am I missing something? I don't see a download link in the first post. Would love to give this a shot.

[BPzeBanshee]

Am I missing something? I don't see a download link in the first post. Would love to give this a shot.

I'm guessing he pulled it for some reason. I for one would like to see this again too.

[CMPXCHG8B]

[deleted]

[BPzeBanshee]

Well that certainly seems fair enough. I for one am glad the project is on hold rather than dead. Here's hoping you had a Merry Christmas too.

[CMPXCHG8B]

[deleted]

[Lloyd Mangram]

Drools in anticipation.

Soooo looking forward to this.

Happy New Year!

[scrilla4rella]

Drools in anticipation.

Soooo looking forward to this.

Happy New Year!

me too. All I have is my powerbook, I feel so left out if the mame party

[CMPXCHG8B]

[deleted]

[scrilla4rella]

Ahh, sorry, I meant Mac Book Pro, practically band-new