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

[Ed Oscuro]

Just a random question if anybody wants to humor me: Assuming that the retoolings of MAME since 0.99 helped out accuracy and the like more that they have hurt, aren't the drivers here going to be handicapped a bit (from the standpoint of accuracy) by the older code? I realize what the purpose of this project is, and if the difference comes down to input lag vs. better colors or better sound - well, input lag is better to tackle first. But things like unrealistically perfect / smooth response in older versions of the MAME code could actually be a benefit vs. playing on the PCB. Of course, that benefit (tweaked CPU speeds) could be non-existent, or about the same as playing on a different revision of the hardware. I'm not calling for banning lagless edition; if anything, I want a new MAME version to play with since MAME Plus! seems to want me to compile it myself now...

[nimitz]

Ed : I don't really understand the argument considering there is a mame137 version (mameFX based) of Lagless and a mame99 version...

That being said, MANY drivers haven't been touched since mame99 (other than superficially), so the argument of accuracy only applies to improved drivers, cps3 and seibu SPI come to mind, but that's about it.

The main reasons for releasing a mame99 based version are the save-states and the New video driver (of mame107) which has caused emulation problems that still aren't fixed as of mame138 . The included functionality of old mameplus came as a bonus.


Finally, it's virtually impossible to make mame respond faster than the pcb, because the input devices, the OS, the video card and the screen (especially if LCD) all add lag which was not present (or very minimal) in the actual pcb.

[KNTain]

Finally, it's virtually impossible to make mame respond faster than the pcb, because the input devices, the OS, the video card and the screen (especially if LCD) all add lag which was not present (or very minimal) in the actual pcb.

I'd guess that there's no guarantee that these add more lag than the sprite buffer changes remove, though.

[Ed Oscuro]

Ed : I don't really understand the argument considering there is a mame137 version (mameFX based) of Lagless and a mame99 version...

Well, there was no argument, just a request for your thoughts. I also didn't know (or had forgot, more likely) about the MAME 137 version. The more you know!

That being said, MANY drivers haven't been touched since mame99 (other than superficially), so the argument of accuracy only applies to improved drivers, cps3 and seibu SPI come to mind, but that's about it.

I was asking along the line of core MAME changes; I'm gathering you think those are mostly architectural (as the liner notes usually indicate). My reading of the notes generally is that core changes seldom (if ever) actually make MAME faster, they generally have laid the groundwork for more complicated memory maps and functions in future releases. Though as of late (post-107) there has been a lot cleaned up. The very few last changes seem like the biggest performance downer in a long while, though.

Finally, it's virtually impossible to make mame respond faster than the pcb, because the input devices, the OS, the video card and the screen (especially if LCD) all add lag which was not present (or very minimal) in the actual pcb.

For the sake of argument: USB controllers add essentially no lag compared to original hardware which also has its own delays (even the amount of updates in classic console to USB controllers is said to be more than adequate); WinXP and some other OSes are quite quick; it's very easy to tweak a video driver to remove some of the famous causes of lag i.e. the infamous "max frames to render ahead" (though I doubt that ever applied to 2D); and how a $3 CRT monitor would add lag beyond an arcade monitor, or qualifies as an esoteric piece of hardware unlikely to be available to the dedicated lag fixer, is beyond me.

It would be silly of me to act as if emulators acting better than the original thing is a new issue (I recall wishing for CPU speed sliders in MAME...sometimes it would be useful) but I'm just tossing out that this is a possibility. Will it make much / any difference? Not in a competitive situation that I care about, but I am still mooting the possibility that lagfree may not be 100% the same as the real deal (of course there's also the possibility of differences between various board revisions and people generally don't mind those).

[trap15]

The very few last changes seem like the biggest performance downer in a long while, though.

That's because Aaron Giles thought it was a good idea to change everything to use C++; with lots of pointless classes (structs would have been fine, since they have no function pointers) and templates (if you know anything about code performance, you should know templates aren't exactly speed demons )

[nimitz]

Ed : http://www.anandtech.com/show/2803/7
This gives a general idea, even though actual total minimum times are higher than what is mentioned in that article (for various reasons) and even more so in mame.


MAME core changes don't really affect the emulation accuracy, unless it's something that affects the OS code directly (which was mostly made worse since 106). Improved accuracy comes from improved drivers. You can picture MAME as hundreds of emulators bundled together in the same framework, it's the individual emulators that make the accuracy difference not the shared code.

[Ed Oscuro]

Ed : http://www.anandtech.com/show/2803/7

Those are average times and for 3D games, and they also aren't being factored against lag times in the original hardware - which probably isn't close to being as significant in many arcade games as in the average situation shown there. That said, I will agree that the amount of slowdown in most any PC setup is likely to be more than in the average arcade game, even after discounting 3D games lag and some other easily solved sources of lag. I suppose you still have to factor in things like delays for simple input accumulators - which is something (I could easily be wrong but I always thought MAME handled this differently) that I don't think MAME explicitly emulates (at least not always, if the accumulator doesn't have any other function relevant to the emulation). At least with the original Game Boy this was somewhat significant (if I've read correctly...) Of course this balances against much of the slowness of old arcade games (i.e. Flying Shark) seeming to be in the various CPUs and other (emulated) components waiting for the input of other tasks, and that will remain constant across all systems / emulators. USB 2.0 bandwidth saturation has been an issue for years now (hello 4000dpi mouse!) but I'm getting a USB 3.0 motherboard pretty soon.

An interesting quote from the article:

Obviously there is variability in games, and sometimes we see a CPU limit at less than 60 FPS even at the lowest resolution on the highest end hardware. Likewise, we can see framerates hit over 2000 FPS when drawing a static image (where game logic and display lists don't need to be updated) with a menu in front of it (like when a user hits escape in Oblivion with vsync off). And, again, multi-threaded software design on multi-core CPUs really middies up the situation. But this is near enough to illustrate the point.

From what I gather, MAME is mainly CPU limited so you don't see those 2000 FPS situations but it does indicate MAME isn't normally GPU limited (for speed, players may gain more by turning off hardware stretch and hardware filtering than they lose by having the CPU scale, if they use a multi-core CPU where rendering and OS tasks are mostly offloaded to another core - the situation may be further improved yet on CPUs like the new Core i5 series and AMD equivalents where single cores can be automatically overclocked when other cores are in low demand). On a single-core CPU it doesn't really make sense to me that the small delay in the GPU hardware stretch, which should be close to free, would be worse than having the CPU do it, especially if you aren't hitting native clock speeds (but then I'm not sure that all the rendering options are done on the GPU even with those options enabled), even though it likely adds a small amount of lag.

(Aside: Well aware that every driver in MAME is its own emulator, though each has many other emulators in common i.e. a 68K emulation core. I would have to be pretty dumb not to know this. I've used MESS a few times too, mainly for the "benefit" of the more standard video modes and input, not for accuracy per se.)

Add in better modern hardware (see that thread about Forgotten Worlds / Lost Worlds spinners) and there is an opportunity for a dedicated player to actually get a small leg up on the originals, in some cases, I think. As I said, it doesn't really matter much to me since all emulator based competition ought to be friendl and skill is going to make or break plays, not slightly smoother gameplay. Of course it's always nicer to play a game more smoothly - if somebody wants to overclock their Genesis or NES that's up to them and I commend them. Same for this project; even if it could give somebody an advantage, I would still think it worthwhile just for nicer playing (let alone trying to stave off rampant PC caused lag).

I suppose somebody could see if using the fastest video mode (GDI maybe?) and changing other variables would allow removing input lag; I wouldn't do it just to prove a point though.

[nimitz]

I think you misunderstood the point of this build, it is completely unrelated to slowdown (no point in playing mame games that wont run at 100% anyways). Only response time is improved.

[Ed Oscuro]

I only mentioned slowdown as an unalterable facet of the original games, or in terms of the CPU MAME is running on being a potential factor of per-game lag, and I'm not confused on that point (at least).

[rashreflection]

This is awesome, thank you very much nimitz!

How much effort would it take someone to remove input delay from other, non-shmup drivers? I'm curious because some friends and I play a number of fighting games which aren't on supported drivers and aren't emulated on much else besides MAME (e.g. Ultimate Mortal Kombat 3, Jackie Chan in Fists of Fire). I'm not requesting this from you specifically, just wanted to ask.

Thanks again!

[Arcatech]

Sounds like a good idea to add those other drivers. Especially for Raiden because that game is very addictive.


The one game I would really like to play in a less laggy way would be bakraid. Does anybody know which version of mame was used to record the flame viper replay that someone encoded into a video? It has japanese writing at the beginning of the vid so I'm hoping its a retooled version of mame that is better somehow. any ideas?

[nimitz]

Bakraid and Batrider are weird ones, I have no idea how to fix those.

As for UMK3, I did check a while ago and there was no quick fix possible.

[Dave_K.]

Does anybody know which version of mame was used to record the flame viper replay that someone encoded into a video?

Its recorded with Mame32Plus-0.66.1 and has 3 frames of input lag.

[Ex-Cyber]

The very few last changes seem like the biggest performance downer in a long while, though.

That's because Aaron Giles thought it was a good idea to change everything to use C++; with lots of pointless classes (structs would have been fine, since they have no function pointers) and templates (if you know anything about code performance, you should know templates aren't exactly speed demons )

I don't see how the way they're using templates would necessarily hurt performance. It probably bloats the executable, but it looks like that would be a small bit of bloat per driver, and in the vast majority of use cases you only actually run one driver at a time.

[Arcatech]

Thanks for the info on that Dave_K.

I'll prob just end up springing the money to buy a bakraid board then. Game is hella fun. Havent mastered the scoring system but the music and sound effects are ace in that one.

[nimitz]

New version is out.

V2.0
new working game:
Fire Barrel

new lagless drivers:
Irem m72
Irem m92
Konami twin16
SeibuSPI
nmk16
raiden

[Dave_K.]

V2.0
new working game:
Fire Barrel

Nice job! Robivy64 will be pleased.

[Zeron]

Nice work man congratulations on the fantastic progress!

[ZOM]

Good stuff nim, keep it going.

[mesh control]

Thank you, Nimitz!

[Udderdude]

Nimitz confirmed for awesome.

[roker]

Bakraid and Batrider are weird ones, I have no idea how to fix those.

DAMMIT!

beggars can't be choosers

keep up the good work

[nimitz]

To be honest I have a few ideas for Batrider/Bakraid. And they are on top of the priority list, so hopefully it will happen sometime in the next decade .

[Ed Oscuro]

The shrimps have been removed from my eyes! I CAN SEE FIRE BARREL NOW!

I like the build, it seems very feature-complete. The only thing I got hung up on was video options - I tried "none" for video just to see what would happen, and it seemed to send Shmupmame to the taskbar with no way of quitting or interfacing aside from quitting the process. Naturally I'm sticking with DirectX as the fastest likely option

[emphatic]

Thank you for your awesome work!

[roker]

To be honest I have a few ideas for Batrider/Bakraid. And they are on top of the priority list, so hopefully it will happen sometime in the next decade .

I'm hoping to have the boards one day, with my luck, by the time it gets figured out it'll probably be too late for me.

[MR_Soren]

Download the appropriate archive for your machine, and extract it. Then download
common.zip and extract it into the directory the archive created.

no readme file in sight!

I agree. I see this and I think to myself, "... and then what?"

I downloaded the ubermame binary osx64.zip and extracted it. I now have a folder with a bunch of executables in it, including one called mame. So, I try to run mame by typing:

./mame on the command line

it tells me I do not have a rompath set in my mame.ini file. That seems like a reasonable thing for Mame to expect. However, I do not have a mame.ini file, nor do I know how to make one. Fortunately, mame tells me to look in my docs folder for more information. Unfortunately, I do not have a docs folder either.

Knowing full well that I'm not stupid, (I just finished co-writing a POS system from scratch), I did a google search. I found some discussions explaining how to make a mame.ini file. They say to type mame.exe -cc on the command line. Well, I'm not on windows, so I convert that to the equivalent ./mame -cc, and it simply lists which games match -cc. Still getting nowhere.

i think it's really cool that somebody posted these executables, but there is absolutely no information about what to do with what has been downloaded. So, I'm asking the people who know more about this than I do, could you please explain how I make this thing work? Thank you.


EDIT:
seems that using ./mame --cc will create the ini file. Maybe I'll get somewhere now, but any tips are still appreciated.

EDIT2:
Ok, I seem to be all good now. Just tried out Mars Matrix, and it worked like a charm. Thanks!

[Obiwanshinobi]

Boo-hoo, Task Force Harrier isn't improved, is it? The only difference seems to be that it refuses to run tharierj clone ROM (parent works fine) and once - just once - those round ground targets in the first stage were displayed incorrectly on top of the planes and helicopters (can be just the game's own bug).
That being said, there is something weird about TFH's behaviour in plain MAME (sprites seem to be out of sync with the background, just like the sprite buffer wasn't there to begin with).

[nimitz]

Thanks for the info Obiwanshinobi, I'll look into that later today.

[Domino]

How hard it is to make a linux version?