Shmupmame 4.2: Lagless Mars Matrix, Strikers 1945, Galaga 88

[BPzeBanshee]

Hooray!

[DrTrouserPlank]

How is this meant to work? I think I've downloaded this about 3 times before and every time it never runs any of the games I've got, even when they 100% working roms.

Normal mame usually winges about there being a missing ROM or CHD file now and then (not sure whether it's a bad ROM I've downloaded or just the program being an arsehole) but it at least plays some of the games.

You've got a massive list of games in this shmupmame, none of which can you play, and adding roms to the directory makes them appear in the list, but they never work. Is there some instruction on this somewhere?

[1up]

I think shmupmame v3.0b is based off of mame0.99. So in order for the roms to work they have to be the 0.99 romset.

also, what is the lowest spec pc needed to run shmupmame @ 100% with not dips in performance?

[BPzeBanshee]

Like any version of MAME it depends on the game. I've found on my legacy PC (1Ghz Pentium III with nVIDIA AGP card) it runs anything up to the late 90s okay but ESPRade (and especially Viper Phase 1 and up) are pushing it.

[DrTrouserPlank]

This has reminded me why whenever someone suggests using mame to play something I don't even bother.

Mame is 95% fucking around with 5% play time, endless roms that don't work and moronic compatibility problems which can't be fixed unless you have endless resources and knowledge about the roms themselves.

[Matskat]

This has reminded me why whenever someone suggests using mame to play something I don't even bother.

Mame is 95% fucking around with 5% play time, endless roms that don't work and moronic compatibility problems which can't be fixed unless you have endless resources and knowledge about the roms themselves.

Dude you need to chill out.

MAME is super easy, which makes you look like an ass complaining about it.

Someone help this guy out....explain the difference between different versions....herp derp.

(WOAH! This was my 420th post....for all you stoners out there!)

[mesh control]

Mame is 95% fucking around with 5% play time, endless roms that don't work and moronic compatibility problems which can't be fixed unless you have endless resources and knowledge about the roms themselves.

LLOLOLLOL

[FIL]

Mame is only a hassle if you care about getting a complete romset.

[Ed Oscuro]

You've got a massive list of games in this shmupmame, none of which can you play, and adding roms to the directory makes them appear in the list, but they never work. Is there some instruction on this somewhere?

From what you've written it sounds as if you copied some ROMs to the shmupmame directory. This is not necessary. Shmupmame is just like other GUI MAMEs, like MAMEUI or MAME Plus! in that you set up the directories from the menu. Apologies if you've already done this - it's pretty basic. Be sure to use the "insert" option if you have a different folder for CHD images (which is the traditional way of doing things).

Some of the games in Shmupmame might have updated ROMs by now, but not many.

Mame is only a hassle if you care about getting a complete romset.

Point client to torrent, done. It's only a bother if you care about seeding ratios and pruning dead ROMs (but I think this essentially happens automatically anyway). You end up redownloading a lot of data, like a whole chunk for one new 15KB ROM, but it's much better than trying to find new ROMs and replace old ones by going with ClrMAMEPro output or something. ClrMAMEPro might still be useful to make sure you don't have any dead ROMs in your set, but they shouldn't harm anything if the torrent already has all the useless ones pruned.

Speaking of which, that's one thing I like about MAME - it's not filled with tons of completely useless dumps (emulator [F]ixed, [O]verdumps, etc.) that aren't of interest to even the historical emulator community. Those might be interesting to a historian of emulation someday, but to everybody else they're a waste of space and should be gotten rid of. And if those ROMs were provided in the MAME tradition, only the additional bits would be available as a child ROM (requiring the parent ROM). I suppose compressed files can help this, and it is easier to work with whole files, though.

[shmuppyLove]

Speaking of which, that's one thing I like about MAME - it's not filled with tons of completely useless dumps (emulator [F]ixed, [O]verdumps, etc.) that aren't of interest to even the historical emulator community. Those might be interesting to a historian of emulation someday, but to everybody else they're a waste of space and should be gotten rid of. And if those ROMs were provided in the MAME tradition, only the additional bits would be available as a child ROM (requiring the parent ROM). I suppose compressed files can help this, and it is easier to work with whole files, though.

Except for all the mechanical games. Something like 8000 ROMs?

[Ed Oscuro]

Mechanical games in MAME? Do you mean games with wrapped-wire or solid state logic? I don't view those as useless. They might not be as fun as many of the games we have today, but they have their place. Don't get me started on the gambling games, though.

An overdump ROM, as marked by Cowering's Good Tools, is literally wasted space (except perhaps in some weird historical emulation case where you want to see how the original emulator worked, or didn't work, or something). It might be a 1024K file that actually only holds 512K, and any data after the first 512K (or a bit further in, if there's a header slapped on) is literally garbage. I won't criticize the elder dumpers, but you think that it would have been feasible to determine the ROM size from the chips, and then use a hex editor to check the end of the data to see if it was as expected, or to cut it down to size if it wasn't. Remember that a lot of these games were being ripped back when a megabyte could take a long time to download.

Of course, the MSX / PC releases I've seen prove that the PC game release / tagging phenomenon is nothing new. If anything, a group putting a readme or a credits image in with a ripped game is less problematic than a MSX game file hacked to show a demo.

[BPzeBanshee]

MAME's the most complex emulator to set up that I know of purely from the ROM structure, UI (or lack thereof) and version variations. It also has crashing issues on whole branches of nVIDIA cards among various other weirdnesses.

But it's not that difficult to actually get going. Not even Shmupmame is difficult to get going.

[moozooh]

I'd say plugin-based emulators are considerably harder to set up—you have this whole new dimension of choices with different combinations of plugins that may or may not work better for some games with some particular settings on some computers.

[BPzeBanshee]

True, but how many common emulators with plugin methods actually *have* choices? I'm pretty sure PCSX2 has got like 1 plugin for each aspect along with various idiot-proofing methods. Even on ePSXe which does have a few options I was able to get *something* going. Plankytrousers seems to not be capable of even doing that with MAME and for a while there some years ago (read = 2007) even I had trouble.

[AntiFritz]

The only emulator i've used that actually had choices was project 64, had to get special plugins to play conker years ago.

[KAI]

This thing died on me. The "Play" command doesn't work anymore.

[trap15]

Long-bump, but I've released the no-buffer patch on my website now, so it should be easier to find >_>

http://daifukkat.su/2012/08/mame-no-buffer-patch/

[Zeether]

This has reminded me why whenever someone suggests using mame to play something I don't even bother.

Mame is 95% fucking around with 5% play time, endless roms that don't work and moronic compatibility problems which can't be fixed unless you have endless resources and knowledge about the roms themselves.

Please stop being pissed off about everything.

[Tokyo-J]

Please do not flame me for asking. I did not want to read 45 pages worth of posts.

Does this support Ibara , Mushi Futari ETC?

[KAI]

No, it doesn't.

[Tokyo-J]

No, it doesn't.

Anyone know where to get the MAME that supports the newer cave games?

[KAI]

You can find the Slowpokemame V2 here.

[Tigershark]

I am having problems in Windows 7 64 with the 0xc000005 error

I've followed the instructions on your web-site to no avail. Any other suggestions?

[BPzeBanshee]

Update Windows 7. Sometimes updating fixes it or breaks it even more.

Try an older version of ShmupMAME (v2.2 is a performance hog but if you're running Win7 you probably won't notice).

Use MAME Plus! 0.146u4 (or whatever is current at time of reading) instead.

[Pulsewidth]

It seems recent versions of MAME have changed so that DoDonPachi is laggier than in 0.140, even with the sprite buffer hack. However, 0.140 won't compile with recent versions of GCC, and backporting the compile fixes would be a lot of hassle. The easier solution is compiling it in a chrooted Linux distro with an older GCC. I used Debian stable.

First step, install debootstrap. Hopefully it's packaged for your distro already.

Create a minimal Debian stable installation (adjust arch and directory as appropriate):
$ sudo debootstrap --variant=minbase --arch=amd64 squeeze /whatever/directory/ http://ftp.us.debian.org/debian/

Chroot into the directory you used:
$ sudo chroot /whatever/directory

Install all the mame build dependencies:
# apt-get install libgconf2-dev libsdl-ttf2.0-dev libgtk2.0-dev build-essential
This is from memory so maybe I missed some. If the compile complains later you'll need to go back and install the missing ones.
(you might want an editor and unzip and sudo for convenience too)

Add a user so you don't have to compile as root. Probably you're running as user number 1000, and adduser will also create user number 1000. Give it the same username as on your host system. If you're not the same user number inside and outside the chroot you'll have to manually edit /etc/passwd.
# adduser myname

You've set everything up, so exit the chroot
# exit

Unpack the MAME source with whatever patches you use in [chroot directory]/home/[username]. Edit the makefile as desired.

Now install schroot on the host, and edit /etc/schroot/schroot.conf to include a section with your username and your chroot directory. Chroot into it as a normal user:
$ schroot -c sectionname

Build mame (in parallel with -j[CPU cores + 1]):
$ make -j5

Exit the chroot:
$ exit

Check you've got all the libraries used inside the chroot also installed outside the chroot. Probably the versions will be compatible, and the mame you compiled will work outside the chroot too. If not, you'll have to run from inside the chroot, bind mounting /dev inside the chroot so mame can access your hardware, and setting DISPLAY and allowing all local X connection with xauth so mame can access your X server outside the chroot. But if you're using closely related distros, eg. Ubuntu outside and Debian inside, there's a good chance it will just work.

Set up the mame.ini etc. as normal. If you want to live dangerously you can skip all the adduser and schroot stuff and just do everything as root.

[e_tank]

It seems recent versions of MAME have changed so that DoDonPachi is laggier than in 0.140, even with the sprite buffer hack.

really? its been a while since i've used a pre .140 version of mame but i haven't noticed excessive input latency in mame/mess as of late, and i'm pretty sensitive to it. let me ask you, is it just ddp or the mame/mess core as a whole? if you're not 100% certain that it's mame core try running super mario bros in both mame or mess and then try comparing it to something like retroarch (with fceu core) or a properly setup bnes - smb is one of those games that i find excess input latency is very noticable in. if i can float through the game without getting snagged on any bricks or anything then i'm probably dealing with an acceptable amount of input latency.

also what timing options are you running mame with? i use -nothrottle -waitvsync -syncrefresh for most games (including ddp)

also what video card drivers are you using? not catalyst i hope. a while back on one of my machines i had an unresolvable input latency issue with programs that synced to vblank for timing, switching to the open source drivers took care of it for me.

[Pulsewidth]

Lag frames with paused frame advance, no sprite buffer hacks:

0.141
DoDonPachi - 1
Esprade - 2
Guwange - 2
Dangan Feveron - 1
DonPachi - 1
Gradius - 0

0.142
DoDonPachi - 2
Esprade - 2
Guwange - 2
Dangan Feveron - 2
DonPachi - 2
Gradius - 0

Previously some of the old Cave games were laggier than others. Now they are all equally laggy. It's not a core change because Gradius is as responsive as ever.

Timing options I'm using are:
autoframeskip 0
frameskip 0
throttle 0
sleep 0
Vsync forced on in my video driver (xserver-xorg-video-ati)

This setup is necessary for my black frame insertion hack ( http://shmups.system11.org/viewtopic.php?f=1&t=34212 ) to work.

The fact that the responsive games can be changed to be laggy suggests that it might be possible to change them the other way round and have all of them responsive.

[e_tank]

hmm.. i did a very quick diff of both drivers/cave.c and video/cave.c between 0141 and a recent version and i had (which you probably also did yourself i would imagine) and don't think i saw anything other than asthstetic changes. maybe it's a core change that only is affecting some games? i dunno, i'll try and look over the source again for the drivers tomorrow if i have some time but hopefully haze or trap (the experts in this area) will notice your post and maybe can shed some light on this for you.

dunno if it helps but i can also confim that with mame0146 and stepping frame by frame it's 3 frame steps (ie 2) for an update in ddp and 1 frame step (ie 0) for an update in gradius. but i'm too lazy to setup a base system and chroot into it with an older gcc to compile 0141 to confirm your other results, sorry

[e_tank]

i've testing stepping frame by frame in a bunch of games/drivers in mame i can say that while i don't know for sure i'm willing to bet you can chalk this up to mame being inconsistent with how it handles when it takes input and displays its output frame _while_ stepping frame by frame with shift+p, between drivers. i don't know how frame advance works in mame so i can't tell you whether or not this actually results in additional lag while playing, but i can say why:

gradius and gradius 3 respond in 1 stepped frame
famicom/sms/gameboy/pce games respond in a min of 2 stepped frames
megadrive games resond in a min of 3 stepped frames

just doesn't add up to me and at led me to this assumption.

as to why dp and ddp now respond one frame later when stepping with shift+p, i really have no idea. like i said i don't know how stepping with shift+p works in mame but if it's not stopping exactly after a frame is outputted then maybe in version 0141 and prev it was stepping slightly more than one frame? dp and ddp both have some special case settings in the cave driver that i think may affect their timings, but these settings haven't changed between versions 0141 and 0146. but more accurate timings in the components used by the games may have affected how far the games were being stepped between versions of mame.

this is all just an educated guess, since i've never really dug into and tried to understand the program flow that drives the emulation in mame/mess core, so i could be way off on this. but if you wanted to do some tests you could always try adding a large delay of a several or more frames in the area of code where you apply your crt flicker hack and see if you get the same results as you do when stepping frame by frame.

@haze or trap15: does the above sound right, or can you guys confirm any of this for me?

edit: cleared up my explanation for possible difference in stepped frames between mame versions for dp/ddp

[KBZ]

Are there any dependencies for shmupmame? I've been using microxp, and can't get any games to launch. In previous installations, I had a mame32.exe and a mame.exe. Here, I only seem to have mame32p.exe.

microxp is very stripped down, perhaps I'm missing something?

Code: Select all

width 374, height 245 depth 16
set visible area 0-0 0-0
using performance counter for timing ... cycles/second = 3579545
set visible area 80-453 16-260
Physical width 1024, height 768
Physical width 1024, height 768
Physical width 1024, height 768
shutting down after exception 

Edit: Derp, same problem as udderdude. FIX