Main > Main Forum

idea for hacking gpwiz49 board to emulate analog shifter (Hard Drivin)

Pages: << < (2/4) > >>

SavannahLion:


--- Quote from: Xiaou2 on November 02, 2007, 11:41:53 pm --- I wish they would Fix mames shifter situation.   Adding a MODE to add 
"HELD DOWN BUTTON"  so that a button is always on = Hi,  and letting it
go = Low.    While there are only a few keys on the keyboard that you
wouldnt mind being held down (caps lock, shift, insert?) one can easily
use Gamepad buttons without any windows issues when exiting.

 Mames current situation does not know what the actual switch
position is (in many games).   If you start mame with your shifter in low gear,
mame may think its in High gear.   This does not happen in the real
machines, cause they do not use a phony Toggle mode. 
They are wired to know which is which.

--- End quote ---

I always found that to be humorous. MAMEDev seem to really push hard on accurately simulating the hardware for these machines, but there seems to be some hesitation to accurately accept input for very specific parts, like the shifter in question, and give us command line access to enable them. I think I understand that the MAMEDevs want to code for the lowest common denominator, but there are some arcade games that simply cannot be accurately simulated without the necessary hardware.

In any case, I've been told by some people that some analog control input do exist in code for certain games, but are commented out. One would need to examine the code, re-enable them and recompile. Unfortunately, I don't recall which games are like this except for Pole Position's pedals.

Edit: for clarification

u_rebelscum:


--- Quote from: SavannahLion on November 03, 2007, 02:26:22 pm ---I always found that to be humorous. MAMEDev seem to really push hard on accurately simulating the hardware for these machines, but there seems to be some hesitation to accurately accept input for very specific parts, like the shifter in question, and give us command line access to enable them. I think I understand that the MAMEDevs want to code for the lowest common denominator, but there are some arcade games that simply cannot be accurately simulated without the necessary hardware.

--- End quote ---

I felt the same way, but then tried to edit mame for a few special-inputs games.  The problem is windows input system.  (Actually all computers input systems.)  Mame has to use it, and gets all the limits of it.  There is no way in modern OSs for mame to directly talk to the input devices like real arcades did.  Thus making any attempt to "accurately emulate" the original inputs to really be simulating the inputs.

So why should a dev program for an input device he does not have, which wouldn't work without special drivers, when a 20 line hack will do the nearly the same thing on what they have to test with?

720 is an example where mame went from almost accurately emulating (one dial axis instead of one normal spinner aixs + one index axis), to a much more user friendly simulation but far less accurate emulation of the original input (analog joystick to dial translation), and 99% of the users were happier. :dunno

brandon:

...and 99% of users would be happier if Mame would make use of 3D acceleration instead of emulating 3D hardware at 5 FPS... but I dont see that changing anytime soon :)   but anyways... with all the specialized hardware interfaces (optical, analog, and digital) from folks like Ultimarc and Groovy Game Gear couldnt Mame more closely emulate the hardware now?  I know Mame can't directly "talk" to your spinner because of all the layers of OS but couldnt Mame read raw data from some of these speciallized devices by way of USB?  I guess as it is now optical interfaces show up as a mouse to the OS but that's just for simplicity sake right?  I wish there was a way to eliminate the sensitivity settings and other "conversions" in Mame and just have the Mame driver read "pulses" from the actually hardware.. be it an arkanoid spinner, 720 stick, pole position wheel.. etc...

u_rebelscum:


--- Quote from: u_rebelscum on November 05, 2007, 07:58:00 pm ---... all computers input systems....  Mame has to use it, and gets all the limits of it.  ...

So why should a dev program for an input device he does not have, which wouldn't work without special drivers, when a 20 line hack will do the nearly the same thing on what they have to test with?
--- End quote ---


--- Quote from: brandon on November 05, 2007, 08:19:33 pm ---... with all the specialized hardware interfaces (optical, analog, and digital) from folks like Ultimarc and Groovy Game Gear couldnt Mame more closely emulate the hardware now?  I know Mame can't directly "talk" to your spinner because of all the layers of OS but couldnt Mame read raw data from some of these speciallized devices by way of USB?  I guess as it is now optical interfaces show up as a mouse to the OS but that's just for simplicity sake right?  I wish there was a way to eliminate the sensitivity settings and other "conversions" in Mame and just have the Mame driver read "pulses" from the actually hardware.. be it an arkanoid spinner, 720 stick, pole position wheel.. etc...

--- End quote ---

As I said, each device would need a special driver.  And even if it had a special driver, the driver would be doing the simulating the so-called "pulses".  ("Pulse" is the wrong term, but close enough for now.)  Well, unless the device had special firmware that didn't send standard USB mouse info, but "pulses".  And even then the original "pulses" would be simulated over the digital USB limits (speed, latency) & through USB driver & USB chip & PC mainboard & OS, vs the direct wiring of the arcade device to the PCB.  After all that, mame would need another major overhaul on the inputs code to handle the simulated signals, including emulating chips and discreet circuitry it doesn't emulate yet (aka possible slowdown, especially for boardline systems). 

Mame is just too far from the input devices for a true emulation of the original hardware.  And why add the extra work of writing a driver and new firmware and emulation code, the first two to stop the mouse firmware from doing what the emu code does?  (IOW, "why re-invent the wheel?")


Can mame come as close as the original hardware with all the limits of modern OSs?  Most games*, yes with simple hacks and proper hardware.  Can mame do it without breaking current support of 99% of the user's hardware?  Only with ugly hacks that go against mame's policies. 

Not to sound against what you want.  I tried adding better support of original hardware in my builds, but the number of different inputs and the different ways they could be done were too much for me to keep at it. :-[  I still want to do it, but need to find a manageable way so I don't burn out again.

*The one original input that would need MAJOR coding (and USB 2 probably isn't precise enough latency-wise anyway), AFAIK, is arcade lightguns.

Xiaou2:

 
 I dont see why it has to be an Ugly hack to be able to support dual means
of control input.

 Already,  most games support input of either Digital or Analog for any control.

 Already in mame,   there is a system of  'And'  and  'not'  in the control
logic...     and why would it  be so hard to insert a  'held down'  logic in
there?

 Meaning:

1)  Press tab
2)  Select button 1  (shifter)
3)  Press joystick button 3 down (putting your shifter into Hi gear), and hold it there
for 5 seconds
4) then put the shifter back to low gear = switch turning Off & mame accepting it.   

 Mame now would accept that this input must be held down for it to be active,
and would toggle the gear when its let up (off).


 But in reality,  the real 'hack'  is the current driver situation.   Having a button
to toggle the shift is not true... and really is Ugly.

 One could say that all the games should operate as the arcade...  maybe having
Caps lock as the default  Hold-n-release  button.   (can change it as said above)

 And the Cheat method (current mame method)  would be to just press
any key and release it in less then 5 seconds.    This would activate the
toggle HACK.


 Is  that really too difficult for guys who already created a complicated
and and not system?   

 
 --- Edit ---

 Look how they Handle pedal inputs.

  They have a specific set of switches.

 Analog / Digital   switch.

 And then they even allow you to define things for values
of Increase and Decrease.

 
 If that it true..  which is a hack...   then why no the same for
shifters?   

 A Toggle like the analog / digital:

-------
 Shifter  (Arcade mode/Toggle mode)
 Hi    =  button 3  (held)
 Low = (na)
-------



Pages: << < (2/4) > >>

Go to full version