Main > Main Forum
4 player options besides iPac
<< < (5/6) > >>
Nephasth:

--- Quote from: pbj on May 11, 2014, 07:51:26 pm ---I have a lono 2 in the parts drawer that I will never use.

Make me an offer.

--- End quote ---

$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:

--- Quote from: rCadeGaming on May 14, 2014, 06:57:40 am ---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

--- End quote ---

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:

--- Quote from: RandyT on May 14, 2014, 12:10:12 pm ---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.

--- End quote ---

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)
Navigation
Message Index
Next page
Previous page

Go to full version