wheel / yoke for road blasters?

[RobotronNut]

Road Blasters may not be very good with an analog yoke.  The original game used an optical steering wheel.

hmm... apparently the original roadblasters used an optical yoke, like a 360 degree wheel, with a physical restriction, so it could only move thru something like 270 degrees.

is anyone out there successfully playing roadblasters on a 270 degree analog yoke? if not, what other good solutions are there?

[cw]

get a road blasters wheel and make a cp?

[Major Rock Hardy]

I found this strange also.  I have tried it with an Ultimarc A-PAC running a SW yoke in windows mame and it gave me problems.  Yoke calibrated fine in win2k and works fine in SW and stunrun. 

If I can't get it to work, it shouldn't be too hard to also mount a spoked wheel and optical sensor (via mouse hack, etc.) somewhere on the backend where the left/right pot is.  Of course no destroying original equipment though! 

[u_rebelscum]

You could edit the source.  Mame doesn't simulate relative analog (mouse/trackball/spinner) input types well with anything but relative devices.  Since analog joysticks & 270 wheels are absolute, mame translates the analog data to digital left/right/center internally, then translates that to simulated relative data.

All you have to do is a small edit of the source: change the input type of the wheel from spinner to paddle, and recompile.  (That's a one word change.)

This has been an issue of mame's, and the person who wrote the drive feels that mame's generic "dial" input type documents the original hardware better than the generic "paddle" input type.  I agree for documenting (mame's main goal), but playability (which isn't mame's main goal) "paddle" works better for most PC hardware.  Do not bring it up with the mameDevs though; just live with it and compile your own.

[Major Rock Hardy]

word.  Thanks for the tip!

I figured I'd have to re-write a portion of something where the difference inputs increment/decrement a counter that saturate at the analog limits the paddle control code would expect... or something... but a one-word change - I like that!

Rock

[Kremmit]

I did see where somebody added an encoder wheel and a set of optics to the back of their SW yoke just for RoadBlasters.  They said it worked fine.

[RobotronNut]

I did see where somebody added an encoder wheel and a set of optics to the back of their SW yoke just for RoadBlasters.  They said it worked fine.

i tried to find an article like that but couldn't find any. if you can re-locate it, please let me know. thanks.

[RobotronNut]

All you have to do is a small edit of the source: change the input type of the wheel from spinner to paddle, and recompile.

how well does it work after you've made that change?

would it still be better to add optical capabilities to the sw yoke?

[u_rebelscum]

All you have to do is a small edit of the source: change the input type of the wheel from spinner to paddle, and recompile.

how well does it work after you've made that change?

would it still be better to add optical capabilities to the sw yoke?

Very well.  The only thing you can't simulate with the change is the "missing spoke" and "missed read of a spoke/gap" errors, AFAIK.  
Adding the optical to the yoke, OTOH, might feel closer to the original sensitivity / angle turned than from the POT side (for reasons of deadzone, progressive/logrithmic scaling, early max, etc, which differents from wheel to wheel, and driver to driver settings).

The one line is in src/drivers/atarisy1.c, line 661:

INPUT_PORTS_START( roadblst )
   PORT_START   /* F20000 */
   PORT_BIT( 0xff, 0x40, IPT_PADDLE ) PORT_MINMAX(0x00,0x7f) PORT_SENSITIVITY(25) PORT_KEYDELTA(10) PORT_REVERSE

   PORT_START   /* F40000 */

"IPT_DIAL" changed to "IPT_PADDLE"

[RobotronNut]

very cool. will give it a try. thanks!!!

[Kremmit]

I did see where somebody added an encoder wheel and a set of optics to the back of their SW yoke just for RoadBlasters.  They said it worked fine.

i tried to find an article like that but couldn't find any. if you can re-locate it, please let me know. thanks.

Sorry, if I remembered where I saw it, I would have linked it up in the first place. 

[mark shaker]

I did see where somebody added an encoder wheel and a set of optics to the back of their SW yoke just for RoadBlasters.  They said it worked fine.

That would be me!

See my Return of the Jedi cabinet at :www.marksarcade.com. There is not a lot of technical info on it, but there is a picture of the mounted optic wheel.

   - Mark

[Major Rock Hardy]

Very well.  The only thing you can't simulate with the change is the "missing spoke" and "missed read of a spoke/gap" errors, AFAIK.  
Adding the optical to the yoke, OTOH, might feel closer to the original sensitivity / angle turned than from the POT side (for reasons of deadzone, progressive/logrithmic scaling, early max, etc, which differents from wheel to wheel, and driver to driver settings).

The one line is in src/drivers/atarisy1.c, line 661:

INPUT_PORTS_START( roadblst )
   PORT_START   /* F20000 */
   PORT_BIT( 0xff, 0x40, IPT_PADDLE ) PORT_MINMAX(0x00,0x7f) PORT_SENSITIVITY(25) PORT_KEYDELTA(10) PORT_REVERSE

   PORT_START   /* F40000 */

"IPT_DIAL" changed to "IPT_PADDLE"

U_rebel-

I assume this should work in the other direction?  That is - swapping an optical spinner where mame expects a paddle control?  For instance - if I want to play 4 person Warlords (which I believe was analog (pot) paddles) with 4 optical spinners - would the source edit work OK?  I know this will have to be a mame analog+ or advmame application due to the 4 axes...

Thanks,
Rock

[u_rebelscum]

The only thing you can't simulate with the change is the "missing spoke" and "missed read of a spoke/gap" errors, AFAIK.  
Adding the optical to the yoke, OTOH, might feel closer to the original sensitivity / angle turned than from the POT side (for reasons of deadzone, progressive/logrithmic scaling, early max, etc, which differents from wheel to wheel, and driver to driver settings).

U_rebel-

I assume this should work in the other direction?  That is - swapping an optical spinner where mame expects a paddle control?  For instance - if I want to play 4 person Warlords (which I believe was analog (pot) paddles) with 4 optical spinners - would the source edit work OK?  I know this will have to be a mame analog+ or advmame application due to the 4 axes...

Mame is great at relative device to absolute game inputs (as with Warlords, or star wars with a trackball).  So no need to edit the source.  (I doubt you would notice any difference with the change, and with it you couldn't use absolute devices.)

The reason is it's really, really easy to go from a relative device's input (spinner) and use it to simulate an absolute input (POTs).  And mame does this fine.  It's almost as 'easy' to go the other way, but there's two totally different ways to do it.

I'll use arkanoid, a spinner, an analog joystick, and a POT spinner in this example.  You can translate the absolute to relative in two ways: "distance from center" and "change from last".  The POT spinner would work exactly like a normal spinner (assumeing linear POT, no software deadzone, scaling, curving, etc) with the "change from last" method (it turns the absolute into relative by software).  However, the analog joystick would probably be best with the "distance from center" method, as the distance from center would determine the speed the paddle moves.  "Change from last" might work for a zero or weak spring analog joystick for some people, though. 

FWIW, games like super sprint and pole position probably would do better with "distance from center" with PC steering wheels (270 degree) even though the game play would be somewhat different than the original.

With that said, mame could get good absolute to relative input play if the user could choose which way it's translated.  More work I never got around to.

[Silver]

u_rebelscum: most useful/interesting post I've read in ages. Thanks!

So basically the best type of input for mame to use depends on the physical controller being used.

Are there many other games in similar situations to roadblasters? ie 'non-standard' input (as not a typical yoke) that works better with a source change?

[RobotronNut]

I did see where somebody added an encoder wheel and a set of optics to the back of their SW yoke just for RoadBlasters.  They said it worked fine.

That would be me!

See my Return of the Jedi cabinet at :www.marksarcade.com. There is not a lot of technical info on it, but there is a picture of the mounted optic wheel.

   - Mark

thanks for the info. have you ever tried the software solution outlined above? you would be in a unique position to compare the two, since your yoke would support both.