The NEW Build Your Own Arcade Controls
Main => Software Forum => Topic started by: SirPoonga on September 16, 2005, 12:47:27 pm
-
I am creating a command line app for you folks. I will get it up on fe.donkeyfly.com as soon as possible. But for now I want to run the idea by you.
First, this project comes out of the fact that I might be getting some 49ways and a gpwiz49 soon. I use game launcher and want it switch modes according to controls.dat. So I need some command line utility to do this.
So last night I started coding on this. I am determining the bext xml parser to parse through listxml. And I have to make a setup UI for it. Other than that it works with hardcoded values.
Note: .NET 1.1 framework will be needed.
The utility will first grab the DRS mode from an override.ini file. This allows you to specify a DRS mode for a particular game, regardless of what controls.dat or mame says.
If that fials then it will grab DRS mode from controls.dat information.
If that fails then from mame.
If that fails (like neogeo does not have an input tag) then a default (which you configure) will be used.
I am thinking everything will be stored in ini files, but there will be a GUI to set everything up. You shouldn't need to modify the ini files by hand. But the option to do that will be there becuase the GUI will be for mame only. With everything in ini files you can easily modify them to work with other emulators. But, in theory, what ever works for mame will work for zinc now if you use commandline wrappers for zinc.
What ini files I am currently using/generating.
controls:
DRSModes.ini - actually, here's what that file is
[DRSModes]
Raw49=1
Progressive49=2
8-Way=3
4-Way=4
Diagonals=5
2-Way Horizontal=6
2-Way Vertical=7
16-Way=8
mame_modes.ini - this will map mame cotnrol constants to the above DRSMode
controls_dat_modes.ini - this will map controls.dat control descriptions to the above DRSMode
override.ini - see above
settings.ini - Duh, stores file locations, default DRSmode, etc...
controls.ini - controls.dat ini version
gamemodes.ini - this is the file the setup GUI generates, it's a romname = DRS mode
And the program will need output from mame's listxml.
Usage:
set49mode version 1.0.2085.18318
Usage:
set49mode -?
set49mode -help
Prints this
set49mode [-setup]
Starts setup GUI. -setup option not needed, obsoleted.
set49mode romname
Execute GPWIZ49.exe with DRS Mode set to value stored in gamemodes.ini.
set49mode romname -showDRS
Displays DRS mode for romname from gamemodes.ini.
Note: This will not execute GPWIZ49.exe
Yes, an obsolueted command line option already. Originally I had no command line option display the usage and -setup to start setup. But I figure some people will double click the exe and wonder why a command line flashed for a moment.
Like I said, it's working with hardcoded values.
I need to create a setup GUI to setup the paths and such so they aren't hard coded.
Note, this is a command line app soo when you double click it a command window will start and then the setup GUI.
I also need to check out different XMl parsers, but since the only time listxml is parsed will be when you exit the Setup->Paths to refresh the left list (see next paragraph) and when you generate the gamemodes.ini file. It is not needed when setting DRS mode to gpwiz49 as it gets the DRS mode from gamemodes.ini. So speed isn't a big issue. The XmlWrite in .NET seem to be pretty decent.
I attached an initial layout for the setup GUI.
The main window will have the usual two lists layout to transfer games from listxml on the left list to override list on the right.
Also, since I currently don't have a gpwiz there's really no way to make sure all this will work. But it does run gpwiz49.exe with a DRS mode as an argument so it should work.
-
Thanks for working on this! It will help a lot on my new cabinet as Im using 49 ways as well. Just a couple of questions:
Why use .ini files when you already have an XML parser? Why not just use XML for everything?
You mention "Zinc" twice. What are you refering to? It's not Zinc from Multidmedia?
If there is anything I can do to help, feel free to ask. My current job has me doing C# pretty much full time.
Thanks again!
Mike
-
Because XML parsers are too slow. I don't need the entire data set from controls.dat, just P1Controls first control listed for whatever rom.
And because of mame I am forced to use XML.
When this runs it has to be fast because I want lag time from when you select a game in the FE to when mame starts to be minimal. Ini is fast and built into windows.
Plus what I am working with is simple key/value pairs, xml adds alot of overhead for something as simple as that. Romname=DRSmode. That's pretty much what is in the ini files.
Plus this allows most people to be able to modify the files for other emulators. People understand how to edit an ini file better than xml.
Compare
<xml>
<drsmode rom="pacman" mode="4-Way"/>
</xml>
[DRSModes]
pacman=4-Way
Frankly, the ini way is easier to understand for most people.
I know several people who have been turned off of the ctrlr files since they went xml because of how much more complex it is to write them.
I originally was going to store all the data in either an access or sqlite database. But I decided to go ini so people can hack the program to whatever emulator.
When I am done I will probably release the code, if someone wants to modify it to use only xml files and send it to me I will do that.
Zinc is an emulator
http://www.emuhype.com
FYI, I meant XMLReader, not XMLWriter like I originally post :)
-
When I am done I will probably release the code, if someone wants to modify it to use only xml files and send it to me I will do that.
Please and thanks. Would like do something similar and could always use a starting point for a new language. Actually, plan to try to use sqlite myself too. ;)
Your using C# right?
-
Yes, using C# because I have to start learning.
-
Yes, using C# because I have to start learning.
Ditto
-
I have noticed XmlTextReader in Visual Studio 2002 is much slower than 2003. 2003 is not that bad, no worse than an expat demo I tried.
-
Personally, I prefer XML for more reasons then I care to list, but I was just curious about the INI suggest, not arguing with your choice :)
Would you be willing to upload one of these XML files that you feel are very slow to parse? Maybe the game list? I don't have access to MAME here so I can't get it my self but I'd really like to see it. Thanks!
Mike
-
Would you be willing to upload one of these XML files that you feel are very slow to parse? Maybe the game list? I don't have access to MAME here so I can't get it my self but I'd really like to see it. Thanks!
Mike
Where would you like it uploaded, it's almost 20MB? Here is a sample of one game:
SirP edit: Took out listinfo code to make thread look nice for low resolution user :(
Now multiply that by about 5000, one for each rom.
-
I don't have an xml file for the drsmodes of each game.
Like I said,it's just key/value pairs. And since reading and writing ini files is built into the windows kernal I don't have to write anything to get the information from the file, it's already done. And it's fast.
I prefer xml too, but like programming langauge, use the tool that makes sense for the situation. That's why I created both an ini and xml file for controls.dat. The xml file is great for FE devs that are going to integrate it into their FE, because generally they will store the info in their own formate compined with other info form catver, history, etc.. But to get one little piece of information amonst all the information that is available the ini version is faster.
-
2600, modernize yourself, please :) That's listinfo, not listxml.
SirP edit: Took out listxml code to make thread look nice for low resolution user :(
-
I wanted to point out what I said before, I don't care about speed of controls.dat and listxml parsing so much because it is in the setup program. XMLTextWriter is doing a good enough job.
I elected to use the ini version of controls.dat because all I need from that is P1Controls first control listed. Much faster to get at that one piece of information using something built into the windows kernel than through an xml parser.
Also, for each game in listxml I could possibly beparsing through controls.xml three times, for romname, if no romname then romof, if no romof then cloneof.
-
2600, modernize yourself, please :) That's listinfo, not listxml.
What the freak was I doing? Don't know why I even have the listinfo. ::)
-
I'm not sure if I fully understand how this will be used.
- Set49mode.exe will be set as an emulator instead of Mame in GameLauncher.
- When you select PacMan, GameLauncher runs 'set49mode pacman'
- Set49mode checks controls.dat to see what GP49 mode PacMan sould have, then sets your GP49(s) to that mode, then runs 'mame pacman'
Am I right?
-
no, set49mode does not run mame.
It is not meant to be specific to GL.
You will need to have GL run a batch file to to execute set49way and mame.
The batch file would have to be in the mame folder. It would look something like this assuming the first argument sent to the batch file is the romname.
echo off
c:\set49mode\set49mode %1
mamepp %1
A well setup mame with mame.ini files doesn't need commandline arguments, though you just change the mame line and append '%2 %3 %4 %5 %6" to allow 5 more command line arguments.
-
note:
set49mode romname -showDRS
This is just a debug tool for the most part. SINCE the modes are viewable in the ini file this is useless to most people. I am using it to make sure the right mode is returned instead of running gpwiz49. It's the same function just outputs the mode to commandline instead of running gpwiz49. Since I don't have a gpwiz49 yet....
-
Thanks for posting the XML sample :)
What started as mild curiosity on the INI file has turned into a performance question. I've never really had any issues with XML processing performance in C# and so I wanted to give it a shot. I duplicated the node you gave me until I had 6,000 of them (XMLSpy started giving me some trouble here so I had to write a program to do it for me). This put the file size at about 20 megs.
At this point I fired up visual studio and hacked out some code that iterates through all that XML and snags a few values (game name, description, control type). I take those parts and throw em into a stringbuilder just to store em all in a nice display. This is a performance expensive operation with all the concatenation. Total time to execute that? Consistently around 1.1 seconds on my P4 - 3ghz machine (with many apps open).
For kicks, I went ahead and changed the source XML from 6,000 to 100,000 game nodes. This comes in at 330 megs. Total parsing time + concats? 18 seconds. .NET XML parsing is FAST.
-=-=-
Ok, enough off-topic stuff from me. Thanks again for creating this app. It will prove most helpful!
Mike
-
Sounds good to me - and thanks for coding this.
-
Like I noted, VS 2002 XMLTextReader is much slower than VS 2003. Unfortunately I have 2002 at home and 2003 at work. At home set48way takes <20 seconds to parse listxml (along with using controls.ini to find control info). At work on 2003 it takes less <3 secsonds.
At home I have an AMD64 3200, at work a P4 3Ghz.
But for the part where speed is concerned listxml and controls.dat isn't even part of that. That's the gamemodes.ini. That just contains key/value pairs like
pacman=3
ddragon=5
dotron=1
For something as simple as that I might as well use the built in ini api, less programming for me and pretty fast execution.
But then you do have to remember most people's arcade machines are around the 1Ghz range or even less.
-
VS 2002 XMLTextReader is much slower than VS 2003
XMLTextReader isn't part of Visual Studio, it's part of the framework itself. I'm assuming you mean 1.0 vs 1.1?
built in ini api
I'm not familiar with this in .NET? I know people use interopt and wire up Kernel32.dll if they need legacy INI support but is there a built-in API already? Thanks!
Mike
-
VS 2002 XMLTextReader is much slower than VS 2003
XMLTextReader isn't part of Visual Studio, it's part of the framework itself. I'm assuming you mean 1.0 vs 1.1?
nope, 1.1 installed on both machines. I doubt the difference between an amd 64 3200 and P3 3Ghz would be that different.... And because it is part of the framework is why I find it odd.
Wait, it's probably memory, I only have 512megs at home, 1gig at work.
I'm not familiar with this in .NET? I know people use interopt and wire up Kernel32.dll if they need legacy INI support but is there a built-in API already? Thanks!
Built in as in windows api, the kernel32.dll.
-
Alright, I wanted to document here a little on how this will work (basically reminding me what I need to put in the readme file).
First, I took a lazy way out. I don't have guis to manage the ini files, I have menu options to open the ini files. They hardly ever change so it wasn't worth the effort.
On ini file that will probably not change unless Randy adds more mode is DRSModes.ini
[DRSModes]
Raw49=1
Progressive49=2
8-Way=3
4-Way=4
Diagonals=5
2-Way Horizontal=6
2-Way Vertical=7
16-Way=8
Pretty self explainatory. In theory if a new mode is added just add it hear and start using the name in the other files.
I will need controls.dat to generate a controls_dat_moses.ini file when a new version is added. However, since I don't have a gpwiz49 yet I am going to have to guess at what modes are best for what controls.
This file is basically all the control names in FEDEV_descriptions_to_controls.txt from the FEDEV package for controls.dat.
To give you an idea, this file looks like
[CONTROLS]
Just Buttons=8-Way
2-way Joystick (Horizontal)=2-Way Horizontal
2-way Joystick (Vertical)=2-Way Vertical
4-way Joystick=4-Way
Diagonal 4-way Joystick=Diagonals
...
49-way Joystick=Raw49
...
Flightstick (Analog)=Progressive49
Lightgun=8-Way
Analog Gun=Progressive49
...
As you see, you assign the control the key name form DRSModes.ini. yeah, very database like, I know. But I know people aren't going to memorize the number so this will make it easy to figure out what's going on.
Simularly mame_modes.ini takes all the mame control constants (at least the ones I found in listxml) and assigns a DRSMode. Again, since I don't have a gpwiz49 yet the default modes is not final. But since it is an ini file, the purpose of it being an ini file, you can change it to your liking. Yes, before you even ask, there is no joy2way in mame. They default the games to joy8way (hence on of the reasons controls.dat exists). It serves two purposes for them to do it that way, it saves two bits which is why I think they did that in the first place, ran out of bits for something. But also it covers for horizontal and vertical games.
[CONTROLS]
joy4way=4-Way
joy8way=8-Way
trackball=8-Way
doublejoy8way=8-Way
dial=8-Way
paddle=Raw49
stick=Progressive49
lightgun=Raw49
doublejoy4way=4-Way
The final ini file you will want to edit is the override.ini file. This lists games you want to force to a certain mode. Example:
[CONTROLS]
puckman=8-Way
Ulitmately then the setup programs generates a gamemodes.ini file that looks like
[MODES]
puckman=3
puckmana=4
puckmanf=4
puckmanh=4
pacman=4
pacmanf=4
puckmod=4
pacmod=4
newpuc2=4
As you see, the override.ini works.
The program is working and pretty much ready for public. I'm having a couple of issues with fe.donkeyfly.com. I will upload files when I get a chance.
Note: Being that this is driven off of ini files you should be able to adapt it to any emulator. Though how many emus have different control layouts? mame is the only one that comes to mind. Zinc is all 8way games. Neogeo, except for 2 games, is all 8way. same with CPS1 and CPS2, so that covers neoragex, nebula, and kawaks.
console emus should be 8ways.
Anyhow, if the situation occurs it shouldn't be too hard to manually edit the files to make them work for other emulators.
I attached a new pic of the setup GUI.
Note: Everytime you click on generate or setup the settings ini files are reloaded. Especially since now I just tell the computer to open the default app for the ini file. You could have moved or changed some setting using notepad or what have you outside of the program. So these two events need the latest setting info. Don't worry, it takes no time to do this. It basically just refreshes the paths to the ini files.
-
is there a way to make this thread fit in a window like normal? It all long and to read it I have to scroll left to right, left to right.
So I Am unable to tell if this application is up, running and availabe or not.
Either way it sounds like a great idea.
-
Fixed, there was some code being quoted that would cause you low resolution users issues.
-
Timoe - Get a bigger screen - thread looks fine at 1152x864 . . . <puts on flame suit>
SirP - Could you give some help for the DOS-challenged?
If I am reading correctly, the program doesn't do an active lookup, right? In other words, I run Set49 mode, it creates gamemodes.ini, and I use it (gamemodes.ini) in my batch file? Then when MAME or Controls.ini updates or RandyT adds a new mode, I run Set49 again to build a new gamemodes.ini file. I don't call set49mode from the batch file and have it find out what the game mode is, or do I?
What I want is a batch file that updates the 49-way software and then launches MAME (and then maybe sets it back to 8-way.
So for Pac-man - I would send "Batch1 Pacman" and Batch 1 would have -
cd\
cd gpwiz
gpwizware 4 (but how does it get the value 4 from gamedata.ini)
cd\
cd Mame
mame %1
cd\
Cd GPwiz
Gpwizware 3
exit
My question is should there be a line(s) before line 3
setmode49 %1 and this parses gamedata.ini and returns 4 and then some variable should be inserted in line 3?
Or is there a routine that will parse gamedata.ini and then how do I pass the value to line 3?
-
TigerHeli, I already posted the batch file you run instead of mame.
echo off
c:\set49mode\set49mode %1
mamepp %1
You don't need the echo off but I like batch files to run clean once they work :)
Minimum steps to get this working.
1) Download controls.ini and gpwiz49.exe
2) generate a listxml file (mame -listxml > listxml.xml)
3) double click set49mode to start setup GUI
4) Setup path locations in the GUI to the above files
5) Then generate the gamemodes.ini.
Now set49mode is ready to use. set49mode will run GPWIZ49.exe with the mode specified in gamemodes.ini for the romname passed to set49mode.
So, when the above batch file runs you will get the lines
c:\set49mode\set49mode pacman
mamepp pacman
set49mod ewill execute GPWIZ49.exe with the DRS Mode from gamemodes.ini.
Then mame will run. This assumes this batch file is int he same folder as mame, otherwise cd as needed.
I believe batch files are synchronous, meaning they will wait for one command to finish executing before running the next, so that should work.
Edit: You don't need controls.ini, but then all your control information will come from listxml and that isn't the purpose of this program :)
-
If I could upload a zip file I would let you try it. But until I can figure out what's wrong with the site.
TigerHeli, PM me your email, i'll send you a test version.
-
Now working fine for me, but, um, you've got more E-mail . . .
-
moving discussion
http://fe.donkeyfly.com/forum/index.php?topic=168.0
webgeek, if you wouldn't mind sharing your parsing code so I can see how it is done?
-
I know that the topic has been moved but, I cant wait till I get my CP set up so that I can try this.
I thinks its great that you're doing this by the way.