Main > Main Forum
Driving Games
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.
--- Quote ---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]
--- End quote ---
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)
--- Quote ---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? :)
--- End quote ---
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[/list];D 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:
--- Quote ---
You don't need C++, mame is written in C.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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)
--- Quote ---[snip]...I dunno dude. It might be much simpler than this.
--- End quote ---
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)
--- Quote ---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]
--- End quote ---
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.
--- Quote ---I hope that made sense. ???
--- End quote ---
Yup, cleared up my questions. :D
Know anything about writing windows drivers? ;D 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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version