Driving Games

[bhille]

I think I might be over planning my MAME cabinet, but I have another newbie question.  How are people playing driving games?  I've looked at alot of cabs and I can't think of any that had pedals for example.  How would you play say "Spy Hunter"?  You need a pedel, 5 buttons, and a shifter for high/low.  Then, when I look at Happs site, they have analog pedals and microswitch pedals.    How do I know which to use?  I've looked at KLOV and all it says is that the game requires a pedal.  I really want a cab/control panel that can play Spy Hunter, Road Blasters, Super Sprint, etc.

Please help!!  I'm burning out just thinking about all the possibilities.  

Thanks,

Brian

[Beley]

not shure about the others but i know for a fact that spy hunter has an analog pedel

[Agent Davis]

How often do you play a racing game and actually not floor the pedal all the way anyway?  Driving games either use optical or analog controls.  I think a lot of people use their spinners for games that require optical controls (ie super sprint) though you can use optical controls for the analog games too.  I think some people actually have analog wheels that the can use.  As far as pedals go, if you are using your spinner as a wheel you can use a pushbutton as gas if you want.  I know some people have made pedals.  But like I said, analog is great but how often do you not floor the pedal anyway?

[Dan]

I'm in the process of designing a driving panel for my ArcadePC.  I have an Oscar SWC, Happ 10" wheel, and a 2-speed shifter w/turbo button.  I've been throwing around different ideas for pedals.  First I tried using my PC pedals, but they're designed for sitting down.  Plus they're not to sturdy and may break if too much weight is placed on them.  Then I looked into the Happ pedals, but they're $50 for a microswitch pedal!  Then I was looking at the Build Your Own Arcade Controls website (the other one:) and they had a write-up for a foot pedal for Namco's GunCon (for Time Crisis).  The foot switch looked like it would do the trick.  It only costs $8!  I'll let you know how it is when it arrives.

Dan

[u_rebelscum]

How are people playing driving games?  I've looked at alot of cabs and I can't think of any that had pedals for example.  How would you play say "Spy Hunter"?  You need a pedel, 5 buttons, and a shifter for high/low.  Then, when I look at Happs site, they have analog pedals and microswitch pedals.    How do I know which to use?  I've looked at KLOV and all it says is that the game requires a pedal.  I really want a cab/control panel that can play Spy Hunter, Road Blasters, Super Sprint, etc.

Please help!!  I'm burning out just thinking about all the possibilities.  

Thanks,

Brian

Most games with pedals used analog pedels.

The easiest (non-cab) thing to use is an analog joystick, with the y axis the gas (up) and brake (down).  So you can hack a joystick to build a brake + gas pedal combo.

Also, I remember seeing examples of people cutting out the bottom front of their cab to fit the pedals, but only do this to the generic conversion cabs, please!

About 20 games or so in mame with pedals that should be analog, including all three you mentioned (full list), do not correctly read the analog pedal input in the official mame.   Mame:Analog+ includes a fix, and Mame:Analog Pedal is only that fix, download at my web site, below.   (both are v.58 currently, update "soon")   I will submit the fix again to MameDev, too.

IMO, Spyhunter really needs the true analog support, or else driving into the truck is very hard, and driving in high gear is next to impossible.

[Frobozz]

Yea, I tried RoadBlasters (one of my favorite games!) with a MS Sidewinder Force Feedback Wheel that I'm planning on "converting" to my cabinet.    

Unfortunatly, the game is unplayable.  The wheel doesn't "re-center" the car.  If I want to take a left turn, I have to turn left (which, depending on how long I hold it there, NOT how far I turn the wheel, the car keeps turning) and then to straighten out, I need to re-center the wheel and turn right for the same amount of time (usually, I end of over-compensating back).  

I think this is an error on the Road Blasters driver since Outrun behaves somewhat decently.  Amen on Spy Hunter though.  Game currently has two speeds:  Sunday Drive (LO) and Death-Monkey-Gonna-Die-In-2.8-Seconds-Fast (HIGH).   Yup...  makes it kinda "tricky"

Second of all, MAME sucks for anything analog.  I think the MameDev team should REALLY take a long, hard look into emulating analog control properly since so many games used them.  

[bhille]

Yea, I tried RoadBlasters (one of my favorite games!) with a MS Sidewinder Force Feedback Wheel that I'm planning on "converting" to my cabinet.

[Lilwolf]

Road blasters had a controller similar to a starwars yoke (no spinning).  To get it playing great, I would go with that hack before a steering wheel.  A forced feedback controller would work great for this also since it centers itself.

Most other games, the wheel could spin.  This makes the force feedback not the best controller.  Steering wheels are cheap on ebay.  I actually have about 5 right now (overbid one week.  didn't expect to get them all).  I haven't hacked them yet, and don't know if I will get all 3 on my cabinet.  But I will probably give 2 away for shipping costs to anyone who wants it.

As for the pedal.  Sure a triggered one would do, but analog is MUCH better.  AnalogMame should do the trick.  I have thought of a few hacks, but nothing great (and easy).  One idea I had was to have a spring pulling a rod on the inside of my cabinet that you push when pressing the pedal.  Then have a joystick jimmied to it so that when it moves, it moves the joystick.  But it seems like such a hack.  I would love to hear a good idea on this one

[Frobozz]

Nope, no force feedback in MAME yet.  It would be a real-interesting idea though!  

Yea, I can't complain with the MAME team.  They've done an increadible job with things so far.  My concern is that analog control is an essential aspect of proper emulation, and I feel the current "analog" setup is still nothing more than a poor hack, and that a proper analog control system should be designed and developed for MAME soon (before MAME can emulate SO many analog games, that going back and retro-fitting existing ones with a new control system becomes a major pain in the butt).

There's no excuse why I can't plug in any analog steering wheel / pedal set and with a few small tweaks in the game settings, get it to behave exactly like the arcade.   To me, that's just as essential as the colors, sound, and game logic being correct.

I believe Analog MAME fixes the pedal problem, but I'm not sure as to how much else.  

RoadBlasters in MAME has it's problems though.  I really wish I understood enough C++ to fix them.  Maybe I should download the MAME source and have a go at it.  

[u_rebelscum]

RoadBlasters in MAME has it's problems though.  I really wish I understood enough C++ to fix them.  Maybe I should download the MAME source and have a go at it.  

You don't need C++, mame is written in C.  Try downloading source and looking at it.  That's what I did and after a little while (okay more than a little), I thought of a couple things I knew how to change.

And since you want mame's Analog input to improve as much as I do,  Wanna help me with Analog+?

[Frobozz]

I'd love to help, but first of all, a standard needs to be set for analog systems under MAME.  

Supposidly, DirectX8 can handle such things, but it must be handled on a driver level for Microsoft's primary OS.  (Not that I blame them, 99% of all instabilities in Windows 9x came from junk programs talking directly with the hardware w/o telling the operating system.)

Unfortunatly, this requires a driver standard as well, so people like Andy at Ultimarc can make a USB Optipac, get it to run under Windows 2000 with it's own hardware driver as a HID ("Human Interface Device"), and have MAME detect and talk to the standardized driver (MAME: "Hey! I detect there's a 4-port USB Optipac installed!  I'll enable support for the device now with any game that can benefit from it...")

Now, while this will work with Windows OS, it won't with Mac and Linux unless they develop their own drivers for the hardware.  Regardless, if a driver standard is set, and a MAME patch can be written for it, and there is at least one device out there that uses it, it stands a very good chance of being included in the official MAME release.  

Also, with a driver standard, other makers of Optipac type devices can make drivers in spec with the standard, and MAME will be able to talk to them w/o any additional modification.  

I think the only reason your patches aren't in the official release of MAME yet u_rebilscum is because they only work with Windows 9x.  

That's my 2 cents on the issue.  What do you think?  

[u_rebelscum]

Frobozz, I'm unclear what you mean, so am asking questions.  I don't mean them to be harsh, be rereading them, they sound that way.  I'm sorry about that, sometimes I sound that way.   I am not attacking you.

I'd love to help, but first of all, a standard needs to be set for analog systems under MAME.
[snip]

Unfortunatly, this requires a driver standard ...[snip]

Now, while this will work with Windows OS, it won't with Mac and Linux ...[snip]

What do you mean by this "analog standard"?  Mame currently has a "standard".  Well, I guess four "standards": mouse analog input data, joystick analog input data, trackball/spinner data "game-trans-put", and joystick data "game-trans-put".  (by "game-trans-put", in mean the data mame passes to the game.)  

Are you're tallking about the mouse analog & joystick analog inputs with your "standard"?  Or a substitute input standard for mice?  Or somthing else?


All input data is OS dependent initially.  This OS dependent data is translated to Mame's internal core data format by mame's OS-specific code (which varies depending on with OS mame is compiled for).

From a programmer's point or view, think of the mame core code and OS specific code as two different programs passing data back and forth. (Core: display this.  OS-specific: okay.  Core: Give me analog joystick #1 data. OS-specific: here you go.)

So would your standard change mame's core data formats, or just the OS specific input data, or both?  (Example: the one change in mame's core analog data format is the addition of a third analog "game-trans-put" axis per player, but almost everything else I can think of can be done exclusively in the OS specific code.)
 
All drivers are OS dependent.  Mame has little problem about using OS dependent drivers, at the OS level, as long as it doesn't demand changes to mame's core that break the other OS mames.  (Example: dx forceFeedBack support demands changes in Mame's core and game driver code, in addtion to the OS code, and probably would break the other OS's mames.  But changing from dx5 to dx6 requires no changes in mame's core code, and wouldn't break other OS mames)

I think the only reason your patches aren't in the official release of MAME yet u_rebilscum is because they only work with Windows 9x.  

That's my 2 cents on the issue.  What do you think?  

Heh, there are many reasons the Analog+ features havn't been added:

• One (the multiple mice) feature needs to be compiled in dx8 (mame uses dx5 to compile)
• Most are ugly hacks
• Some of the hacks really mess up the current I/O functions
• Some of the hacks can slow down mame
• They are all still very much WIP
• Most aren't totally stable yet
• I only have submitted the pedal fix

I'm sure I missed a few points, too.  Some of the features are getting closer to being it submit-able shape, but unless some mameDev wants to make corrections theirself, I doubt most of the code is clean enough to be added to the offical mame yet.

[SirPoonga]

You don't need C++, mame is written in C.

[Frobozz]

Putting it that way, it would change the OS specific end of MAME.  

See, the problem I see, is that a USB DirectX8 HID device what includes multiple mouse / spinner pipelines hasn't been developed yet.  Why?  Because nothing  uses it!  (Except MAME that is  

I'm not entirely sure DirectX would know what to do with it, since it wouldn't be handled like a Joystick, Mouse or what-not.  It would be an entirely new device requiring it's own driver to tell DirectX how to handle the data comming in.  

So... you come up with a nice, standardized way to pass that info through the driver layer, and into DirectX by writing a driver.  You tell it, ok:  The first interrupt is for the first "mouselike" device, and it's input comes in on pipes 1 and 2.  The second interrupt is for the next mouselike device, and it's input comes in on pipes 3 and 4.  Now, take the data from those pipes, and post them to some memory position that whatever the hells going to use them can see them.

Wonderful, you've now, by writing a driver, gotten DirectX to post the positional data from our new multi-XY analog axis hardware.   Next step, you gotta tell MAME's OS layer where that data might be located.

Well, it's not defined as a joystick, so DirectX reports none.  It's technically not a mouse, because the driver says it's not.  Besides, Windows2000 only allows one "mouse" on a system, and that one's already accounted for.  But, if MAME knows to look for some standardized "key" that DirectX is posting (like "Hey, I got a multi-XY analog axis device plugged in on the USB!") then it can be programmed to look for where that data is comming in.  


I dunno dude.  It might be much simpler than this.  I welcome your criticism, and while I know quite a bit about Windows programming, I'll be the first to admit I don't understand DirectX mery much at all.  What I do know is there exists a standard for input devices in recent versions of DirectX called HID devices.  These are non-mouse, non-joystick, some other kinda device entirely things.  

They have their own drivers that tell DirectX what to go do with it.  It could be as simple as "There are a lot of data pipes attached to this device, turn the first 2 into standard system-mouse input, turn the next 6 into key-presses for the following keys.  Turn the last pipe into a mousewheel up or down action depending on if the value increases or decreases..."

I mention a "driver standard" because when telling MAME to "look here for the input data if this weird HID device is installed" , all drivers for all weird HID devices meant for MAME must be set to tell DirectX to post the data to the same place.  

I hope that made sence.  

[u_rebelscum]

Okay Frobozz, I agree with you all the way, just been looking at this from the other end.

I'm not entirely sure DirectX would know what to do with it, since it wouldn't be handled like a Joystick, Mouse or what-not.  It would be an entirely new device requiring it's own driver to tell DirectX how to handle the data comming in.

DirectX can do this; apparently there are four basic input types for dx (just reading about it now, so not too sure on details): mouse, keyboard, joystick, and device.  The last one is a generic type for devices "that (do) not fall into another category".  (quote from MS directX C++ help file)

[snip]...I dunno dude.  It might be much simpler than this.

I think you have it pretty close to what needs to be none.  One shortcut: The driver can use the mouse data format in directX as the method of passing the data, but through a DIDEVTYPE_DEVICE type device instead of through the system mouse, and let mame handle them like the mice already are, only adding a separate emuneration for them.  (I think)

I welcome your criticism, and while I know quite a bit about Windows programming, I'll be the first to admit I don't understand DirectX mery much at all...[snip]

The only stuff I know about windows programming is what I've learned through hacking mame.  It includes a little about directX, but not very much.  All I know is win9x lets HID mice be seen as separate mice in addition to the system mouse, but not win2000/XP.

I hope that made sense.  

Yup, cleared up my questions.  

Know anything about writing windows drivers?  Know anyone else who can?  (I don't.)  Maybe someone can make sense of what we're talking about here and write one.  I think I can write the needed code for mame to work with it if the shortcut I mentioned is used.

[Frobozz]

All I know is win9x lets HID mice be seen as separate mice in addition to the system mouse, but not win2000/XP.

Right, and that's a big problem.  Because all mice and mouse-like devices announce to Windows "Hey!  I'm a mouse!".

Now, can you take a device that acts like a mouse and tell it to announce itself as "device" (rather than a "mouse"), then write a driver to tell DirectX that this new "Device" has mouse-type data and to pass it to DIDEVTYPE_DEVICE?  And thus to MAME?  And now the biggest question:  Will it work with Windows 2000 / XP?

If it's driver doesn't define it as a "mouse", but as a generic HID device, then it should, correct?

If so, THIS is the avenue we need to explore.  

Also, as I mentioned, a standard needs to be devised for the future.  If this is to be done, I feel it must be done right.  What happens if someone comes out with a "device" with a driver that passes 4 sets of mouse-type data to DirectX at once (like a USB OptiPac)?

How would MAME handle it?  Could a "standard" be written to make it flexible enough to allow people to make all-sorts of input devices and have MAME just simplly pick them up from DirectX?   That's the key I believe to opening a whole new door in PC controls

Know anything about writing windows drivers?   Know anyone else who can?

Kinda at Andy's request (because I brought up the idea of a USB OptiPac), I did recently take a look at the Microsoft DDK (Driver Development Kit) and severely hurt my brains.  Now, I also found out some "quick driver development kits" on the web.  I'm going to explore this further, because the amount of resources needed to write a driver from scratch seems hideous.  

Also, Andy recently posted that he's talking to a person who REALLY knows drivers.  So I'm anxious to hear what happens from that.  

[u_rebelscum]

Right, and that's a big problem.  Because all mice and mouse-like devices announce to Windows "Hey!  I'm a mouse!".

Now, can you take a device that acts like a mouse and tell it to announce itself as "device" (rather than a "mouse"), then write a driver to tell DirectX that this new "Device" has mouse-type data and to pass it to DIDEVTYPE_DEVICE?

I could be wrong, but I think the devices annouce "Hey! my ID is '3423er23erf3'" (or some garbage like that), then  windows looks at it's .inf files and finds that ID.  If the ID matches a mouse or mouse-like device, then windows treats it like a mouse .... So either the devices need to send a new ID, or erase the (old mouse's) ID from the .inf file and repleace the ID's driver data with the reference to the new driver.

And thus to MAME?  And now the biggest question:  Will it work with Windows 2000 / XP?  If it's driver doesn't define it as a "mouse", but as a generic HID device, then it should, correct?

If so, THIS is the avenue we need to explore.

I think so, I think so, I think so, and yes.

Also, as I mentioned, a standard needs to be devised for the future.  If this is to be done, I feel it must be done right.  What happens if someone comes out with a "device" with a driver that passes 4 sets of mouse-type data to DirectX at once (like a USB OptiPac)?

Usually in cases like this, the .inf should indentify the single device as four mouse-like "device-type" virtual devices; the directX mouse data format is still used in four virtually different devices, instead of needing to come up with and pushing a new standard.  Of course, while this makes it easier on mame, it might make writing the driver harder.

Current day example, some keyboards that include a touch pad are seen as 2 devices by the applications: a keyboard and a mouse; and not a single device that has keyboard and mouse data.  So, following this method, Andy's 4 mouse device would been seen as 4 "device-type" mouse-like devices, instead of one device with 4 sets of mouse-like data.

Am I making sense.

How would MAME handle it?  Could a "standard" be written to make it flexible enough to allow people to make all-sorts of input devices and have MAME just simplly pick them up from DirectX?   That's the key I believe to opening a whole new door in PC controls

Unless it absolutely can't be done with directX mouse, joystick, or keyboard data formats, I think sticking with these is the way to go.  I don't think we need a new "standard", umm, besides the "device-type", mouse-like driver.  IMHO, let the drivers divide the input device into X number of "device-type" mouse data formatted obejects, and Y number of joystick type objects, as needed, that mame sees and uses as before; with mame getting only two changes: the "device-type" support, and absolute mouse data support (for lightguns).

Kinda at Andy's request (because I brought up the idea of a USB OptiPac), I did recently take a look at the Microsoft DDK (Driver Development Kit) and severely hurt my brains. [snip]

Also, Andy recently posted that he's talking to a person who REALLY knows drivers.  So I'm anxious to hear what happens from that.

I hope Andy wasn't taking about me.
Seriously, I talked to Andy a little while back about some of this also. But I couldn't get an example he ref'ed to to work on my computer, and then I took a peak at MS's DDK <shutter>.  I also heard about Andy's driver acquaintance and I sorta' put researching the driver part on the "backburner"  (ie: gave up for now trying to write one myself).  I would like to know how this go with this pursuit, too.  Again, I think I can edit mame to use "device-type" drivers, if help is needed.

[Frobozz]

Well, looks like you know just about everything I do about the subject.  Yea, I know how devices report to windows ("I'm 92235F43A"... look up number in .inf...).  Was just being simplistic.

I also know about how devices can report "multiple" logical devices to windows (one unit reporting 4 mouse-like devices).  

If DirectX can handle the mouse-like inputs for all versions of Windows, then this is definatly a time-saver.  With all my assumptions with windows programming, I always assume the API is dumb.  If the API turns out it can handle things smarter than I assume, then, it's always a bonus.

If Andy can get a driver written for something like a USB Optipac, then it looks like it would be a simple conversion to MAME to get it to work (heck, might just need to be recompiled under DX8, though a routine to scan the DX API for any "mouse-like" devices and pass them on to MAME might also be required.)

In my spare time, I'm going to examine how HID mouse devices work, and even try to "rebuild" a driver for my mouse as a test.

From what I've seen, even something reporting 4 mice wouldn't be any harder to program up than a single device.  Just has more data pipes.  Process is the same.

[StephenH]

I suggest getting Analog pedals, and an analog wheel.  Since MAME at this time does not support Force Feedback, it is not nessecary to have force feedback.

For most games, 2 pedals is enough.  However, there are a few games that need 3.  

[u_rebelscum]

[snip]
If Andy can get a driver written for something like a USB Optipac, then it looks like it would be a simple conversion to MAME to get it to work (heck, might just need to be recompiled under DX8, though a routine to scan the DX API for any "mouse-like" devices and pass them on to MAME might also be required.)

I don't think DX8 alone will do it, as the MS DX8 help file states that XP/2000/NT will only find the system mouse.  But DX5 (or DX8 ), a cut-and-paste, and a few simple edits will work with the generic device type mouse-like driver.

In my spare time, I'm going to examine how HID mouse devices work, and even try to "rebuild" a driver for my mouse as a test.

From what I've seen, even something reporting 4 mice wouldn't be any harder to program up than a single device.  Just has more data pipes.  Process is the same.

Thanks for researching mouse drivers.  And for all the information already.  I can almost smell the day when mame works with two or more trackballs!   Hope you or Andy's driver source come up with a way to fix this, ahh, weakspot in MS and mame.

[SirPoonga]

because I brought up the idea of a USB OptiPac

Do you know how many people want that!!  I would for one.  I thought of that last year when I first saw the optipac!

[Howard_Casto]

about placing your pedals.......

my cab was designed with such things in mind, it's just I've never gotten to them yet......  

My cab insted of having a flat front is a polygonal shape... one slender panel(about 1.5 feet wide) in the front and two panels at angels connecting this panel back to the sides.....

What does that have to do with anything?

Well What this means is the front door of my cab opens vertically rather than the usual horizontal way.....
inside my cab i already have the floor slightly raised....
When I decide to make my steering wheel rig, i'll cut my front door in half horizontally at the middle(or however i have to do it to make sure my coin door is on the top half)  and make it into one door that folds up and another door that folds down....
This way when i open the lower door my pedals will pop out and be ready to go.....
No cumbersome hookup, no nothing.... they're always ready...
combine that with my modular panel design... (My entire cp box is removable, not just the top of it like other cabs.)  And I can plug in an angled panel with a wheel a shifter and a couple of buttons on it and be ready to go.

Btw the inside of my cab has enormous real estate.... The way my door is setup I could easy put about 5 boxes in it and still get them out easily.  I don't even have to open the door the way my cab is designed.   The key is not to put a top on the portion of you cab that holds the cp box.  This way you can store a few cp boxes underneath vertically.  When you need to change you pick up the current box, set it aside, pull out the new box and put the old one back in it's place.... one simple connection and your ready to go!

Ok I'm rambling I know, just thought I would share a few of my ideas on the carpentry end of things, which a rarely do.

[Frobozz]

Do you know how many people want that!!  I would for one.  I thought of that last year when I first saw the optipac!

Yea, same here.  That's when I sent an email to Andy asking if there was one in the works.  From our mailings, I got the feeling it wouldn't be a problem for him to slap one together (he may already have one), but the whole software issue prevents him from marketing it.  

If a USB Optipac were to come out, it would require a Windows driver, which had to be installed, and most likely a MAME patch to get it to work with it; though I feel the latter wouldn't be all that hard to accomplish if the previous one was.  

[enemyace]

(snip)...just thought I would share a few of my ideas on the carpentry end of things, which a rarely do.

Howard,

Do you think you could take some detailed pics of the construction that you're describing? It sounds really interesting and I'd love to see it.

-Andy

They make alarm clocks for that type of thing... sleeping dragons. =)