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

[Ed Oscuro]

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.

We've gone down this road before many times (including a few months ago), so let me explain this briefly:

Shift+P will show how long it takes for the game to respond to inputs, on original hardware, if the emulation is correct. (For most games, including many "laggy in MAME" titles, it is.)

This is apparently unrelated to your computer system's lag, which makes all games seem worse than they are. System-caused lag can be consistent - i.e. the "best case" scenario when you are just running the emulator (really simplified) which is influenced by things like USB timing as well as your graphics card and monitor. System-caused lag can spike, though, because most PCs are running many tasks in the background and some of these can cause performance drops.

When you add the two sources of lag - original game lag and new lag introduced by the system - games may be considerably more laggy than they originally were. Eliminating a sprite or frame buffer (which serves a purpose on original hardware, but not necessarily when the games are run in MAME) will help you get back to that baseline "original hardware" response, or possibly even beyond it.

But it's simply not correct to say that MAME (which has a highly modular structure) is especially inconsistent in how it handles inputs.

[BPzeBanshee]

There's definitely something up between old releases and new ones though.

I've been doing a bit of mucking around with compiling and I actually had a go at modifying cave.c like how Nimitz did to give the 'lagless' effect. Despite going more or less to the letter, however, I couldn't replicate the behaviour present in Lagless MAME at all. I even got on IRC and got trap15's help on the matter and it left him stumped that day. The most we managed to make it do was make Dodonpachi look like it was running on frameskip all the time.

Where set_pens() line in video/cave.c's screen update function (around line 1600) there's this:

Code: Select all

	
VIDEO_UPDATE( cave )
{
	cave_state *state = screen->machine->driver_data<cave_state>();
	int pri, pri2;
	int layers_ctrl = -1;

	cave_get_sprite_info(screen->machine);  //hack
	set_pens(screen->machine);

That's literally the only difference between the standard 0.140uWhatever release Shmupmame v2.2 was based off, and v2.2 itself. I even made a diff to see if there was line-by-line changes. Of course, in 0.147 the naming conventions for things have changed, so the set_pens function now looks like this:

Code: Select all

UINT32 cave_state::screen_update_cave(screen_device &screen, bitmap_ind16 &bitmap, const rectangle &cliprect)
{
	int pri, pri2, GFX;
	int layers_ctrl = -1;

	set_pens(machine());

I would've thought that adding cave_get_sprite_info(machine()); would've done it but no, it makes no difference at all. Maybe I missed something, this kind of modification IS new to me.

In addition, I got trap15's bufpatch diff to actually work, and had a go at say, Strikers 1999 which uses the unified buffering that it patches, and not only did it reduce the frame-by-frame delay by one frame exactly as advertised but I found it incredibly difficult to notice any desyncronisation between the background and sprites short of going frame-by-frame. It's nowhere near as obvious as what I saw in the other drivers in Shmupmame builds.

[e_tank]

Shift+P will show how long it takes for the game to respond to inputs, on original hardware, if the emulation is correct. (For most games, including many "laggy in MAME" titles, it is.)

not exactly. emulation can both be correct and the results you get from using the shift+p / frame advance test may differ from the response in frames that the game would have on actual hardware.

for example, many 8/16-bit gen console games (including mario 1 and sonic) poll input and cache it once per frame during vblank. the cached input is then used by game logic that runs after vblank, during the active display portion of the frame. for most games structured like this, from the time the input is caught it will take take 2 frames worth of time for you to see the response in a completed frame.

now lets say we have two emulators, emuA and emuB. for each frame on the host system both emulators will step the emulated machine one corresponding frame (1 full frame = active display + vblank), and both will poll input from the host system right before they emulate vblank, but emuA will start by emulating the active display and emuB will start by emulating vblank. if both were emulating a game described like the one above, then using the same kind of shift+p / frame advance test emuA would show a response in 3 frames whereas emuB would show a response in 2. both are technically correct in terms of emulation, but one _MAY_ respond quicker when running in real-time. now i say _MAY_ because that would depend both on the polling rate and the speed of emulation on the host system (among other things, probably). still, if given a choice i would argue that an emulator should be structured like emuB over emuA, as on certain host hardware there can be a difference.

But it's simply not correct to say that MAME (which has a highly modular structure) is especially inconsistent in how it handles inputs.

i'll give you that, i really don't know one way or the other. mame is a complicated beast and i'm not willing to devote the large amount of time it would take to study the code in order to really grok its core structure. however, that's kind of my point as well, mame is complicated and if there are some machines in mame/mess that due to its timing system are effectively structured like emuA above, and others like emuB, well then that would be an inconsistency and will give different results in a frame advance test for games that work pretty much the same way.

the fact that mario 1 running on nes emulation in mame/mess responds in 2 frames in a frame advance test, and sonic running on genesis emulation in mame/mess responds in 3, two games that have the same frame response time on hardware, shows that mame/mess can be inconsistent between emulated hardware. what exactly is causing it, i don't know, and if it results in an actual delay when running in real time on the host system, again i don't know..

[Ed Oscuro]

Thanks for the info BPz!

the fact that mario 1 running on nes emulation in mame/mess responds in 2 frames in a frame advance test, and sonic running on genesis emulation in mame/mess responds in 3, two games that have the same frame response time on hardware,

MAME / MESS being modular internally doesn't mean that all of their parts are guaranteed to respond the same way: Different CPU emulators are called up for each of the systems. Anyway, you'd have to ask a MESSdev whether NES and Genesis really do respond in one or two frames; I believe the Genesis has a frame buffer while the NES doesn't.

Shift+P will show how long it takes for the game to respond to inputs, on original hardware, if the emulation is correct. (For most games, including many "laggy in MAME" titles, it is.)

not exactly. emulation can both be correct and the results you get from using the shift+p / frame advance test may differ from the response in frames that the game would have on actual hardware.

No, almost exactly! The goal of MAME and MESS is cycle-accurate emulation. When you use the word "correct" you seem to mean "responses look the same as hardware," but you have not ruled out taking shortcuts to get there (i.e. non-cycle-accurate emulation), which is not what MAME and MESS are about. The hardware would not be documented if it was merely a "faithful recreation" of the original game, which is what MAME would be without the goal of cycle-accurate emulation.

With that out of the way, there is one difference between MAME running normally and actual hardware that is the lag introduced by MAME's and the operating system's input systems, which means that running at normal speed, you can't duplicate play on MAME or MESS exactly if it requires responses below the new total response (emulated system + MAME and operating system overhead). Additionally I believe it is possible for inputs to be delivered to MAME frames behind even if you use shift+p, which may be the center of much of the speculation and uncertainty seen here. I would see that as a bug if it introduced more than one frame of lag, though - I don't know whether MAME's frame step is set up so that the next frame is rendered before or after the step, so it might be possible (although it would seem wrong) for input from the system to reach the frame slow (although actually the behavior in MAME seems to be that the desired inputs must be depressed at the time of the frame step, so you can't just mash keys first and then frame step, which makes sense but would mean that essentially frame stepping might give no benefit to reducing the effect of system lag at all).

[trap15]

For what it's worth, almost literally nothing in MAME is cycle-accurate. Especially not the CPU cores. Also I'm fairly sure e_tank is correct in his reasoning for why Shift+P doesn't work how you'd expect it to sometimes.

[Ed Oscuro]

Figures I'd get bsnes and MAME mixed up!

I think, then - isn't cycle-accurate emulation a MAME objective, even if just implied? That would seem to fix a lot of problems (at the expense of even slower operation, of course...)

[trap15]

It should be, but it doesn't seem so

Probably wouldn't fix most problems, the main problem is the severe lack of proper regression testing.

[BPzeBanshee]

Turns out I was wrong. Adding the line cave_get_sprite_info(screen.machine()) to the current source just before set_pens(screen.machine()) actually DOES have an affect........but DoDonPachi has one more frame of lag than what it did in Shmupmame v3.0b. The other Cave games behave the same as in v3.0b.

I also tested DonPachi and got the same effect. The actual blitter/video code is a bit much to look at for my liking but I reckon it's some kind of MAME core change that changed a function that the DonPachi/DoDonPachi-specific component of MAME calls, ergo the extra frame.

[evil_ash_xero]

Any advice on the 0xc0000005 error, other than the DEP fix, or going to an older version of SM?

[trap15]

That's all you can do. By the way, turning off DEP lowers your system's overall security. Bad idea.

[twotone8]

it's a bit daunting trying to figure out which versions of mame to use. I've read through quite a bit of this thread, and much of it goes right over my head. The only thing I know is that I'm very very sensitive to input lag, and would love to avoid it as much as possible.

As of now I'm running shmupmame 2.2 with a full .140 romset for most of my mame needs

And slowpoke mame .143 with some select cave roms.

Is this a viable option? Am I missing something? Has anything been updated in the main mame builds recently which renders shmupmame obsolete? I haven't done much comparison work, but 2.2 feels fine for things like espgaluda and gradius II.

[BPzeBanshee]

v2.2 is fine if you don't mind missing out on Garegga lagless. I think it might be missing custom buttons too but it's been so long since I used it that I've forgotten (MAMEUIFX base I believe).

That's all you can do. By the way, turning off DEP lowers your system's overall security. Bad idea.

Bullshit. Look back and you'll some people have fixed this (or at least shifted the problem around on worst-case) by updating Windows 7 with Windows Update. I have a constantly up-to-date machine that runs v3.0b fine and it's a 64-bit machine too.

[trap15]

DEP = Data Execution Prevention. Turning off DEP turns off this protection against attacks that put arbitrary code on the stack to run and break in to the machine.

[BPzeBanshee]

I was referring to the "that's all you can do" part, implying he had no options left, which is untrue.

[yukbeezy]

Hi,

Is there a way to activate auto fire option in Guwange under shmupmame 3.b?
I cannot find the dip switches.

I would like to map the 3rd button as full auto.

Thanks in advance.

[daskrabs]

I was thinking about building a MAME PC w/ a J-PAC and an ArcadeVGA for my E2. Anyone here running a candy w/ that setup? I'd like to know what the limitations are, i.e. what doesn't run 100% (or near).

[R3ma1ns]

v2.2 is fine if you don't mind missing out on Garegga lagless. I think it might be missing custom buttons too but it's been so long since I used it that I've forgotten (MAMEUIFX base I believe).

That's all you can do. By the way, turning off DEP lowers your system's overall security. Bad idea.

Bullshit. Look back and you'll some people have fixed this (or at least shifted the problem around on worst-case) by updating Windows 7 with Windows Update. I have a constantly up-to-date machine that runs v3.0b fine and it's a 64-bit machine too.

Whelp,

I've completely updated my Winx64 installation, made a DEP exception for Shmupmame, and I still get the 0xc...5 error. Unless anyone has further suggestions, I guess I'll use the older version, which seems to work fine.

...That said, if anyone has advice on how to get current versions to work, I would like to hear it.

[BPzeBanshee]

Damn. Whatever causes the error must be something real obscure and possibly driver-related. You'd think it'd at least error consistently on machines with the same OS and updates.

I didn't even have to make a DEP exception to get it to work on my setup, guess I'm the lucky one.

If anyone has a clue how to go about compiling old versions of MAME apparently WolfMAME Plus! 0.99 works just fine on computers that otherwise show a DEP exception for ShmupMAME (I've tested this on at least one machine, had another forum member back me up, and Nimitz knows but has done nothing). Compiling that but with the v3.0b lagless drivers on top of it should in theory result in a working build. I'll see if I can't figure it out at some stage but the next few days are a bit tight for me.

[R3ma1ns]

For what it's worth:

It works perfectly on my Win7x64 laptop and my older Win7x32 laptop. Just not the x64 desktop. The only major between the desktop and the laptop setups is that the desktop has a discrete video card (a Radeon HD 8400 series). The laptops both have integrated video.

[joeboto]

also working on my new win8 pro OS direct upgraded from win7 64bit which cant play shmupmamev3.

[BPzeBanshee]

My working desktop has an Integrated card actually and the machine I tested that had the DEP error was a gaming laptop which I presume had it's own card. Interesting.

Not sure I want to touch Windows 8 just yet. I saw it on display at a local JB HiFi store and played with it for a bit, kinda broke it when I couldn't figure out how to close a program and hit CTRL-ALT-DEL for Task Manager. :S

[TransatlanticFoe]

Worked fine on my Win 7 64 bit for ages (like a year or something) then suddenly it throws the error from time to time. DEP exception worked at first then stopped working.

I just use regular MAME now because that starts every time without fail.

[O. Van Bruce]

Worked fine on my Win 7 64 bit for ages (like a year or something) then suddenly it throws the error from time to time. DEP exception worked at first then stopped working.

I just use regular MAME now because that starts every time without fail.

I still wonder why haven't anyone fixed this error for shmupmame...

[twotone8]

does anyone know how CAVEUI holds up in terms of input lag when compared to shmupmame? I've been toying with it since the new release this week, and I honestly can't determine if it's any different, and I'm usually quite sensitive to these sorts of things.

http://neo-nebuwaks.blogspot.com/2012/1 ... -info.html

[BPzeBanshee]

Decrypted P? What on Earth's that about?

CAVEUI does nothing for input lag to my knowledge, really it's biggest feature is including the blacklisted CV1000 (gotta be programmatically correct here, not "Cave SH3" ) games.

[nahucirujano]

Hi, guys.

I wanted to ask you about some problem I'm having with ShmupMame 3.0

After a long time without playing on Mame, yesterday I wanted to play Battle Garegga.
But I don't know why, Mame doesn't run any rom.

I move from one to the other, and press Enter and nothing happens, or click on "Play X game" and doesn't run it either.

I refreshed the rom list, the Roms directory is fine, but it doesn't work at all.

How can I fix this problem?

[Obscura]

For Garegga, you should be using Garemame anyways.

[nahucirujano]

For Garegga, you should be using Garemame anyways.

I'll keep that on mind, thanks

Besides that, does anybody know how to fix this?

[nimitz]

Updated to version 4, See first post.

[Mortificator]

More than a shmupmame! More than a shmupmame to meeee.

The link to the gui version is a little off, however, this when it should be this.