Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06068 Core Minor Always Nov 7, 2015, 19:36 Aug 18, 2017, 19:26
Tester u-man View Status Public Platform MAME (Official Binary)
Assigned To Resolution Open OS Windows Vista/7/8 (64-bit)
Status [?] Acknowledged Driver
Version 0.167 Fixed in Version Build Normal
Summary 06068: CFG/INI confusion: core screen settings that are changed with sliders are saved in the .cfg file and this creates a conflict with .ini file
Description core screen options (like brightness, gamma, contrast) that are altered with sliders while in game, are stored in the .cfg file on exit. The resulting .cfg file will override the .ini setting, which also stores core_screen_options.

This leads to a inconsistence, because the core screen options are stored in two places.
If a game with a existing .cfg file will started again, MAME will read any core screen options values only from the .cfg file and will ignore any setting from the .ini file.

This behaviour can lead to problems, if people wants to exchange .ini files among each other, or a user wants to change the core screen options via the .ini file and is not aware that a existing .cfg file will override the changes he made to the .ini file.
Steps To Reproduce Create a .ini file for a game of your choice.
Start the game, use the tab-menue and enter the "slider controls" options there.
Change the Brightness, Contrast, Gamma settings via the sliders.
Quit MAME and a .cfg file for the game will be stored in the cfg folder.
Start the game again and it will have the Brightness, Contrast, Gamma settings, which was set by the sliders you used before and are overriding the (default) core screen options settings from your .ini file.

Additional Information IMHO the core screen options settings should not be stored in two places, but rather only in one. Ideally only in the .ini file, as the users got used to this file.

The best way, would be a seperate screen setting file, that keeps track of any screen relevant settings, including HLSL/GLSL, core screen options, screen index, screen horizontal/vertical stretches and position, etc. etc.

Such a screen setting file, could be then considered and treated like a "screen preset" and this preset could be set in the .ini file.

This way we would also clean up the .ini file, that is cluttered and overloaded with all these available screen options.
Regression Version
Affected Sets / Systems CFG/INI confusion
Attached Files
There are no relationsihp linked to this issue.
User avatar
Nov 10, 2015, 18:35
It doesn't matter how many places a config item is stored - there is a certain order of application which is used where the last setting accepted from your config files is used, In the DOCS, in the CONFIG.txt file under the command for "readconfig", there is an list of .config file types outlined which shows you the order which they are loaded. If an item lower on the list matches another options, the previous one is superseded.

-[no]readconfig / -[no]rc

Enables or disables the reading of the config files. When enabled
(which is the default), MAME reads the following config files in order:

- mame.ini
- <mymame>.ini (i.e. if MAME was renamed mame060.exe, MAME
parses mame060.ini here)
- debug.ini (if the debugger is enabled)
- <driver>.ini (based on the source filename of the driver)
- vertical.ini (for games with vertical monitor orientation)
- horizont.ini (for games with horizontal monitor orientation)
- arcade.ini (for games in source added with GAME() macro)
- console.ini (for games in source added with CONS() macro)
- computer.ini (for games in source added with COMP() macro)
- othersys.ini (for games in source added with SYST() macro)
- vector.ini (for vector games only)
- <parent>.ini (for clones only, may be called recursively)
- <gamename>.ini

The settings in the later ini's override those in the earlier ini's.
So, for example, if you wanted to disable overlay effects in the
vector games, you can create a vector.ini with the "effect none" line
in it, and it will override whatever effect value you have in your
mame.ini. The default is ON (-readconfig).

.cfig files, while similar, run under a separate system completely and if you have a .cfg file contradicting anything in any .ini file, the .cfg file will be used for the driver/setname/default settings, depending on filename.
User avatar
Senior Tester
Nov 10, 2015, 21:03
edited on: Nov 10, 2015, 21:04
Looking at source code in EMUOPTS.CPP <driver.ini> is parsed before <parent.ini> not before vertical/horizontal (which are equally ranked)
	// next parse "source/<sourcefile>.ini"; if that doesn't exist, try <sourcefile>.ini
std::string sourcename;
core_filename_extract_base(sourcename, cursystem->source_file, true).insert(0, "source" PATH_SEPARATOR);
if (!parse_one_ini(sourcename.c_str(), OPTION_PRIORITY_SOURCE_INI, &error_string))
core_filename_extract_base(sourcename, cursystem->source_file, true);
parse_one_ini(sourcename.c_str(), OPTION_PRIORITY_SOURCE_INI, &error_string);
// then parse the grandparent, parent, and system-specific INIs
int parent = driver_list::clone(*cursystem);
int gparent = (parent != -1) ? driver_list::clone(parent) : -1;
if (gparent != -1)
parse_one_ini(driver_list::driver(gparent).name, OPTION_PRIORITY_GPARENT_INI, &error_string);
if (parent != -1)
parse_one_ini(driver_list::driver(parent).name, OPTION_PRIORITY_PARENT_INI, &error_string);
parse_one_ini(cursystem->name, OPTION_PRIORITY_DRIVER_INI, &error_string);

User avatar
Nov 10, 2015, 23:19
edited on: Nov 10, 2015, 23:20
It is possible when I when through and fixed up the documents a while ago I misread this below to mean <driver.ini> and placed it higher on the list because of it
// if we have a valid system driver, parse system-specific INI files
const game_driver *cursystem = system();
if (cursystem == NULL)

Other than that, there shouldn't be much of an issue with order.

User avatar
Nov 11, 2015, 02:23
edited on: Nov 11, 2015, 02:39
".cfg files, while similar, run under a separate system completely and if you have a .cfg file contradicting anything in any .ini file, the .cfg file will be used for the driver/setname/default settings, depending on filename. "

And this is exactly, what IMHO is inconsistence behaviour. I dont mind the other stuff that .cfg is storing, like for example horizontal/vertical stretch, position etc. , because you can not find this stuff in a .ini . Brightness, Contrast, Gamma on the other hand, can be found in both places. And just for information, the .cfg file doesnt store only the last setting, thats why i wrote a brief decription of the problem "Change the Brightness, Contrast, Gamma settings via the sliders."... which means it stores all three sliders and make the problem even worse.

To be honest, there is no logic behind this (or at least i dont see it), for having such relevant parameters in two places. Either store any slider action and not just a few in the .cfg and that would be, what i described the best solution, or dont create conflicts by having important parameters in two places.

To follow your statement regarding the layering of .ini´s, a .cfg file would be the last and not a game.ini.
Or to make it short: .cfg settings should not influence any .ini settings at any cost.

User avatar
Nov 11, 2015, 16:19
Short of taking those video options out of the slider menus, under the current system, I'm not sure what else that someone can do to avoid it other than making sure not to conflict your own settings. Setting up any special exceptions and checking for previous adjustments from default of any of those settings you describe only complicate the code and potentially allows for more stuff to go wrong, in my opinion. I cannot say that it is perfect, but it is as flexible as it is for a reason that end users over time have pretty much demanded it and there is a clear path on how things tend to work.

This is in my view considered more of a feature request rather than a straight up bug.
User avatar
Nov 11, 2015, 20:17
Sorry... but in no way, i can imagine, that this behaviour was demanded by any user. This inconsistence is so user unfriendly, that i can not find the right words for it, other than WTF.

It is quite the opposite, i only know people that are upset by this behaviour. If you really think, this is a feature request... go for it.
I will create a macro for myself that deletes any .cfg file upon exit from MAME. The .cfg is not a essential file and not needed at all by MAME, it causes just troubles, like the one i described already (but maybe i write chinese). The only usage i have from a .cfg file is, that it remembers the artwork settings (like use upright, cocktail etc. artworks). I will gladly yield up on the .cfg file, in favor of a absolutly correct working .ini file.
User avatar
Nov 12, 2015, 00:55
I've set status to Direction Needed in hopes some actual developers join into this discussion. Like I said, it is not perfect and I know it. Rewriting it would be time consuming effort and, it would seem, no capable developers are currently jumping to do anything about it.
User avatar
Aug 16, 2017, 14:47
I actually agree with u-man here. While this behavior may have made sense at one time, it is at odds with how shaders options work. I think consistency needs to be applied.