> I'm not asking anyone to fix it asap, I'm asking mamedev to at least
> ascertain/confirm, take the issue seriously that's all, right now I don't trust you
> do.
No, I don't think RB takes the issue seriously, either. In fact, I think once he reads this post of mine and sees who and what is responsible for the issue, he'll be even less likely to want to take up the mantle and fix it. I know that now that I've tracked down who and what caused it, I have precisely zero interest in fixing another dev's code. Least of all when it's part of such a monolithic change as this one.
In this case, the issue was re-introduced with this changeset: https://github.com/mamedev/mame/commit/b193e05cd7c8456a2648d43854645da84f56ddbd
It's a Nathan "Bletch" Woods special, aptly named "Overhaul to how MAME handles options, take two". I guess it needs a take three, because the current INI behavior is flatly unacceptable.
If I had to hazard a guess, the source of all of this misery is the removal of this exact line while implementing no functional replacement: https://github.com/mamedev/mame/commit/b...2c9a2184cabL205
The intention of that line seems obvious: At the start of the machine's execution, it would previously call m_options.revert with the highest-priority INI setting, to peel off any game-specific INI settings which had previously been applied.
With that line removed, any game-specific INI settings are free to linger on even after the user has returned to the internal UI and launched another game.
How best to fix it? You got me, the front-end code isn't exactly the greatest thing since sliced bread.
|
Index 
Flat 
Re: Why does MAMEUI need to continue to exist? (nt)
Reply
