Main > Software Forum
ctrlr / cfg file parsing
Minwah:
As I've been out of the loop for a while, could someone please jog my memory a bit...
I want to figure out which controls (keycodes/joystick/mouse inputs) are used by each game. I recall the order of priority is general, driver, parent, clone but I can't quite remember what happens if settings are present in both ctrlr and cfg files. I *think* cfg files over rule ctrlr files in terms of game specific entries, but I'm not sure about the general entries etc.
What I am after is exactly which order I should parse the files.
Thanks for any help!
u_rebelscum:
Think two lists: general & local (aka "this game"). This lets mame keep the defaults for all games even when editting specific games.
The general list is every input, the local is just the inputs included in the game. Usually the local list has everything set to "default", which means "look in the general list" (in pseudo code, of course). However, if the game driver sets the input to something else, then that local starting setting isn't "default" but whatever the driver sets. The general list defaults are also set in the source code, but there's only one for all games.
The ctrlr file changes the general list. The ctrlr file is read once for top to bottom, and any relevant changes are added in the order they are read. (This is different than the first ctrlr files, which had the priority you listed.)
Then the default.cfg changes the general list. (aka overriding the ctrlr file)
Finally the gamespecific.cfg changes the local list. (Almost always overriding the ctrlr and default.cfg files, see next paragraph for the exception)
The weird case is with driver set game specific inputs. For cfg files, only inputs set to something different from the starting settings are listed. In this case the starting input is not "default", but since it's the starting input, it's not included in the cfg file. However, since it's not "default", mame uses it instead of the general setting. To use the general setting, set that input to "default", which will be saved in the cfg file; sort of "un-overriding" the general list. And the only way to find them is to look at the source AFAIK.
Ignoring them, it's pretty easy.
Minwah:
Thank you, that helps a lot....
It seems like it ought to be more straightforward. Is there any reason why one shouldn't create a default.cfg, and game-specific .cfg's with all relevant inputs? ie so no ctrlr file is needed. By 'create' I mean manually or otherwise generating the files, rather than using the Tab menu. I don't much like the 'new' ctrlr file system.
Edit: Yes there is, they get wiped :p Not sure how it can tell tho, maybe the port index's...
u_rebelscum:
--- Quote from: Minwah on August 01, 2007, 05:42:38 am ---Thank you, that helps a lot....
It seems like it ought to be more straightforward. Is there any reason why one shouldn't create a default.cfg, and game-specific .cfg's with all relevant inputs? ie so no ctrlr file is needed. By 'create' I mean manually or otherwise generating the files, rather than using the Tab menu. I don't much like the 'new' ctrlr file system.
Edit: Yes there is, they get wiped :p Not sure how it can tell tho, maybe the port index's...
--- End quote ---
The game specific cfg files are much more strict that default.cfg or the ctrlr file; if the port index, mask or default are different that the source, mame considers it invalid and removes it. This allows for the drivers to have rare cases where, for example, there are two player 1 button 1s, or the inputs are hacked with "original" and "playable" & both using player 1 joystick type.
The default.cfg & ctrlr file do not use the index/mask/default values, so you can copy from a game's cfg file to default.cfg or ctrlr file, but not the other way around. Even copying between or within a game cfg might not work without the correct index/mask/default values, but works fine with the default.cfg & ctrlr file.
Aaron has expressed openness toward changes to the input structure, but not interest in doing it himself. How do you suggest making it more straightforward? Without removing ctrlr support? ;)
If you want everygame to list every input, whether changed or not, for your project, it's a simple change in scr/emu/inptport.c, diff attached. The cfg files will include special and dipswitches. Looks like I get memory overload if I try the same changes to default.cfg, though (in the function above the one edited for the games).
headkaze:
MinWah, this thread might be helpful. Also me and Howard are working on the "Mame Input Bible" which will go into detail how everything works. Hopefully we can see a release in the near future. It should be very helpful for this sort of thing.
Navigation
[0] Message Index
[#] Next page
Go to full version