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

I don't know anything about what flags are and aren't optimal for the Mac, so if you do I'm glad to hear about them. And I have no idea at all about SDLMAME on OSX vs. Windows MAME on the same hardware - there's a few too many variables there. SDLMAME is typically less than 5% slower than "native" MAME on the same OS & machine (e.g. SDLMAME vs. MacMAME on OS X or vs. MAME on Win32).

The exception is Linux where X11 itself is really the limiting factor (and which SDL is arguably best-optimized for, although the Win32 target has improved almost astronomically in the last 2 or 3 SDL releases).

BTW, -fomit-frame-pointer is usually a small win on Intel, might be on PPC too.

PS: I have OpenGL working for vector games now. Atari Star Wars and Asteroids at 1600x1200 with hardware anti-aliasing are a near-religious experience, you're gonna love it

Just out of interest, does sdlmame store any setting outside it's own directory?

I tried messing around with a bunch of things, and eventually got things in a horrible mess, and just deleted my source tree + started again.

On the most recent test version, if I just type:

"./mamepm mslug"

Then I find the music "catches" quite a lot (it's quite obvious on the first level, it often goes "mission one one start" and the music catches every so often. If I run it in a window and type "top", I see that mamepm is maxing out a CPU. Surely metal slug shouldn't do that?

I have a 2Ghz Macbook pro

EDIT : I had run mamepm with -nosleep. If i add -sleep back, then I get exactly the same problem, but now only ~60% CPU usage.

It'll look in $HOME/.mame/ for .ini files if it doesn't see any elsewhere.

Hmm.. no, I've tried clearing that out, and I'm still getting this "echoing" effect. I actually seem to be getting it in all games (at least in bublbobl, pacman and mslug). It sounds exactly like the music is "getting ahead" of the game.

Ah ha! I think it's a throttling issue.

If before I run mame, I type
nice yes > /dev/null &
nice yes > /dev/null &

Then everything behaves well and I don't get any jumping. I didn't trigger the bug before because I was converting a huge number of mp3s in the background over several hours.

EDIT : I just checked as a sanity check, and neither Genesis Plus or BSNES have the same problem. Of course that might just be because they have different CPU requirements.

Without really having much idea of what I'm doing, I hacked ticker.c and undefed X86_ASM, so that the SDL would be used for timing.

That smooths things out nicely, but it might produce a drop in performance, on my computer:

./mamepm-sdltime -nothrottle -frames_to_run 500
Average FPS : 51.5ish

./mamepm-x86time -nothrottle -frames_to_run 500
Average FPS : 58ish

Ahh, yes! Most newer x86 CPUs vary their clock speed to reduce energy usage/heat/etc but the side effect is that the time measured by the x86 RDTSC instruction goes all wobbly. In MAME it tends to manifest as the sound going weird for whatever reason. I need to make that an option, and investigate if gettimeofday() works on OS X. Or maybe Bannister knows something more native-y that'll work. Just some kind of timing API that returns milliseconds or microseconds would be fine :-)

I quickly tried some of intel versions of Richard's emulator conversions and they don't show the same problem. I was going to go and have a look for the relevant code, but I'm sure he will probably be able to provide it before I can

I had a quick look around, and found mach_absolute_time(), which I include <mach/mach.h> and <mach/mach_time.h> to get. It doesn't seem to provide any substansal improvement over sdltime, I'm still getting that slowdown.

I'm somewhat suprised any timing function could produce that much slowdown, I assume it must be something else which is causing the effect...

Actually it may not be slowing down as much as it says (or even at all) - the FPS counter does not read out accurately when RDTSC is fluctuating. On my laptop I've had it show 30 FPS when the game was running clearly too fast (ie, more than 60).

Incidentally, Intel fixed RDTSC on some of the newest Pentium Ds so it's always steady even when the chip is variable-throttling. It'll be nice when that fix propgates through all their chips.