Build Your Own Arcade Controls Forum

Main => Software Forum => Topic started by: Kaytrim on February 07, 2007, 02:10:50 pm

Title: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 07, 2007, 02:10:50 pm
I appreciate all the work to automate the maping of the Ultimarc 360 joystick.  Could someone take the same functionality and port it over to the GPWiz-49 from Groovy Game Gear?  Randy has a nice piece of support software (http://www.groovygamegear.com/GPWIZ49.zip) that maps the GPWiz-49 in a command line.  I just want it to be automated like what is being done for the U360.  I don't have a GPWiz-49 yet but I do have two 49-way joysticks that I will need interfaces for and ordering at least one soon.

I use GameEx but I am also looking at MaLa, MameWah and AtomicFE.  I would be willing to do some testing for you once I get setup.

Thanks to all you developers,  :cheers:
Kaytrim
Title: Re: Request for a plug-in / functionality for front ends
Post by: fatfingers on February 07, 2007, 03:07:17 pm

As the author of the U360 plugin for MaLa, I would be willing to take a shot at this since I assume much of the infrastructure would be the same.  I may need some help getting up to speed on the 49-ways however.
Title: Re: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 07, 2007, 03:27:36 pm
Thanks FatFingers,

This shouldn't be hard at all.  Randy has a text doc in the zip file that explains how to use the .exe.  I quote the following command lines from that document;

(DRS stands for Digital Restrictor Selection)

Automatic Mode:

Automatic mode was intentionally made to be very simple for integration into other software or in a shortcut as required.  The command line is just a number between 1 and 8 as follows:

GPWIZ49.exe 1
GPWIZ49.exe 2
...and so on.

The numbers indicate the DRS Modes as follows:

1= Raw49
2= Progressive49
3= 8-Way
4= 4-Way
5= Diagonals
6= 2-Way Horizontal
7= 2-Way Vertical
8= 16-Way

Looking at that it is just a matter of knowing the game requirements for the stick and pass the appropriate command to the exe.
Title: Re: Request for a plug-in / functionality for front ends
Post by: fatfingers on February 07, 2007, 03:56:03 pm

Hi Kaytrim,

Yes, it does look easy enough.  Do you see a need for overriding the mame default for control type?  Say like for Q*Bert that would show as 4-way, but really you might want diagonals?  If so, please propose a method to do that mapping and I will try to implement it.
Title: Re: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 07, 2007, 04:17:02 pm
There is a diagonal mapping built in, see option 5 above.  Or maybe I am not understanding you correctly.  How is the q-bert mapping handled for the U360?
Title: Re: Request for a plug-in / functionality for front ends
Post by: Space Fractal on February 07, 2007, 04:22:53 pm
Yep Q-Bert use option 5.
Title: Re: Request for a plug-in / functionality for front ends
Post by: fatfingers on February 07, 2007, 04:26:58 pm

Yes, I see there is a diagonal mode, but mame (and mala) will report the controls for that game as being 4-way, not diagonal.  So, there must be a way for the plugin to know that for qbert it needs to use diagonal instead of the 4-way that mame/mala told it to use.

In the U360 plugin we have the notion of map files (which are necessary to be applied by the UltraMap tool that the plugin uses -- similar to the 49way tool, but it takes a map file as a parameter and reads the mode to apply from the map file).  Since files were necessary for the U360 plugin to work the logic is to look for a game-specific file first, then the clone-of file, and finally the mame reported controller type.  The first one found is used.  It seems we need the notion of a 'map file' for this plugin as well, but what should the format be?  Should it just be a number?  Should it just be a string that is well-known and that the plugin can map to a number?

Is that clearer?
Title: Re: Request for a plug-in / functionality for front ends
Post by: Space Fractal on February 07, 2007, 04:57:35 pm
You could create a couple of bat files a same way you did with ugc files. Instead launching GPWIZ49.exe directly, you can simple launch the bat file (so this bat file can run the correct number).
Title: Re: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 07, 2007, 05:04:38 pm
I think a single coma delimited file or table file might do the trick.  First column will have the rom name, second column have the DRS number.  If the game is not listed in the file use the same logic as the U360.  Then all we need is someway to edit the file to tell the plugin what DRS to use for the odd games like q-bert, sinistar, etc.  Eventualy a master file could be created holding this information that could be distributed with the plugin.  I don't know how many of these oddball games there would be so I am not sure what the demands would be for searching the file.  If you see a more elegant or simple way of doing this feel free to use it.
Title: Re: Request for a plug-in / functionality for front ends
Post by: fatfingers on February 07, 2007, 05:14:50 pm
You could create a couple of bat files a same way you did with ugc files. Instead launching GPWIZ49.exe directly, you can simple launch the bat file (so this bat file can run the correct number).


At the moment I am liking this idea.  I'll think about it for a while before implementing it.  That will give other wise people time to propose their ideas.

Title: Re: Request for a plug-in / functionality for front ends
Post by: Havok on February 07, 2007, 07:28:46 pm
AtomicFE already natively supports the 49 ways. It will generate the settings from your mame executable, and you can then edit and override the settings to what you like after the fact, per game...
Title: Re: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 07, 2007, 07:33:53 pm
AtomicFE already natively supports the 49 ways. It will generate the settings from your mame executable, and you can then edit and override the settings to what you like after the fact, per game...

Does it work with the GPWiz and does it handle the oddball controller mappings like q-bert?
Title: Re: Request for a plug-in / functionality for front ends
Post by: millercentral on February 07, 2007, 08:29:33 pm
Note: Its already (kindof) possible to autoset the GPWiz-based 49-way sticks in MaLa. I do this today by using Sir Poonga's "set49mode" program (see: http://www.mameworld.net/tigerheli/set49mode/) -- I point to this in the "keyboard encoder" setting, with the config parameter set as "%rom%".  This works fine for setting the stick prior to launching the game. The only thing it doesn't handle is resetting the stick back to a MaLa friendly mode after you exit out of the game (ie, if I play Joust, it sets the joysticks to 2-way horizontal before launching Joust, but when I finish playing Joust and return to MaLa, the sticks remain in 2-way horizontal mode making it hard to select another game...)

I'd love to see a full-fledged plug-in solution similar to the excellent work done with the Ultra sticks, and I'd happily sign up as a beta tester if needed.
-james
Title: Re: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 07, 2007, 08:50:21 pm
millercentral, thank you for your support. :cheers:  Let's see if we can get Swindus or loadman to look into this.
Title: Re: Request for a plug-in / functionality for front ends
Post by: loadman on February 07, 2007, 09:07:12 pm
millercentral, thank you for your support. :cheers:  Let's see if we can get Swindus or loadman to look into this.

??  I vote FatFingers on this one Please  :notworthy:

He is a man with his hand on the stick    :notworthy:
Title: Re: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 07, 2007, 09:08:55 pm
He is a man with his hand on the stick    :notworthy:

That is a loaded statement.  :laugh2:
Title: Re: Request for a plug-in / functionality for front ends
Post by: fatfingers on February 07, 2007, 09:45:13 pm
He is a man with his hand on the stick    :notworthy:

That is a loaded statement.  :laugh2:

 :laugh2:  :laugh2:  :laugh2:

loadman, loadman, loadman...    ;)

In any case, I will try to start on this tomorrow.

Title: Re: Request for a plug-in / functionality for front ends
Post by: youki on February 08, 2007, 03:33:07 am
AtomicFE already natively supports the 49 ways. It will generate the settings from your mame executable, and you can then edit and override the settings to what you like after the fact, per game...

Does it work with the GPWiz and does it handle the oddball controller mappings like q-bert?

Yes, it is done for the GPWiz49 .  I don't know what you mean by oddball controller mappings. But anyway if the settings automatically generated by Atomic from your mame  isn't good for you for a particular game , you can easily modify it.

Title: Re: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 08, 2007, 09:12:15 am
AtomicFE already natively supports the 49 ways. It will generate the settings from your mame executable, and you can then edit and override the settings to what you like after the fact, per game...

Does it work with the GPWiz and does it handle the oddball controller mappings like q-bert?

Yes, it is done for the GPWiz49 .  I don't know what you mean by oddball controller mappings. But anyway if the settings automatically generated by Atomic from your mame  isn't good for you for a particular game , you can easily modify it.



Taking Q-Bert as an example it uses diagonals only instead of the standard 4-way map.  I think that Congo Bongo is another that uses diagonals.  According to fatfingers MAME shows the joystick as a 4-way not a diagonal joystick.  In this case we would need to tell the plugin to set the GPWiz49 to diagonal instead of the standard 4-way joystick. 

I don't believe that there are too many of these games that deviate from the standard joystick 4-way or 8-way maps.  With that in mind I think that an exceptions list would be the simple way to go instead of the batch files suggested above.  Youki, how do you handle these in AtomicFE?
Title: Re: Request for a plug-in / functionality for front ends
Post by: youki on February 08, 2007, 09:31:07 am
Quote
I don't believe that there are too many of these games that deviate from the standard joystick 4-way or 8-way maps.  With that in mind I think that an exceptions list would be the simple way to go instead of the batch files suggested above.  Youki, how do you handle these in AtomicFE?

Atomic generate a file with all settings for games, it looks like :

<romname>=<gpwiz49mode>

ex :
Code: [Select]
pacman=4
mslug=8
qbert=4

If the setting for a game is not correct, you just have to edit the file and change the appropriate row.
ex , if the example above , you have just to change :

qbert=4  to qbert=5    and you GPWIZ49 will be in Diagonal mode for qbert.

Title: Re: Request for a plug-in / functionality for front ends
Post by: fatfingers on February 08, 2007, 09:32:45 am
First the good news: I have the MaLa plugin working and can send it to whoever wants to try it out (it is about a 30KB .zip file).

Now the bad news (for Kaytrim): I used the batch file method.  I have included default batch files for standard modes and also for mala start, mala exit, and Q*bert.

PM me with your email address if you want to try this out.

Title: Re: Request for a plug-in / functionality for front ends
Post by: Kaytrim on February 08, 2007, 10:20:38 am
I am not quite setup to test yet.  I just put in an order with Randy for the cards I need for my sticks.  They should be here early next week.  I was working on getting MaLa, AtomicFE and MAMEWAH setup on my cab last night but got interrupted by my oldest daughter with computer problems of her own.

As AtomicFE uses this method already I think that it would be better to use the single file method that way it can be ported easily to the other front ends.  Then that file can be standardized and maintained easily for everyone's benefit.   I am just trying to think big picture and not for each front end individually.