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

This update should solve all the reported problems with Test 1. (Available both as a full zip and a zip with only changed files).

Notably the Linux and Mac builds weren't being built with optimizations on, and there was an additional speed problem afflicting PowerPC Mac builds, so all of those builds will now run much faster.

Win32 once again builds out of the box and should run more smoothly as well.

scud doesn't appear to work on PPC. No idea if that's expected or not.

I had noticed a few speed hiccups, but I blamed a Flash-ad-laden 9-tab Firefox that I had running at the time. Running a more demanding driver, there was a pretty striking difference...

Model 3 (ironically) has never been big-endian friendly. I'll see if I can track it down. scud should work pretty nicely on Intel though, with the PPC_DRC and all.

A few more, all on PPC -

daytona never seems to get out of its network test
starwars hangs
sonic crashes with an unhandled opcode at game start
srallyc falls over with draw_object: unknown zsort mode!

enduror's sound chip goes mad on game start.

Compiles and works just fine with mingw, no problem (and just a couple warnings). Everything I've tried has run fine, too, a few old, a few not-so-old.

Quick edit.. Daytona did the same networking thing to me too, until I went into service mode, changed it to single, then selected "backup ram clear". (it wouldn't save without clearing backup ram.. might just be how it is; my computer's too slow for Daytona so never bothered with it, but tried it now for benchmarking)

And, both SDL Mame (Win32) and regular Mame u10 (Win32) both die with that "draw_object: unknown zsort mode!" so that's probably just a u10 problem, not SDL.

sonic is probably due to reported big-endian issues with the V60/V70 core.

You're kind of enjoying having an up-to-date MAME on PPC, eh Richard? :shadow:

Yes. I don't play games much any more (time is the fire in which we burn) but yesterday evening I needed a change of scenery!

Thanks for this update!

I'm sure you don't want to get into compiler flags arguments, but I find adding "-mdynamic-no-pic" on mac os x (both ppc and intel) gives a consistent (small) reduction in size and boost in speed on all applications. It removes the ability to use the code in a dynamic library, which isn't useful for MAME anyway.

On my 2Ghz Macbook Pro, radient silvergun is oh-so-close to playable, but not quite. Out of interest, do you know how much slower SDLMAME is compared to real MAME? I might dual boot windows just so I can play it

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.

I run a separate pthread that increments a volatile integer (frame rate) times per second. This works for me, though I doubt it'll win any efficiency awards.

I have one other weird problem. Basically after I quit full-screen MAME, all my applcation's minimise buttons are greyed out, and remain that way until I quit + restart the programs!

You can see this yourself by doing (but lots of other things work)

1) Open Safari
2) Open Terminal
3) Type "./mamepm mslug"
4) wait till you get in-game, then quit
5) all the minimise buttons are greyed out!

I've been trying to track down whats causing this, but I can't find it. I don't think I'm running any unusual programs that could be causing this.

Can anyone else confirm this problem? If not, I'll dig more myself.

4zumanga, it's not happening here using mameg5. All of my minimise buttons stay yellow.

I've tried figuring out what is causing this problem, and I can't track it down myself. I think I'll wait for the next version, to see if that happens to fix it, and then set off on a bisection search to find the line which is causing me problems if it is still there.

I'm definitely not seeing that. I *am* seeing pretty substantial speed boosts on the G5 with the new OpenGL backend though, so once I qualify it on MinGW tomorrow I'll post it for everyone to enjoy.

So, can it still be called SDLMAME if it uses OpenGL instead of SDL?

Instead? It still uses sdl.

OG.

I can see it now...

./sdlopenglxcodemameg5withoptimizations starwars

SDL also provides cross-platform OGL setup & teardown, so you don't have to deal with WGL, GLX, or any of the 3 GL/window management APIs currently available on OS X (4 actually, since it supports GLX too).

Forgive my ignorance, but AFAIK SDL is a graphics library and OpenGL is a graphics library, too.

They serve (approximately) the same purpose, so why use both?

Not quite - SDL is more of an abstraction framework, like DirectX. In the case of OpenGL, while OpenGL itself is portable the details of how you create/destroy a GL window or fullscreen context and get keyboard/mouse events from that window are wholly platform specific. SDL provides a consistent interface for that, and it also provides consistent interfaces for audio, timing, threading/synch, keyboard/mouse/joypad input, file I/O, and CD-ROM access. In other words, you just build your game/emulator and it's pretty much guaranteed to port relatively painlessly.

It's also excellent for people new to graphics/games/emulation because it's generally much easier to learn than DirectX or Xlib or whatever. (The semantics are similar to DirectX given it was originally written to facilitate Loki's Linux ports of Win32 games but not as involved, and there's plenty of sample code around).

Thanks for pointing out the differences between the two libraries.

In what way does OpenGL constitute an advantage when using as a background (I suppose that means final rendering on the screen) in SDLMAME?

SDL only gives you a range of memory associated with the screen you can write into and it will show up. It requires pure software rendering in other terms. OpenGL gives you hardware-accelerated compositing and rotations.

OG.

Ok, now I got it.

Thanks!