The NEW Build Your Own Arcade Controls
Main => Software Forum => Topic started by: Stiletto on July 27, 2017, 03:05:48 pm
-
We're hitting the limitations of the driver element and its attributes in MAME's -listxml output. To allow for inheritance, better deal with systems with configurable slots, and make handling of machines and devices more uniform, this element is being deemphasised, and some of its attributes are deprecated, to be removed in a future release.
The following attributes of the driver element are deprecated and will be removed in a future release (they will be maintained for at least two releases before being removed): color, sound, graphic, protection. The other attributes are not scheduled for removal at this point.
A new feature element (https://github.com/mamedev/mame/commit/22d80b35290491e041122708b0482826ba3a89c9) is being introduced to provide more detailed information on unemulated and imperfectly emulated features. This element is applicable to both systems and devices, unlike the driver element that is only applicable to systems. The feature element has three attributes:
- type - required, indicates the feature of the system/device that has emulation issues; possible values at present: protection, palette, graphics, sound, controls, keyboard, mouse, microphone, camera, disk, printer, lan, wan
- status - implied, indicates the emulation status of the feature for the device itself; possible values: unemulated, imperfect
- overall - implied, indicates the emulation status of the feature inherited from subdevices; possible values: unemulated, imperfect
The status attribute only be present if the device itself indicates emulation issues for a feature. The overall attribute will only be present if more severe emulation issues are indicated by subdevices than by the device itself. For example
<feature type="keyboard" status="imperfect"/> <!-- device indicates that its keyboard emulation is imperfect -->
<feature type="mouse" status="unemulated"/> <!-- device indicates that mouse is unemulated -->
<feature type="graphics" overall="imperfect"/> <!-- at least one subdevice indicates that graphics emulation is imperfect -->
<feature type="palette" overall="unemulated"/> <!-- at least one subdevice indicates that colour palette is unemulated -->
<feature type="sound" status="imperfect" overall="unemulated"/> <!-- device indicates that its sound emulation is imperfect, at least one subdevice indicates that sound is unemulated -->
Right now you can see this with the votrax device. The aussieby system inherits imperfect sound from its votrax device. The c64_speakeasy slot card inherits imperfect sound from its votrax device. If you launch a c64 with a c64_speakeasy card in a compatible slot, MAME will warn about imperfect sound.
If you provide a UI for slot device selection, you may want to provide indication of emulation issues declared by slot devices.
Right now, there is no equivalent for the emulation and savestate attributes for devices (NOT_WORKING and SUPPORTS_SAVE flags). This will come at some point in the future.
Source: http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Board=news&Number=368244 (http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Board=news&Number=368244)
-
Yup. Told you guys the day you switched over that xml sucks and you'd hit a wall. A switch to ini files or a straight up database format might make more sense now that mame's game/machine list is so gigantic.
-
Yup. Told you guys the day you switched over that xml sucks and you'd hit a wall. A switch to ini files or a straight up database format might make more sense now that mame's game/machine list is so gigantic.
A little heads up from a project leader to help front-end deals with upcoming changes and the messenger gets it figuratively shoved back in his face in a very "Thanks, but no thanks" way. Crazy stuff.
Anyway, hopefully those who have a legitimate use for the information will take it to heart.
-
Yup. Told you guys the day you switched over that xml sucks and you'd hit a wall. A switch to ini files or a straight up database format might make more sense now that mame's game/machine list is so gigantic.
Are you smoking crack or something? This has nothing to do with xml sucking, nor is it something that would be easier with 'ini files'
It's simply about devices getting their own sets of flags because we have a lot of systems where you can configure different devices meaning the global flag is no longer sufficient so people need to consider the status of the device too. It also allows finer control over where in a system emulation issues are flagged. eg. if we know the emulation of a certain sound chip is buggy / incomplete we can tag it at that level and have the drivers inherit that.
The concept of each game / machine only having it's own set of flags is just something that has been around since the early days of MAME (yes, before XML was used for output) and is now going away in favour of something better (which XML makes nice and convenient to represent in the output as it happens)
-
I get it now. Instead of a singular set of status flags for a game you can now do it at the component level, potentially allowing for even more bloat in an already bloated xml file and inaccuracies due to the fact that individual games won't necessarily be checked anymore. That isn't worse or anything. I do appreciate the heads up, don't get me wrong, but have you guys looked at the full xml lately? Takes forever to parse it's so big.
-
I'd say we had different ideas of forever, or maybe your parser sucks.
If you were to attempt to brute-force a CPS2 key without the key-cracker that would take forever, literally, we're talking longer than the universe has been around so reducing that to a couple of days / hours depending on the situation was worthwhile.
If you're talking about taking a couple of seconds to parse an XML file that you can then cache the bits you care about if you so please, no, that isn't forever.