Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: dat redesign discussion  (Read 12983 times)

0 Members and 1 Guest are viewing this topic.

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
dat redesign discussion
« on: August 28, 2014, 12:43:38 pm »
Creating a thread to discuss how the dat needs to change.

I am going to start with the dat will be xml and possibly JSON.  The ini format is going because it is limiting.

I have a couple of ideas for the format. I will put some samples together. I am thinking the xml will be database-like. In other words there will be sections of the xml that can be used as a lookup table.  For example, one possibility is to ha e the list of control types - 8way joy, spinner, etc - has a separate node and then in the game i will link to the control via an I'd.

Anything we come up with I will provide a C# example of how to efficiently access the data.

The website is going to be redesigned also. I want to learn HTML5 and there is a bunch of new elements we can take advantage of. In my mind I can see how I want it to work, utilizing drag and drop, web storage, and other html5 things. :cheers:

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: dat redesign discussion
« Reply #1 on: August 28, 2014, 01:06:11 pm »
Also I am thinking thw we sit will act like a social media site. There will be like/dislike on entries and that will determine if the entry stays in the dat. Some type of voting system I think. It may be a good or bad idea.  The idea is to have the project be self managed.

Part of that will also be if an existing entry needs to be changes someone can change it and the public approves the change.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19399
  • Last login:March 16, 2024, 05:59:16 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: dat redesign discussion
« Reply #2 on: August 29, 2014, 12:50:04 am »
Ok so I'm not saying keep the ini, but in what way is it limiting?

It uses far less white space than xml.  It's quicker to parse than xml and it's easier to read by human eyes than xml. 

The limitations I had with it in the past had a lot to do with the fact that we still had to support windows 9X, which is no longer the case. 


If anything the xml is very limiting.  I didn't like it when we originally switched and as the years have rolled on and mame's own xml output has gotten more bloated and convoluted I like it even less.

It might make more sense, truth be told, to make controls.dat true to it's name and just make it a database.  Why put it in xml which has to be parsed into an array by any reader before it's presented by the program when it could already be in an array? The dynamic column numbers might be a bit of an issue, but most languages can handle that pretty well. 

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: dat redesign discussion
« Reply #3 on: August 29, 2014, 10:41:17 am »
Ini is limiting because it is difficult to make relationships and change. Xml can easily be change. Xml  parsing is not slow. In facx xml can be used like a database.

However, that's why I also suggest JSON. It has the same functionality as xml but much less text. It is not as human readable though.

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: dat redesign discussion
« Reply #4 on: August 29, 2014, 03:43:35 pm »
I need a refresher, what are the oddball things in mame?
I know there is a game that has different controls for 2nd player than 1st?
What uses a 49 way joy other than Blitz/Gauntlet/Midway games?

Also, how do I filter out non-arcade games?  Is it the ismechanical attribute?
<game name="jd_l1" sourcefile="wpc_dcs.c" ismechanical="yes" cloneof="jd_l7" romof="jd_l7">
« Last Edit: August 29, 2014, 03:46:49 pm by SirPoonga »

Yenome

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 547
  • Last login:March 24, 2024, 11:08:50 pm
  • Punch a fish. Make a wish
Re: dat redesign discussion
« Reply #5 on: September 05, 2014, 02:27:58 am »
I need a refresher, what are the oddball things in mame?
I know there is a game that has different controls for 2nd player than 1st?
What uses a 49 way joy other than Blitz/Gauntlet/Midway games?

Also, how do I filter out non-arcade games?  Is it the ismechanical attribute?
<game name="jd_l1" sourcefile="wpc_dcs.c" ismechanical="yes" cloneof="jd_l7" romof="jd_l7">

After playing with it for a day I noticed that when merged with the 141 controls romlister was outputting some control names in the old way. The old one wasn't being accepted as proper for Clrmamepro. if you tried to add it as a dat file it would tell you bad exe or you stopped the program. I found the issue when I compared this section with a new xmllist from mame 151. once I changed it all to the new way I was able to create and load a custom dat for just the games I want on my system. with the ability to check crc with clrmamepro for consistency. with out replace all instances of the old 141 with the one for 151 clrmamepro would not load the xml as a dat file and allow all my work I got done. I must say im excited to finally be able to make custom lists for hyperspin and clrmamepro with lil effort.

bikkuric is the game that first displayed this
Old way in 141
 <control type="joy8way"/>

new way that was accepted by 151
 <control type="joy" ways="8"/>

I know at some point I had read bout these changes but it has been a while. so not sure if you knew of this issue.
My Gf made me put a sig up. /whipped

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: dat redesign discussion
« Reply #6 on: June 22, 2015, 09:25:39 pm »
That's the toughest part about the redeign.  So many changes have been made since this has been last updated.  Good new is I finally got my db access back and made a backup.  So the next bit is if I stick with storing in a MySQL db it needs a redesign.  I am looking to see if there is a more modern way of storing the data.  Suggestions welcome.

ZeroQI

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 1
  • Last login:September 11, 2022, 06:46:05 am
  • I want to build my own arcade controls!
Re: dat redesign discussion
« Reply #7 on: September 03, 2016, 02:06:47 am »
This github project is 4 month old it seems https://github.com/yo1dog/controls-dat-json
He also posted there: http://forum.arcadecontrols.com/index.php/topic,150639.0.html

He wrote "I found the structure of the data in the controls.dat project a bit archaic, convoluted, and difficult to use. So I created a tool that will restructure the controls.dat JSON file in a way that (in my opinion) is much easier to work with. I think the JSON format makes this much easier compared to XML. I also expanded the structure so that more exact and meaningful information could be recorded. It also updates the way the MAME input ports are stored so it is compatible with the latest MAME (no more _EXT inputs)."

That seem to follow through the ideas mentionned (to me) so i thought i would post there to let you know...