Bribery for new Mame feature "Shifter Toggle" Help...

[Xiaou2]

 Ive noticed that mame has a real problem with shifter games if you try to use a real arcade shifter with them.   This makes playing great games like  Spy Hunter, Turbo, Outrun...and more almost impossible with a real arcade shifter.

 Ive decided to post on mame board, which is currently asking for donations for the Dumping project:

==========
 Instead of begging.. I will try bribeing

I will donate 100$ to the project if a dev makes a way to allow a 'toggle' mode for shifter games.

For example:

Spy Hunter now works with pressing one key and releaseing it for shifting up.. and to shift down, you have to do the same.

However, If hooking spy hunter up to a real arcade shifter, this does not work, because the switch is HELD DOWN, either Always on or held always off. Currently, Youd have to press up + down to shift high, then up + down to shift low... which messes the gamplay timing up.

Understandably, keyboards might not react well to a key being held down all the time. However, using a joystick button, mouse button, num lock, scroll lock, or even the tab key, (should you choose to remap the menu function) all would seem fine for this.

Simularly, games like Daytona Usa, have a 4 way shifter which has four switches. However, once a switch is 'on'.. it stays held on, untill the shaft is moved into another position. These games also need the 'toggle mode', for true shifter support.

Maybe press and hold the key/button for 3 seconds, will change it to a 'toggle' type button in the controller Menu?

Let it be known that Ive donated in the past without asking for anything, and will again. However, a little incentive never hurt either

Planning to rebuild a cabinet soon, and this is a very needed features. A lot of people are having trouble with this, and would love this feature. Im pretty sure I could get others to join in with the funds for this as well.

May not be a lot, but its all I can afford for now.

Thanks for all the great work.

Anyone up to it?

Thanks


=========

 Anyone else care to join (that is willing to make a simular large as you can afford donation?) ?

 Please post on the mame message board.

 If you wish to donate regaurdless, maybe you can say that you will donate "More" later,  should the feature be added.  Or just plain donate anyway - at least this is an advertisment if all else fails

 

[Minwah]

I would settle for the shifters being handled as per the original games (currently some are, some are not).  However mentioning this to MAMEdev is pretty much futile.  I think your 'bribe' will also be futile.  I would love to see this taken care of also, but I wouldn't donate solely for this as in principal (arguably according to MAME's own goals) it should be done regardless.

[Silver]

well it would be nice for some change of some description to be done...

I think the codes already out there (for some games anyway).

Anyone have a link to the code for patching this in various games? I used to have the pole position patch source patch....

[Xiaou2]

 Minwah,

  I agree, that games should be handled as they are meant to be.    Id be currious to see which games handle the shifter correctly, as most Ive seen do not.   Ill have to double check.   If anyone knows offhand, or has a list, it would be appreciated.

 I would love to donate more to the funds on principle.  However, being that I cant really afford to be so reckless with my funds.    I have to have personal incentive to be more reckless than usual..   and this is the way I can live with it... as its worth it to me.

 People asking for features may be futile..  but to offer a donation in return.. I do not think its so bad.  Im sure it may have been done behind closed doors before.

 Its a lot less scandelous than the paypal for capcom decryption thing that went on... and well.. that got results.. even though they werent quite the best results...
Still, it prooves a point that money moves the world. (sadly)

 Imagine if all of 200,000 mame users donated 3$ a month to a single dev.  Most likely, that dev wouldnt need to work.  He be free to spend 24-7  on nothing but mame. ..    But, how would something like that happen?    Not by people thinking that its Futile.       

 Lets be realistic...  A lot missing donations are more to do with lack of interest than lack of funds.   

 While Im not condoning a massive bend twords money for driver/features..  Im not saying that a few here and there wouldnt hurt productivity either. (in both mame improovment, and boards purchased)

 I say, theres nothing wrong with requesting a feature like this.    Its a win win for all parties.

 And yes, I have donated in the past.  For the simple passion of preservation. 

 While devs and I may have different ends in our passions.. they do cross paths

 I have the utmost love for the Devs genious and hard work.    Not forgetting the tireless efforts of the Guru.. and all the others who help to make Mame the great program that it is.

 
 
 

[tetsujin]

While I'd love to see this and a number of other reforms to how Mame handles miscellaneous input and output (many of which have been implemented already, but aren't being integrated), I have to say it seems like it'd be an incredibly easy thing to fix at the hardware level.  Just create a circuit that generates "shift up" signal pulses when the shifter is shifted up, and "shift down" signal pulses when the shifter is shifted down.

It's not a perfect solution, but I think it'd probably be "good enough" in lieu of a software fix.

[daikiki]

Would you be able to change the shifter to a momentary one by mounting a capacitor inline with the switches that the shifter depresses? Just a thought.

[tetsujin]

Would you be able to change the shifter to a momentary one by mounting a capacitor inline with the switches that the shifter depresses? Just a thought.

I'm not sure what you mean by this, exactly.  You mean have a cap in series with the switch?  What would that do?  When the switch is closed, the cap charges to saturation.  When the switch is open, the cap doesn't change state.  (Or have I misunderstood?  I switched to Comp Sci. after my first year of Electrical Engineering...)

Plus there's the possibility that a pulse will be issued but (for whatever reason) the computer will miss it.  This is why my suggestion was for the shifter circuit to generate a continuous stream of pulses.  If you shifted the shifter "up" while the computer was off, or the game wasn't running, or whatever, then it'd continue sending the "shifter is up" signal as long as the shifter is up, and as soon as the PC is listening properly it'll get the signal.  (The main problem with that approach is that some software on the PC-side may be attempting to issue interrupts when there's a state change, or keep a history of rising and falling edge events - in which case if the pulses are too fast the PC will waste a significant amount of time processing the events.  This probably works better with a gamepad-type interface rather than a keyboard encoder.)

[PetitMorte]

Just create a circuit that generates "shift up" signal pulses when the shifter is shifted up, and "shift down" signal pulses when the shifter is shifted down.

For a lot of the games, mame toggles between hi and low on one keypress.  So the circuit would want to send a keypress when the switch is pressed, and send the same keypress when the switch is released.

Pole position, and Spy hunter would both use this kind of on=low off=high shifter.



How about this for a solution...  Connect both the NO AND the NC connectors from the switch to the key input.
That way it sends a signal when the switch is pressed, and stops and then sends it again when it is released.
Of course, then you'd have a key that is constantly pressed, and that might cause problems.  In addition, Mame would never "know" what position the shifter is in...

Please let me know why that wouldn't work.

[ahofle]

I will see your $100 for the shifter feature, and raise you $200 for fixing the Joust pixel bug and getting Gorf working again. 

[thebrownshow]

Not to be a total wiseass here, but for that much, you could just take a programming course and fix it yourselves

[RetroBorg]

Why not just use one these type of shifters?



Makes switch contact in low and high position and returns to center .

[Mario]

Why not just use one these type of shifters?

...

Makes switch contact in low and high position and returns to center .

This is exactly the type of shifter I'd prefer to use. I mentioned this in a thread a long time ago (http://forum.arcadecontrols.com/index.php?topic=29658.0). With a return-to-center type of shifter, any game can be supported. And if this was supported, you wouldn't even need this special type of controller. You could just use a standard joystick. A cheap solution if one desired it. Is this currently supported in MAME? I haven't been keeping myself up-to-date.

What I'd like to see is a config option for MAME which tells MAME what type of shifter you have installed, and then MAME can adjust itself accordingly.

Mario

[RobotronNut]

Why not just use one these type of shifters?
...
Makes switch contact in low and high position and returns to center .

This is exactly the type of shifter I'd prefer to use.
...
you wouldn't even need this special type of controller. You could just use a standard joystick.

for 2-gear games, a regular joystick should work, and for 4-gear games, a 4-way-restricted joystick mounted in Qbert orientation might work nicely. these sticks would return to center, so all contact would be momentary. they would thus play nicely with mame, as currently implemented, and with front ends.

the feel of return-to-center sticks would be quite different from the feel of stay-in-place sticks. how this works out in actual game play is probably a matter of personal taste.

[Xiaou2]

 Thats the issue.  These games do not feel right using the momentary type of shifter.
Some people may find them ok.. but I persoanlly, and Im sure many others would agree that they stink comparitively.

 Thanks ahofle.   Please post on mame site to add weight to the post

 As for the programming comment.. my brain is limited in such a complex capacity.  Sometimes I wish it werent like that.. but. we all have our strenghts and weaknesses.. and programming is beyond my capability.

   

[Minwah]

How about this for a solution...  Connect both the NO AND the NC connectors from the switch to the key input.
That way it sends a signal when the switch is pressed, and stops and then sends it again when it is released.

This should work, as long as there is a moment of 'off' between NO & NC.  And the shifter would work in either position at startup, but it might not match the hi/lo labelling of the shifter itself (not the end of the world, but a bit irritating).

[Minwah]

With a return-to-center type of shifter, any game can be supported.

But for some games (eg Chase HQ) where you have to hold a button down to stay in low, you would have to hold the shifter in the lo position and let go to engage high.  So it would work but far from ideal.  And for the other games (Pole Pos etc.) I agree with Xiaou - it wouldn't really feel right.

[Minwah]

As for the programming comment.. my brain is limited in such a complex capacity.  Sometimes I wish it werent like that.. but. we all have our strenghts and weaknesses.. and programming is beyond my capability.

There are plenty of programmers here...maybe we should look into it.  I don't program in C but maybe with a bit of looking around the Pole Pos and other drivers it might be possible.

Now from what I've seen games with a hi/lo shifter are handled in three ways:

1) Toggle (eg Pole Position) - 1 input
2) Hold input for low, release for high (eg Chase HQ) - 1 input
3) Input for low, input for high (eg Outrun) - 2 inputs

I think these should all be handled in the same way for our purposes.  This needs a bit of thinking but I reckon having an input for low and an input for high is the way to go (as per 3 above).  This way it would work with momentary shifters (2 seperate microswitches presumably) and 'locking' shifters (eg NO for low, NC for high).  4 speed (digital) shifters would work in the same way for these games as hi/lo locking shifters.  I think this is the method with the least problems...the only potential problem I can think of is with locking shifters sending a constant keystroke, but if neccessary this could be worked around with a physical switch on the ground to the shifter.

[Minwah]

As for the programming comment.. my brain is limited in such a complex capacity.  Sometimes I wish it werent like that.. but. we all have our strenghts and weaknesses.. and programming is beyond my capability.

There are plenty of programmers here...maybe we should look into it.  I don't program in C but maybe with a bit of looking around the Pole Pos and other drivers it might be possible.

Now from what I've seen games with a hi/lo shifter are handled in three ways:

1) Toggle (eg Pole Position) - 1 input
2) Hold input for low, release for high (eg Chase HQ) - 1 input
3) Input for low, input for high (eg Outrun) - 2 inputs

I think these should all be handled in the same way for our purposes.  This needs a bit of thinking but I reckon having an input for low and an input for high is the way to go (as per 3 above).  This way it would work with momentary shifters (2 seperate microswitches presumably) and 'locking' shifters (eg NO for low, NC for high).  4 speed (digital) shifters would work in the same way for these games as hi/lo locking shifters.  I think this is the method with the least problems...the only potential problem I can think of is with locking shifters sending a constant keystroke, but if neccessary this could be worked around with a physical switch on the ground to the shifter.  Edit: this wouldn't even be a problem if the shifter has a 'deadzone'...I know my Atari 4-speed for example does.

[PetitMorte]

Now from what I've seen games with a hi/lo shifter are handled in three ways:

1) Toggle (eg Pole Position) - 1 input
2) Hold input for low, release for high (eg Chase HQ) - 1 input
3) Input for low, input for high (eg Outrun) - 2 inputs

I think these should all be handled in the same way for our purposes.  This needs a bit of thinking but I reckon having an input for low and an input for high is the way to go (as per 3 above).  This way it would work with momentary shifters (2 seperate microswitches presumably) and 'locking' shifters (eg NO for low, NC for high).  4 speed (digital) shifters would work in the same way for these games as hi/lo locking shifters.  I think this is the method with the least problems...the only potential problem I can think of is with locking shifters sending a constant keystroke, but if neccessary this could be worked around with a physical switch on the ground to the shifter.  Edit: this wouldn't even be a problem if the shifter has a 'deadzone'...I know my Atari 4-speed for example does.

The funny thing is, even though MAME handles Pole Position as a type 1 shift, the origional shifter hardware from a pole-position machine functions in Type 2 mode!

[Flinkly]

well i've got a shifter that is the four way type that engages the buttons...ala happs 4 speed shifter (type three).  it sounds like minwahs idea is good, but would i add a cap or something in line to cut off the switch?  or replace with another switch?

sounds like we need a mame patch.

[RobotronNut]

how about a simple hardware solution? if i understand correctly, mame currently expects momentary button presses in all cases, but some games play better with stay-in-place shifters.

if each microswitch in a 2-pos or 4-pos stay-in-place shifter were connected to a "one-shot" or "monostable multivibrator," you would get a single pulse, starting each time that switch is closed, and lasting for a user-definable duration. thus, your stay-in-place shifter would be simulating momentary button presses.

you can get 2 one-shots in a single TTL chip (74123, 74221, or 74423), so a 2-pos would need one chip, and a 4-pos would need 2 chips. you'd also need a few resistors and capacitors and access to +5V somewhere inside your panel. it would probably be even cheaper to use a very inexpensive microcontroller with a few lines of code.

i don't know if there'd be enough business for one of the vendors out there to take on this project.

[Minwah]

if each microswitch in a 2-pos or 4-pos stay-in-place shifter were connected to a "one-shot" or "monostable multivibrator," you would get a single pulse, starting each time that switch is closed, and lasting for a user-definable duration. thus, your stay-in-place shifter would be simulating momentary button presses.

Sounds like it should work, but then there are games of 'type 2', which wouldn't work with this.  Also, you lost me with the hardware talk so I wouldn't want to have to build such a project.  I think a software solution is best/simplest unltimately...

[Silver]

Based on what has been said here, I believe there is NO hardware solution that can solve all the problems.

The problem is that the games in mame that use a shifter are configured differently. So you can make varios harware circuits to adapt different shifters to work in different situations (such as get a momentary to work as a 'held down' type, or vice versa. Or even the No/NC double wire up - but there are still games in every case that don't work correctly.

You could solve this by having a circuit that is ALSO controlled by software, so that it acted differently depending on which game you are playing (say get a frontend to activate it before launching the game) but if you are going to the trouble of a custom program, why not just mod mame?

Also, it would probably be viable to have a solely software solution - such as back ground program written to monitor for your "gear up" signal and then either send a always on signal or a momentary signal (ie get the effect of a custom circuit soley through software). Bit crude and hacky though.

The best to expect from mame is for authentic modelling of the original game. Has anyone done this and submitted the fixes? It appears the changes are not huge in this respect (I say this not being much of C programmer).

[MikeQ]

What about adding this "circuit" (or software behavior) to a key-wiz.  Since the key-wiz is programmable, you can program the desired behavior of the input attached to the shifter to match the game.  Then when a game is selected, a config file or something describes the desired behavior and you program the key-wiz accordingly.

[Mario]

With a return-to-center type of shifter, any game can be supported.

But for some games (eg Chase HQ) where you have to hold a button down to stay in low, you would have to hold the shifter in the lo position and let go to engage high.  So it would work but far from ideal.  And for the other games (Pole Pos etc.) I agree with Xiaou - it wouldn't really feel right.

My key point is that Mame must support the setup. The Mame code should be written so that if a momentary contact shifter/joystick is used and the game ROM requires a constant contact, then the Mame code should tell the ROM code that the contact is still closed. I.e., Mame translates one type of control to another. Mame already does something similar in allowing a joystick to be used in place of a trackball.

Mario

[Minwah]

The best to expect from mame is for authentic modelling of the original game. Has anyone done this and submitted the fixes? It appears the changes are not huge in this respect (I say this not being much of C programmer).

Several people have tried (me included)...they are not interested   For example look at Pole Pos...the authentic/accurate version is in the driver but not enabled, basically because the way they have it is easier for keyboard users to play with.

So much for 'MAME is about accuracy' 

[RobotronNut]

of the 3 software implementations:

1) Toggle (eg Pole Position) - 1 input
2) Hold input for low, release for high (eg Chase HQ) - 1 input
3) Input for low, input for high (eg Outrun) - 2 inputs

i'd prefer #3 for all cases. if you're playing from a keyboard, you have a momentary button press for each shift, with a different button for each gear, which i think is the most natural way to play. if you're using real arcade controls, you can use a return-to-center shifter or a stay-in-place shifter with hardware to make it emulate a return-to-center shifter.

this is simple and uniform for the mame developers, and it avoids having "always-on" keys, which might cause problems with front-ends or O.S. drivers.

originally, i thought mame was already implemented with all games using #3. since this apparently is not the case, i think all games should be changed to use #3.

[Minwah]

i'd prefer #3 for all cases. if you're playing from a keyboard, you have a momentary button press for each shift, with a different button for each gear, which i think is the most natural way to play. if you're using real arcade controls, you can use a return-to-center shifter or a stay-in-place shifter with hardware to make it emulate a return-to-center shifter.

Yes, that's what I was saying above (reply #17).  Although you do not need to make a locking shifter return to centre as you say - leaving it in position will work fine.  The only potential issue is sending constant keystrokes which shouldn't normally be a problem (in MAME)...I commented further on this above.

this is simple and uniform for the mame developers, and it avoids having "always-on" keys, which might cause problems with front-ends or O.S. drivers.

Agreed, but with a locking shifter this might happen anyway.  I don't think anyone should have to modify their shifters if possible (as someone said, return to centre ones don't feel right for some games).  A simple switch on the ground line would solve this issue anyway.

originally, i thought mame was already implemented with all games using #3. since this apparently is not the case, i think all games should be changed to use #3.

Agreed.

[Silver]

I forgot that Polepos had the code in the driver and it just needs a recompile.

So seeing as mamedev appear to want to leave it as is (or are uninterested or whatever) how about the next best thing - lets get all the games to have the code available in  the driver.

This would make it easy for anyone to just edit a line of code per game to switch the control setup. Also having the code for the correct shifter for each game would improve the "documentation" aspect. Of course, the next logical setup would be having code in there for support #3 type that you mentioned above, even if the original game was not. But sounds like mame already is like this for a keyboard point of view?

[RobotronNut]

this is simple and uniform for the mame developers, and it avoids having "always-on" keys, which might cause problems with front-ends or O.S. drivers.

Agreed, but with a locking shifter this might happen anyway.  I don't think anyone should have to modify their shifters if possible (as someone said, return to centre ones don't feel right for some games).  A simple switch on the ground line would solve this issue anyway.

the hardware modification i'm suggesting would just be a small circuit board; the locking shifter would not be modified mechanically. it would still feel and play like a locking shifter. the shifter's microswitches would be connected to the circuit board, which would be connected to the keyboard encoder. mame (and the o.s. and front ends) would see momentary keystrokes, rather than always-on keys.

if mame were modified to make all games behave like #3, then all games would play perfectly with real shifters, and as well as possible with just buttons.

[RobotronNut]

...
seeing as mamedev appear to want to leave it as is (or are uninterested or whatever) how about the next best thing - lets get all the games to have the code available in  the driver.

This would make it easy for anyone to just edit a line of code per game to switch the control setup.
...
Of course, the next logical setup would be having code in there for support #3 type that you mentioned above, even if the original game was not.
...

if the code for style #3 were enclosed in an #ifdef in all drivers, then no code would have to be changed at all. you'd just need to recompile with a one-word change to your compiler options.

[Darth Nuno]

Do you know if there is the specific pathc  to fix Out Run & Turbo Out Run games, in order to use the original gear shifter of the cab' ?

[Tailgunner]

How hard would it bee to move the micro switch on a Hi/Lo shifter from one end of the stick's travel to the center of travel? As I understand it, a Hi/Lo shifter has the microswitch held open in one position and closed in the other. With the switch in the middle, it would be open 99% of the time. It would momentarily close the switch as you moved the stick past the center to the other position, giving that single keypress the MAME expects for the Hi/Lo shifter function.  You would need to watch what position the shifter is in when you're starting the game though, start in the wrong position and it'll be backwards the whole game.

A 4 way shifter could be similarly devised, though it'd take 4 switches to pull off. The switches would need to be placed in between the center and ends of the shifter throws, so that the stick momentarily closed the switches as you moved through the gears. It would close them again as you moved out of a gear, but MAME should ignore those as you were already in that gear.

Act Lab's RS shifter worked this way, and was a godsend in Grand Prix Legends as you could skip gears and eat a sequential shifter user's lunch on slow corners.