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

[TransatlanticFoe]

This had been running fine on my Win 7 64 bit machine for over a year but as of today is now inexplicably throwing the error which has been doing the rounds. Pah.

[Bee Cool]

Yea, it's been working about once a week for me.

[dmauro]

I'm having a lot of trouble getting v3.0b working on my cab. It wants to run at the desktop resolution despite going into default game options and using either "auto" or explicitly setting a resolution. I would love some help from anyone that has managed to get these looking arcade perfect in a cabinet.

I got bottom paged and could really use some help. I just can't seem to get it to respect any changes I make to the video options.

[dmauro]

Hmm, simply re-downloading seems to have fixed the problem of not being able to change the settings.

The sound seems really weird on ESPGaluda, does anyone have any tweaks to get the sound a little better?

[BPzeBanshee]

I bump the volume up. It's "improved sound" compared to what's in the newer builds of MAME so there's not a lot you can do about the sound being different because there's a different driver.

Not sure about the video options. If you're able to get it going with other builds I don't see why it'd be that much different with the exception of what tab the settings are in.

[Ed Oscuro]

Well, this is odd. I used to think "boy I don't see any lag anywhere" to now seeming to notice it everywhere. Dunno what's going on.

I played Dangan Feveron (I always though it was Dangun...but yeah it's not) and did some input lag tests with Ship A - both slowest and fastest speeds gave 3 frames to reverse direction, which wasn't too terrible as far as it goes. But it didn't seem too playable either. Of course, I wonder if it isn't possible that I'm stretching my data bandwidth with the other stuff I have running - that might not show up in a controlled input lag frame skip test, but would still spike now and then. Every now and then I seem to notice a ship not responding to an input, and I had one of those just now (it seemed the ship kept moving left even after reversing direction). Maybe I need to stop playing with a keyboard, or follow the Macaw's advice and get a better computer.

[BPzeBanshee]

I don't have much other stuff open when I'm playing MAME games but I suggest checking the obvious - 100% speed. There was times when I was playing Raiden Fighters on a machine that ran it at borderline speed and it would not respond to inputs every so often due to performance spikes and such. Also, having something like LanSchool installed (if you're playing it at a school or business that has similar software) usually fucks up controls regardless of what you're doing with the keyboard.

[Ed Oscuro]

I don't have much other stuff open when I'm playing MAME games but I suggest checking the obvious - 100% speed.

I'm not sure I'd be able to catch a dropout on the counter if it happened...it might be worth trying, though.

Also, good news all - Dangar runs with no frames of lag at all (in the new version)!

[BPzeBanshee]

The .145+ official MAME build?

[kassj0peja]

I want to get into MAME as well. But I have no idea what computer I need for the games I want to play.

I am quite new to shmups (Ikaruga on 360, looking forward to Sine Mora and Raiden Fighters Aces PAL, and 10 years ago Ikaruga and Border Down on DC) and I want to try classics like (Do)Donpachi, Batrider, Garegga, Bakraid and Batsugun.

What computer do I need for those games or is there even a chance to play them on multicore-ARM tablets with a Bluetooth controller?

[moozooh]

I suggest starting with a personal computer. Anything released in the last ten years will run DoDonPachi and other games of that period. I haven't heard of anyone playing MAME games on an ARM tablet with a BT controller, but that isn't out of the question I guess. You might experience noticeable input lag that way, though, which will render the games nearly unplayable.

[CMPXCHG8B]

What computer do I need for those games or is there even a chance to play them on multicore-ARM tablets with a Bluetooth controller?

A modern day Core 2 Duo would work fine. An i5 or an i7 would be even better. You don't need multiple processors or even that big of a graphics card. I'm willing to bet you could build a brand new MAME rig for under $400 (but that would be cheaping out on a lot of components, like the case and PSU).

Bluetooth will murder latency and make MAME games more annoying then they're enjoyable. You really need something wired.

ARM tablets don't have the power to play some of the more graphically intensive games. They also lack the software support from MAME to make things run really well. And given the wasteland of abandoned devices, broken SDKs, and horrible hardware that ARM seems to have spawned- I can't really see why anyone would want to invest time in trying to port to anything ARM based. It might be worth it for iOS or the Playbook, but such an undertaking would be neither quick nor simple.

-CMPX

[moozooh]

Actually graphics card doesn't matter at all, since MAME only uses it for postprocessing filters. And any game from 80s or 90s will run just fine even on a crappy netbook; confirmed by myself. That brings the initial price down to <$250 for brand new hardware. :P

[BPzeBanshee]

Well my legacy PC has issues running anything past 1995 (ESPRade works but is pushing it, Raiden Fighters is just like nope) and I'm fairly certain that's thanks to not only MAME's bloat issues but the underperforming graphics card - I find it hard to believe a 1 Ghz processor couldn't handle stuff up to 2000 so long as it isn't 3D. Furthermore it performs better than a lot of netbooks I've seen which is pretty disgusting. Cheap out, but don't cheap out too much.

Speaking of 3D, don't run anything 3D with MAME - it sucks. For example, get a Saturn emulator for Radiant Silvergun etc. as it's better designed/optimised for it.

TLDR: ^^ the Core 2 Duo is great.

[spl]

Well my legacy PC has issues running anything past 1995 (ESPRade works but is pushing it, Raiden Fighters is just like nope) and I'm fairly certain that's thanks to not only MAME's bloat issues but the underperforming graphics card - I find it hard to believe a 1 Ghz processor couldn't handle stuff up to 2000 so long as it isn't 3D. Furthermore it performs better than a lot of netbooks I've seen which is pretty disgusting. Cheap out, but don't cheap out too much.

Speaking of 3D, don't run anything 3D with MAME - it sucks. For example, get a Saturn emulator for Radiant Silvergun etc. as it's better designed/optimised for it.

TLDR: ^^ the Core 2 Duo is great.

1Ghz?? What is that like a Pentium III??? I would recommend something like a Pentium 4 3.0Ghz machine at minimum. Forget about new netbooks with Windows 7, just find an old machine P4 3Ghz or above with XP. That will run anything you need and will be less than $200.

[BPzeBanshee]

Well my legacy PC has issues running anything past 1995 (ESPRade works but is pushing it, Raiden Fighters is just like nope) and I'm fairly certain that's thanks to not only MAME's bloat issues but the underperforming graphics card - I find it hard to believe a 1 Ghz processor couldn't handle stuff up to 2000 so long as it isn't 3D. Furthermore it performs better than a lot of netbooks I've seen which is pretty disgusting. Cheap out, but don't cheap out too much.

Speaking of 3D, don't run anything 3D with MAME - it sucks. For example, get a Saturn emulator for Radiant Silvergun etc. as it's better designed/optimised for it.

TLDR: ^^ the Core 2 Duo is great.

1Ghz?? What is that like a Pentium III??? I would recommend something like a Pentium 4 3.0Ghz machine at minimum. Forget about new netbooks with Windows 7, just find an old machine P4 3Ghz or above with XP. That will run anything you need and will be less than $200.

Yeah, Pentium III. The last Pentium 4 I saw choked on running Ketsui though the integrated chip could run Halo on low detail no worries. If you're going to get into advanced stuff in MAME though there's no way in hell a P4 alone will cut it regardless of graphics card as going by the discussion that was in the TCFC thread upon testing the Cave SH3 games. I fortunately have a AMD Athlon machine in my room and while the graphics card that was in it choked and reduced me to using the integrated MAME stuff works fine as far as I tested. Carks it with 3D-anything and SH3 though.

[Captain]

I have pentium 4 and run the games just fine.

[Matskat]

Love it.

I use this everyday as my preferred MAME - installed on a PC I have built into one of my cabinets. GREAT STUFF!

Two questions:

1. Any chance of getting sound for Rapid Hero? Sound has been working since the .10x builds back in 2007.
2. Will SHmupmame ever adopt more modern variants of mame (namely .143)?

I know it's not anyone's problem but mine, and I'm VERY HAPPY TO HAVE WHAT I'VE GOT
But, I have to use two different MAME builds in my cabinet (slowpoke for SH3...Mushi, Pork, DS etc) and Shmupmame 3.0b...for EVERYTHING else. It would be real cool to someday not have to drop out of my frontend and boot up slowpoke to play three games

Thanks for the great MAME solution, it makes my cabinet setup alltogether more awesome...

Here's a peek:

[Ed Oscuro]

Just FYI, a great number of games run with either no lag, or 1-2 frames of lag, in the newest versions of MAME.

Rapid Hero works with three frames of lag - not great, but still should be playable. (I haven't tried that one out in years, since before it had sound, thanks for the heads-up! Man, feels like old times.) I'm not sure, but I do not believe every game in ShmupMAME is specifically lagfixed - some were ported in from older MAMEs which did not have lag yet worked fine, others were specifically backported from newer MAMEs (but past a certain point the architecture of MAME changed enough that it looks like it'd be highly improbable to get any of the new stuff working; I think 120 was a critical version for that).

In any case, it looks like this project has been put on the back burner by Nimitz (and left there). Any updates would be highly welcome, but the new MAME architecture seems to be such that getting rid of lag would be fighting with too much of the structure of MAME.

I wonder why we haven't seen a multi-polling per frame approach like the author of Ootake used, though.

[BPzeBanshee]

austere posted a quite detailed analysis of some of the games that ran on this some time ago, it might be difficult to find it sludging through the shit in this thread but since austere hasn't posted much from what I've seen lately, looking at his post history would be easier I imagine. Hope he's still up and around.

[trap15]

For what it's worth, the latest MAME changes have actually centralized lagged sprites. So now making a lagless MAME build is far easier than it used to be, and just requires changing one file in a not-very-complex way.

[O. Van Bruce]

For what it's worth, the latest MAME changes have actually centralized lagged sprites. So now making a lagless MAME build is far easier than it used to be, and just requires changing one file in a not-very-complex way.

It exist a mame version as lag optimized as shmupmame v3.0b?

[trap15]

It could easily be done, yes. I don't think it has been done yet though.

EDIT: Once the next u release is out, I might give it a quick shot and provide patches for those who build their own releases (and maybe others would routinely compile them or something, I dunno how most people deal with MAME).

[MEDIEVAL_MIKU]

Is making lagless Garegga/Batrider/Bakraid a similar process? I would like to see a patch for that for a MAME that actually works on my machine.

[trap15]

It would make literally every game in MAME that buffers sprites no longer buffer them.

[MEDIEVAL_MIKU]

It would make literally every game in MAME that buffers sprites no longer buffer them.

Sweet.

[Ed Oscuro]

I guess I have some reputation as a know-it-all (how could that be?!) and got asked about the GIT Repo changes listed.

I have some questions about this as a result. I ought to declare, also, that I'm not a programmer, so yeah.

- Are the changes listed at GIT Repo mostly removing already unused code?
- About lag, is the main cause sprite buffering? (This would explain why it is so time-independent, i.e. why lag doesn't disappear when frame-skipping.)
- Would there be any advantage at all to increasing polling of the computer's inputs to MAME, as seen in Ootake, or would this be unwieldy to implement for different games, or cause CPU use to shoot up dramatically?
- More out of my own curiosity, are there many (or any) games running different components (i.e. a watchdog circuit) on a different frequency altogether to the main emulation, and if so how does MAME handle this?

[trap15]

#1: No, there's some retarded conversion going on right now to "modernize" MAME
#2: Lag does exist as sprite buffering, yes. The removal of the sprite buffers is used to counteract input lag from the overhead of all the crap in PCs, rather than just to remove the sprite buffer itself though.
#3: Highly unlikely; almost all arcade games read the inputs once per frame and use that.
#4: Possibly, but doesn't really matter; MAME has a pretty good timeslicing system that handles all sorts of crazy non-matching frequency stuff.

[BPzeBanshee]

Would this universal change affect Batrider as well trap15? As I recall there's a bit more going on there than standard sprite buffers which is why Nimitz had problems with it to begin with.

Not sure about where to place patch files but I can compile stuff and build my own release for this and distribute if necessary - probably just standard MAME (not UI) with no fancy icons and your changes if it's cool with you.

[Barrakketh]

As I recall there's a bit more going on there than standard sprite buffers which is why Nimitz had problems with it to begin with.

Yeah, several of the toaplan2 games do things...differently compared to how most of the other games handle the sprite buffering. Some notable bits from shmupmame 3.0b:

Code: Select all

+extern data16_t *rz_mainram;
+extern data16_t *bg_mainram;
+static int bak;
+static int klug = 0;
+static int klug2 = 0;

*snip*

/***************************************************************************
     Sprite Handlers
 ***************************************************************************/
 
 static void draw_sprites( struct mame_bitmap *bitmap, const struct rectangle *cliprect, int controller, int priority_to_display, int bank_sel )
 {
-	const struct GfxElement *gfx = Machine->gfx[ ((controller*2)+1) ];
-
+	const struct GfxElement *gfx = Machine->gfx[((controller*2)+1)];
 	int offs;
-
-	data16_t *source = (data16_t *)(spriteram16_n[controller]);
-
+	data16_t *source;
+
+	/*if((controller == 0) && (bank_sel == 1) && (bak == 0))memcpy(spriteram16_n[0], &rz_mainram[(0x14e/2)], (TOAPLAN2_SPRITERAM_SIZE));
+	if((controller == 0) && (bank_sel == 1) && (bak == 1))memcpy(spriteram16_n[0], &rz_mainram[(0x15a/2)], (TOAPLAN2_SPRITERAM_SIZE));
+	if((controller == 0) && (bak == 2))memcpy(spriteram16_n[0], &bg_mainram[(0x52c/2)], (TOAPLAN2_SPRITERAM_SIZE));*/
+	//if((controller == 0) && (bank_sel == 1) && (bak == 0))memcpy(spriteram16_n[0], &rz_mainram[(0x354e/2)], (TOAPLAN2_SPRITERAM_SIZE)); 
+	//if((controller == 0) && (bank_sel == 1) && (bak == 1))memcpy(spriteram16_n[0], &rz_mainram[(0x355a/2)], (TOAPLAN2_SPRITERAM_SIZE));
+	//if((controller == 0) && (bak == 2))memcpy(spriteram16_n[0], &bg_mainram[(0x392c/2)], (TOAPLAN2_SPRITERAM_SIZE));
+	//memcpy(spriteram16_n[0], &rz_mainram[(0x15a/2)], (TOAPLAN2_SPRITERAM_SIZE));
+
+	if((bank_sel == 1) && (bak == 0) && (klug == 0))memcpy(spriteram16_n[0], &rz_mainram[(0x14e/2)], (TOAPLAN2_SPRITERAM_SIZE));
+	else if (klug > 0) klug--;
+	if((bank_sel == 1) && (bak == 1))memcpy(spriteram16_n[0], &rz_mainram[(0x15a/2)], (TOAPLAN2_SPRITERAM_SIZE));
+	if(bak == 2)memcpy(spriteram16_n[0], &bg_mainram[(0x52c/2)], (TOAPLAN2_SPRITERAM_SIZE));
+	source = (data16_t *)(spriteram16_n[controller]);
 
 	priority_to_display <<= 8;
 
 	for (offs = 0; offs < (TOAPLAN2_SPRITERAM_SIZE/2); offs += 4)
 	{
 		int attrib, sprite, color, priority, flipx, flipy, sx, sy;
 		int sprite_sizex, sprite_sizey, dim_x, dim_y, sx_base, sy_base;
 		int bank, sprite_num;
@@ -1351,16 +1419,19 @@ static void draw_sprites( struct mame_bitmap *bitmap, const struct rectangle *cl
 			{
 				sprite = ((attrib & 3) << 16) | source[offs + 1];	/* 18 bit */
 			}
 			else		/* Batrider Sprite select bank switching required */
 			{
 				sprite_num = source[offs + 1] & 0x7fff;
 				bank = ((attrib & 3) << 1) | (source[offs + 1] >> 15);
 				sprite = (batrider_object_bank[bank] << 15 ) | sprite_num;
+				if ((bak == 0) && (sprite > 0x1b100) && (sprite < 0x1b1FF))	klug2 = 1;
+				if ((bak == 0) && (sprite > 0x18FFF) && (sprite < 0x196FF))	klug = 6;
+				if ((bak == 0) && (klug2 == 1) && (sprite > 0x24000) && (sprite < 0x24FFF))	klug = 6;
 			}
 			color = (attrib >> 2) & 0x3f;

On a slightly related subject, I wish the git mirror provided a proper git repo to pull and clone from, especially since you can't fetch tags or anything. The clone and pull commands also operate at a speed best described as glacial.