Main > Software Forum
My official MAME output wip thread.
bdam:
Below is a list of what I submitted. It was primarily binary stuff that I was certain of. I'll probably take a break for a bit and then see if MAMEdev will accept a submission where the motor outputs change the state of the machine which in turn will trigger limit switches. In certain machines this is a matter of manipulating an existing input (if that's even possible) that tracks position and in other cases it will mean simulating a position value since the machine didn't track it.
(cischeat) Lamps and wheel vibration, bigrun, cischeat, f1gpstar, and f1gpstr2. Seat vibration for f1gpstr and f1gpstr2.
(megatech) Lamps
(taito_z) Wheel vibration for sci and clones.
(undrfire) Lamps, gun recoil, and wheel vibration for undrfire and cbombers
(weclemans) Lamps, wheel vibration, and tentative cabinet motions for weclemans and hotchase. DIP switches for hotchase based on manual.
BadMouth:
bdam, thanks for helping howard out! (especially on the driving games ;D )
Wild Pilot had vibrating guns (I have a gun from one). It's just has a single motor with a lopsided weight on the end.
There was also a deluxe sit-down version that had motion base.
The flyer mentions three safety sensors and an emergency button that stop the movement.
Looking at the flyer it's hard to tell if it was full motion or just pivoted up and down.
I've never been able to find a manual, but if I do I will buy it and pass it along.
Howard, I bought a cheap wheel off fleabay to hack, but the one I received is not the one that was pictured or described. It's not worth sending back and losing out on shipping both ways. I haven't tested it out yet, but if it works, it's yours if you want it. PM me your address.
I'm just a dumb end user and am assuming directx wheel feedback works the same on all wheels, but the fact that some newer wheels have 2 or 3 motors has me wondering if that is the case?
I'll be reading your tutorials at work today. :laugh:
EDIT: Howard, the links to tutorial 2 and 3 both take me to tutorial 2.
Howard_Casto:
--- Quote from: bdam on June 03, 2011, 08:21:41 am ---Below is a list of what I submitted. It was primarily binary stuff that I was certain of. I'll probably take a break for a bit and then see if MAMEdev will accept a submission where the motor outputs change the state of the machine which in turn will trigger limit switches.
--- End quote ---
If this is what you are doing then even if it's accepted we need to change it. The mame's goal is to be a drop-in replacement for a pcb, you are hacking the lsw inputs to work better with a directx ff device. We shouldn't do that.
I have all the limit switches in the sega boards hooked up to inputs.
You hook limit switches up as regular old inputs. If you are concerned about a ff device not working because of this let me assure you that limit switches have next to nothing to do with operation (except the bootup test) and regardless I will write and app and/or device that will read the joystick data and send keystrokes when needed.
If nothing else, the easiest solution is to just crack open the wheel you are using and add some physical limit switches. ;)
bdam:
>you are hacking the lsw inputs to work better with a directx ff device
Not quite, this doesn't have anything to do with the output from MH or my input device but rather simulating how the limit switches and motors interact on the actual machine. The cabinet motors would move something and at certain positions that something would trigger certain limit switches. DirectX doesn't come into play; my input device doesn't come into play; I was thinking of handling this all within MAME.
>You hook limit switches up as regular old inputs ... read the joystick data and send keystrokes when needed
Agreed, but how do you trigger those outputs in a manner similar to the actual machine? If I understand you correctly you suggest triggering the limit switches based on the value of an input device such as a joystick or wheel. I don't think that would work either; the limit switches on the machine aren't tied to the limits of their input devices but rather the positions of something the motors were moving.
Here's another idea. In MAME, add outputs for the position of whatever the motors are moving; that something. Output its position left to right, front to back, up and down. Then use MH to read those positions and at certain points trigger a key that MAME has tied to that input. The only problem I could see is that people who don't have it all set up will now get warnings on initialization. Sure, it's more accurate to the machine but it sounds like a support nightmare for MAMEdev. Also, some machines don't seem to track an exact position so how do we simulate that?
Howard_Casto:
How every single solitary arcade ff device that I've ever looked at works is this. Limit switches are just that, switches. i.e. either an optical gate or plain old cherry switch that gets tripped when the motor/wheel, ect goes to far and physically passes through it. In other words, it's just an input, like a pushbutton or anything else. It isn't built into the motor/piston or anything, it is a stand-alone switch. If youa re doing anything other than hooking up the limits switch bits to inputs then you are hacking it.
Your problem is you are trying to equate directx force feedback and how it operates with how the arcade hardware operates. They don't operate in the same way at all, so somewhere there has to be a hack. It can't be in mame, so we do it on our end. Directx ff devices don't have the same kind of limit switches. They have fail safe switches in case something goes crazy wrong, but in general the limit is determined in software by the pot value.
I think you are confused about limit switches. There is the limit (holy crap we are at the end, turn it off!) and there is a motor/ram position. Motor/ram positions are inputs as well, we hook those up to an analog input port. We don't bind them to the wheel position though, it is a seperate input. This gives the user the freedom to do any kind of force feedback arrangment possible and more importantly, hook up the original arcade hardware as intended.
For an end user to use a ff wheel (which let's face it, is a gross hack) they would do the following:
Bind the steering wheel's axis to the wheel axis in mame.
Also bind the steering wheel's axis to the motor position value in mame.
Allow some middleware app (probably mamehooker) to trigger any limit switches via code whenever the wheel's axis is at it's limit OR when the pot hooked up to track the motor is at it's limit OR skip all of it and simply have physical limit switches already binded inside mame.
I don't need the position of the motors vai outputs in mamehooker because on a dx ff wheel, the position of the motor is the position of the wheel. And if it's the arcade hardware or some sort of custom rig, the motor will be hooke up to a pot to track position, and I simply read that value instead. Also you are forgetting, The motor position in mame is the virtual one. Since I read the joystick anyway (how do you think I make it rumble? ;) ) I can simply read any analog value there.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version