4 player options besides iPac

[Trip]

What other options are out there for a 4 player panel besides a keyboard emulation controller like ipac?  Been looking to get a Lono2 but apparently they were discontinued.

Currently have an iPac and just keep getting stupid keyboard conflict error outs when people bang on a lot of the buttons.

Any other affordable options?  Can you run two xin mo boards to do the same thing as a lono?

[Slippyblade]

You can mix and match however you want.  Using multiple Xin-Mo's would simply show up as extra gamepads in your setup.  Mame doesn't really care what you have and you can configure the inputs to literally whatever you want.

Is it keyboard encoders in general that you are averse to, and if so, why?

[Trip]

You can mix and match however you want.  Using multiple Xin-Mo's would simply show up as extra gamepads in your setup.  Mame doesn't really care what you have and you can configure the inputs to literally whatever you want.

Is it keyboard encoders in general that you are averse to, and if so, why?

Yeah, I want to stay away from keyboard encoders.  I have so many buttons, when get a big group of people drinking beer and they start banging on them, they manage to keep finding new combinations that cause some sort of windows error that crashes gameplay.  I hoping gamepad encoders will get rid of this issue.

What options are out there for these and where to get them?

[Slippyblade]

Take a look at Groovy Game Gear's GP-Wiz.

http://groovygamegear.com/webstore/index.php?main_page=product_info&cPath=76_81&products_id=235

The Xin-Mo things work just fine, I've used em.  But they are cheaply made.

[PL1]

Did you disable the default shifted functions on the IPac?

That and changing a few other default keys (like Ctrl and Alt) could avoid tons of trouble caused by button-mashing.


Scott

[ark_ader]

2X Xgaming boards. 

[PL1]

2X Xgaming boards. 

      



Scott

[yotsuya]

The Howler is also a 4 player option.

[Slippyblade]

The Howler is also a 4 player option.

Isn't the Howler a key encoder though?  He wants to avoid those.

[rCadeGaming]

You should be avoiding joystick encoders, they add more input lag in MAME than keyboard encoders.  If it's properly set up, you won't have any problem with unintended key combos.

[PL1]

You should be avoiding joystick encoders, they add more input lag in MAME than keyboard encoders.

Interesting hypothesis.  What do you base that assertion on?

AFAIK there hasn't been any objective, quantifiable, and duplicatable test methodology developed to benchmark/compare encoder lag.

The closest I've seen is the test that Todles did (referenced here) that appears to have less-than-ideal methodology as mentioned in that thread.

Fieldofcows suggested an approach that might work, but the KADE team hasn't gotten around to implementing and testing it yet.

I would probably look at using a microcontroller or development board that supports USB OTG and program it to recognise HID devices. You could then directly set the test contact in firmware and measure exactly when the HID report arrives. This can then be reported back either on an LCD or via USB if the development board supports this as well as OTG.

Scott

[yotsuya]

The Howler is also a 4 player option.

Isn't the Howler a key encoder though?  He wants to avoid those.

According to the specs on Paradise's site, inputs can be programmed as either joystick inputs or keystrokes.

[Trip]

Did you disable the default shifted functions on the IPac?

That and changing a few other default keys (like Ctrl and Alt) could avoid tons of trouble caused by button-mashing.


Scott

The problem is I run out of options, I need somewhere around 56 keys for my entire setup.

[pbj]

I have a lono 2 in the parts drawer that I will never use.

Make me an offer.

[rCadeGaming]

You should be avoiding joystick encoders, they add more input lag in MAME than keyboard encoders.

Interesting hypothesis.  What do you base that assertion on?

Correct me if I'm wrong, but:
MAME uses the RawInput API for keyboard inputs.  It does not use it for joystick inputs, making them slower.

http://forum.arcadecontrols.com/index.php?topic=133194.0

OP there is nothing wrong with your IPAC.  Fix the problem by setting it up properly.  As mentioned by others, disable shift functions, unmap keys like CTRL, ALT, F keys, etc.  Don't try just throwing money at the problem.  It's wasteful, the work of installing a different encoder is totally unnecessary, and you might just add a different problem.

[AndyWarne]

OP there is nothing wrong with your IPAC.  Fix the problem by setting it up properly.  As mentioned by others, disable shift functions, unmap keys like CTRL, ALT, F keys, etc.  Don't try just throwing money at the problem.  It's wasteful, the work of installing a different encoder is totally unnecessary, and you might just add a different problem.

+1

The original choice of keys in Mame was not an ideal one but all can be changed. If you cant overcome the issues drop me an email and I will try to help.

andy@ultimarc.com

[WakiMiko]

The original choice of keys in Mame was not an ideal one but all can be changed.

This is just a guess, but the MAME developers probably chose the modifier keys (CTRL, ALT, SHIFT) as defaults in order to get around ghosting/rollover issues.
When pressing multiple "letter" keys together, most cheap keyboards will fail to recognize certain key combinations. The IPAC handles it just fine, however.

[wirenut]

OP there is nothing wrong with your IPAC.  Fix the problem by setting it up properly.  As mentioned by others, disable shift functions, unmap keys like CTRL, ALT, F keys, etc.  Don't try just throwing money at the problem.  It's wasteful, the work of installing a different encoder is totally unnecessary, and you might just add a different problem.

+1

The original choice of keys in Mame was not an ideal one but all can be changed. If you cant overcome the issues drop me an email and I will try to help.

andy@ultimarc.com

Do this.  I was sure that I had a dead PAC 64 and after several emails, Andy brought it back to life!  There is a reason that the Ipac is the most used encoder.  Just fix it.

[RandyT]

You should be avoiding joystick encoders, they add more input lag in MAME than keyboard encoders.

This really couldn't be further from the truth.  At the system level, joystick controls are given high priority, as latency is very undesirable in the applications for which they are used.  Conversely, keyboard priority can be lower, as people typically can only type so fast, and low latency is far less important for keyboards.  There's also the fact that the USB gaming control reports use bitmapped representations of buttons, meaning that these require far less processing at the system level, and require as much as 1/8 or less of the data required by keyboard key reports to travel over the USB bus.

However, every interface is different, and latency is very dependent on the manner in which the hardware is implemented, and the quality of the device used.  Just because you found a cheap joystick controller which doesn't perform well, is no indication that all joystick encoders have those kinds of issues.  It's very much the same as driving a 1982 Geo Metro, and concluding that all cars can only reach speeds of 75mph, and get 32mpg.

That being said, a properly implemented device of either type, supported by a mature OS, is just fine for gaming requirements.  Especially in the case of older system emulation, where inputs are usually only read at  60hz (about 16ms).  If the controller latency, combined with the system processing of those events ends up beyond that, you might notice.  Otherwise, there should be few, if any, issues.

[rCadeGaming]

You sure about that?  That may be true in Windows, all things being equal, but not necessarily in MAME if a different API is being used for keyboards than joysticks.  I'm just going off what I've heard from knowledgeable people in the GroovyMAME section.

http://forum.arcadecontrols.com/index.php/topic,133194.msg1386069.html#msg1386069

[Nephasth]

I have a lono 2 in the parts drawer that I will never use.

Make me an offer.

$20 shipped.

[Trip]

Well I checked all my ipac keys, I only have letters, numbers and , . / ; ' \ - = `

I do not have any shift's, ctrl's, alt's or function keys...

shifted functions are all turned off,  I ended up purchasing two Xin Mos from GGG

[RandyT]

You sure about that?  That may be true in Windows, all things being equal, but not necessarily in MAME if a different API is being used for keyboards than joysticks.  I'm just going off what I've heard from knowledgeable people in the GroovyMAME section.

http://forum.arcadecontrols.com/index.php/topic,133194.msg1386069.html#msg1386069

Yes.  Any Input API not capable of 60hz speeds would be pretty worthless.  Even VB6 could do timed events close to that range.  That is not to say that a specific version of MAME, which may include hacks to do "who knows what" isn't spending time doing something else when it should be processing inputs in order to meet the requirements of the original ROM.  But there are usually smart people working on these things, and who understand that requirement.

I just spent a little time looking at the discussions regarding lag testing, as I have done in the past.  In all honesty, few, if any, are using what I would call absolutely controlled methods.  Even those who attempt to, seem to lack the fundamental understandings of all of the parts and how they work together, in order to even have a fighting chance at a correct conclusion.

There is a possibility for issues at every level of the system, and different users will end up with different results, based on the hardware at each level.  For example, two individuals could have the exact same system where everything has zero lag.  The second one of them decides to use a random LCD panel, instead of the CRT the other individual uses, or changes the interface to one which routinely debounces inputs for longer than a frame refresh, or a switch gets dirty and a variable debounce routine takes longer to process, it all goes out the window.  The same can happen at any level of the system, so disparate individuals comparing their findings, each using different testing techniques and different hardware, will not be a very useful endeavor. 

[Trip]

While I wait for the xin mo's, I got these from amazon and had a little fun with my vinyl cutter.

Been playing a lot of Tecmo football and the joysticks and buttons weren't cutting it.

[Calamity]

Yes.  Any Input API not capable of 60hz speeds would be pretty worthless.  Even VB6 could do timed events close to that range.  That is not to say that a specific version of MAME, which may include hacks to do "who knows what" isn't spending time doing something else when it should be processing inputs in order to meet the requirements of the original ROM.  But there are usually smart people working on these things, and who understand that requirement.

I just spent a little time looking at the discussions regarding lag testing, as I have done in the past.  In all honesty, few, if any, are using what I would call absolutely controlled methods.  Even those who attempt to, seem to lack the fundamental understandings of all of the parts and how they work together, in order to even have a fighting chance at a correct conclusion.

Hi RandyT,

Just to clarify, we never intended to affirm that joystick encoders added more lag than keyboard encoders. It's only that MAME (both official and GroovyMAME) use the raw input api for keyboards and mice, while it still uses the DirectInput api for joysticks. Because Microsoft documentation says DirectInput adds some overhead (due to using a separate thread for polling input) some people just assumed that "overhead" means "lag", which is not necessarily true. I just claimed I was using a keyboard encoder in my tests to discard this hypothetical source of lag (in MAME) in the first place.

In fact I've always mantained that in IMHO 16.7 ms is plenty of time at today's computer scale to process input messages right for the next frame, with any half decent hardware. My tests were more focused on proving wrong the myth that v-synced emulation must by its own nature lag at least one 1-frame more than the real hardware (http://forum.arcadecontrols.com/index.php/topic,133194.msg1381183.html#msg1381183). In fact what we found is that the most probable source of lag which people claim to "feel" must come from a frame queue that video drivers secretly arrange when using Direct3D (probably just in order to cheat on 3D performance tests).

Finally, I'd love to hear what concrete conceptual flaws you find in the test I posted about here: http://forum.arcadecontrols.com/index.php/topic,133194.msg1377633.html#msg1377633
... forget about the part where I suggested to put monitors upside down, that was supposed to be a joke

(I'm writting this from all my respect and admiration)

[RandyT]

In fact I've always mantained that in IMHO 16.7 ms is plenty of time at today's computer scale to process input messages right for the next frame, with any half decent hardware. My tests were more focused on proving wrong the myth that v-synced emulation must by its own nature lag at least one 1-frame more than the real hardware

I agree with what you are stating.  My comments weren't directed at what you are doing there, as it is well beyond controller lag, but that does demonstrate how complex all of the interactions can be.   There is so much different hardware and software in the chain of every different system in use, narrowing down which is responsible for some of these tiny delays becomes a huge endeavor.  At some point, folks who feel the need for perfect accuracy, should probably consider original hardware.  But it's great that folks like you are working diligently to make things the best they can possibly be on the software side of things.

I may have a couple of comments on the setup, but I'll post in that thread a bit later if it seems like it would be helpful.