| Main > Main Forum |
| USB "Gamepad" encoder questions |
| << < (7/9) > >> |
| tetsujin:
--- Quote from: u_rebelscum on January 28, 2005, 08:13:28 pm ---I know most of this has already has been touched, but I thought I'd put my 2 cents in. --- Quote from: tetsujin on January 26, 2005, 02:28:47 pm ---First, are there any pre-made USB game controller encoders readily available? --- End quote --- Well, there's always happs interface:P If you don't mind $$$. --- End quote --- Ah, I thought that one was mainly a keyboard encoder. I guess it encodes with the joystick protocol, too, huh? I think so, anyway, it's not really clear in the case of the fighting encoder. That is crazy expensive, though. I mean, it's probably a good-quality thing, what with the non-volatile coin counter and watchdog timer, but I don't think I'm gonna need that. :) I don't think six axes and 128 buttons is going to be much of a limitation. :) I like not having to have special drivers, too. NBA: I know you can wire four player controls to any encoder with a sufficient number of inputs. What I was saying is that the PIC I'll be using doesn't have that many inputs. As for remapping to support games that aren't configurable... The ideal situation would be for the front-end to handle that. I launch a game, it sets up the right controls for me. No button-pressing, no control-panel opening... And there shouldn't be a need to re-flash an EEPROM to do it either. Those things can't be re-flashed indefinitely, after all. I don't see an automated keyboard encoder re-programmer as significantly less complicated a solution than using a software driver to translate the joystick to keycodes for the purpose of running old or otherwise backward software that doesn't support USB joysticks or an adequate level of configurability. There is the situation you cited where a particular game may support USB game controllers but not have a configurable button mapping... If I determine that I need to address that at the hardware level I could provide a way for the software to instruct the encoder to change its mapping at runtime. Hopefully I just won't have to bother with that at all. And then if I decided to play something like X-Wing with flight controls (I am planning a flight-control panel in the future, but not for a while), the keyboard encoding would have to be fairly sophisticated to handle things like the throttle anyway (repeated +/- throttle keystrokes along with (possibly) zero throttle/half throttle/full throttle to dead-reckon the throttle to match the analog throttle) - something like that could be done in firmware, but it's such a specialized thing it's really better done at the PC level. That's how I feel, anyway. That said, though, I think my NES and SNES emulators both support USB joysticks. "Timing-critical": You said for the games I listed I wouldn't have to worry about control latency. This means they must not be particularly timing-sensitive games. So in what games would I have to worry? |
| NoOne=NBA=:
--- Quote from: tetsujin on January 28, 2005, 09:07:36 pm ---"Timing-critical": You said for the games I listed I wouldn't have to worry about control latency. This means they must not be particularly timing-sensitive games. So in what games would I have to worry? --- End quote --- I don't think you're going to have timing related problems, which is why that question threw me. The problem you will most likely run into, with USB on an arcade cabinet, is when too many keys are pressed simultaneously, on a device that doesn't support it. The potential for that problem increases with the number of players. When you reach that point, the signs you see will appear similar to packet loss, rather than lag, on a network connection. You'll hit jump, but the computer will never see that keypress because it filled the packet with other commands. IIRC, the I-pac2 will only allow 16 simultaneous commands. (This may have been increased, or could be different) Two players would be very hard pressed to hit 16 inputs at any given moment. FOUR players could all be hitting a diagonal, and BOTH action buttons at the same time though. If someone tries to coinup at that exact moment in time (a difficult feat if you are also hitting both action buttons), a keypress will be dropped somewhere on those packets. Multiple encoders should reduce this effect because they will be polled independently, and will be able to send their full state on each poll. I have seen reports of specific devices, and/or hubs, creating problems. These were easy fixes in most cases, by either removing the device, updating drivers, or in extreme cases, switching one of the devices to the PS/2 port. |
| tetsujin:
--- Quote from: NoOne=NBA= on January 28, 2005, 11:05:48 pm --- --- Quote from: tetsujin on January 28, 2005, 09:07:36 pm ---"Timing-critical": You said for the games I listed I wouldn't have to worry about control latency. This means they must not be particularly timing-sensitive games. So in what games would I have to worry? --- End quote --- I don't think you're going to have timing related problems, which is why that question threw me. The problem you will most likely run into, with USB on an arcade cabinet, is when too many keys are pressed simultaneously, on a device that doesn't support it. The potential for that problem increases with the number of players. --- End quote --- I see. For USB Joystick encoders, the encoder could send the entire controller state with each interrupt. The tradeoff, as best I understand it, relative to a PS/2 keyboard encoder is that a keyboard encoder can send updates every millisecond (unless the host decides to send output to the encoder, in which case the encoder has to wait), but each update is just one state change: one button pressed/released, etc. But with multiple USB devices being serviced a USB joystick may have to wait 10ms before it can update anything. So in the same time it takes a USB joystick encoder to update its entire state (including the latency as it waits for its interrupt) a PS/2 keyboard encoder could update between 10-15 buttons (depending on the speed of the PS/2 bus on the host). A low-speed USB HID device can send I think 8 bytes of payload per interrupt... that'd be two axes plus 48 buttons. I don't know how a USB keyboard encoder would behave. Presumably it'd be the only device on the bus (and therefore get its interrupt every millisecond, or close to it) - I don't know if the commercial encoders are set up this way, but I'd assume that if too many state-changes appear at the same time, some of them may be delayed a millisecond to appear on the next interrupt. That's how I'd do it. Since the game is (I imagine) waiting at least 10ms between updating its internal notion of what buttons are being pressed, barring any complications I'd imagine the entire control panel on such a thing could change state and still get there "on-time"... |
| Tiger-Heli:
--- Quote from: tetsujin on January 28, 2005, 06:08:33 pm ---I don't know of any four-player games that use more than three buttons - not arcade games at least. --- End quote --- Dungeons and Dragons series in MAME . . . |
| Lilwolf:
Hate to say it... but... you still should really look at a keyboard encoder. Everything you have said is SCREAMING keyboard encoder. sure... if someone came up with a good usb joystick encoder that would be great... but nobody has yet (Dave?? How many connections can that chip of yours handle? Consider creating one?)... But you would find more problems with them. But until then... you will not find anything off the shelf work for you. You could find the fanciest joystick on the market and pull it apart to get its 20 connections... The speed issues your talking about is bunk though. The ps2 is fast enough for anything your tlaking about it. only about 1000 examples are here that are successful. |
| Navigation |
| Message Index |
| Next page |
| Previous page |