MAME has a -mt option to turn on some extra multithreading to give a tiny speedup by handling the final blit on a different thread. This is unrelated to drivers which have their own threading implementations for larger speedups.
For several versions now this has been the default.
However, it is not a *safe* option to use, and should really be turned off.
The problem appears to be that for games using indexed palette modes the palette / video aren’t buffered properly and end up out of sync in what MAME outputs at a frame, or even sub-frame (if single stepping) level.
This is very evident in some cases, for example in “Rapid Hero” the initial fade at the start of a level becomes a flickering mess with -mt enabled, and in games like “DoDonPachi Dai-Ou-Jou” the area surrounding the AMI logo fades at a different speed to the rest of the image creating an obvious border, in addition the ending text fades are horrible broken. Several CPS2 games including the of the intro screens of “Gigawing” exhibit similar issues with -mt enabled. In other cases it caused more severe palette glitches; I had to work around it in Casanova by converting the whole driver to use RGB32 mode.
The issues introduced can be rather system-specific, and depend on the unchecked timing of everything else in your machine, so depending on what hardware you’re using the glitches may be different for you.
While in some case such glitches occurred on real hardware, and are thus emulated, the -mt option is creating many more incorrect cases where this happens and is significantly harmful to the fidelity of our emulation. I do not know why it is turned on by default for some marginal performance gain on older systems, it seems to go against the MAME philosophy of putting correctness of emulation as the first priority.
There are already Mametesters entries associated with this bug, for example
http://mametesters.org/view.php?id=3356
I’ve requested that it be turned off several times, but it appears the development team are not interested in turning it off, so I feel the need to highlight this issue as a public service. If you want to guarantee MAME operates as expected without additional glitches being introduced based on the hardware configuration of your machine then you should ensure you run with -nomt or equivalent way of turning off the multithreading from your frontend.
UME builds still ship with it turned on because I wish to ship unmodified baseline sources (so this applies equally to that) but it does irritate me that I’m shipping a piece of software with options know to cause defects in the emulation turned on by default.
yes, i remember some ‘MAMEPLUS’ specific options (filters) didn’t like the “mt” flag in MAME…flickering/blinking all the time
..they advised me not to use ‘-mt’
yeah, keep it off whatever build you’re using, I can’t stress enough, it’s not a safe option regardless of what marginal speed up you get (which in part I guess is because it’s not safe)
This doesn’t apply to MESS, correct?
Mess is Mame, so it applies there too.
I see. Has the latest SVN revision by hap resolved this issue?
it turns it off by default yes (of course if you turn it on you’ll still get the glitches) but at least the default is safe now.
does this relate to -numprocessors
and possibly carry over to that?
Or does that function completely different and save to use?
Haze I can see where you are coming from. However, I have to disagree. Would it not be better to find out where the race conditions are? So ship with it on? This is almost nearly the same argument you used for smooshing mame and mess together again. More use means more edge cases found.
I would say it would be better to have it on. Then say ‘if you are having trouble try turning it off and see if that fixes the issue. If so report it’.
In my crazy emu I would make every chip 1 thread and then only communicate thru signal lines just like the real chips. But it would probably be amazingly slow and a real pain to make it ‘tick’ like a real board.
The problem is nobody has fixed it (it’s been broken for *years*) and the gains you get are so utterly marginal it’s not worth it.
I’m pretty sure once you start copying everything you’d need to copy to safely offload the blit you’d lose the marginal speedup it offers anyway. In other words, I’m not even sure it’s worth fixing either.
There’s simply no point in having it enabled when it’s probably breaking thousands of drivers in subtle, and not subtle ways. A lot of people will run with the default config, so our default config shouldn’t be ‘broken’ it’s a disservice to users.
Drivers that do their own threading (numprocessor stuff) are unaffected, different system.
By that logic, then it’s not enough to simply change the default operation.
If it’s a broken feature then it needs to be commented out in the source because the majority of users do not create a fresh mame.ini at every new release and some front ends will automatically insert and include the -mt switch.
I noticed the glitching effects with Rapid Hero for some time now but I just assumed it was part of the video emulation issues with the NMK games that trap15 and MAMEdev had overlooked. I see now that isn’t the case – thanks for the heads up.
B2K24> I actually agree, it shouldn’t be an option at all, I’d rank it along with hiscore.dat in the silent but deadly category in it’s current form.
(I’m surprised nobody has extended the cheat system to offer similar functionality to hiscore.dat mind you)
Hi Haze, it’s unrelated, but may i ask you if you can add more post to your RSS feeds (at the moment it’s 10, which i feel is a bit too low) :
http://stackoverflow.com/questions/5838860/parameter-for-more-than-10-posts-in-wordpress-rss
What’s your method to make sure you don’t miss a comment?
I just look at the comments in the admin panel, have to do it fairly often to make sure all pending comments are approved / spam is actually spam etc.
it’s not usually too busy, so I’m surprised you don’t find 10 to be high enough.
I added the rss feed a day or two and the last comment i read is already out of the feed…
I think 20 should be largely enough
Well I’ve changed that option, not sure if it will affect the comment feed tho?
That’s perfect now, thank you!