Mouse/Trackball/Spinner Lag In MAME?

[FrizzleFried]

Wade,  in another thread mentioned that playing trackball games through MAME annoyed him (I am paraphrasing here) because of the lag between the physical movement and the reaction on screen.   He also mentioned this lag is evident with spinner games.  Of course being that both are recognized as a MOUSE,  a mouse itself would also experience this lag. 

Do you experience any lag while using a trackball,  spinner or mouse in MAME?  Please vote,  then post your response with the version of MAME you are using and whether your trackball,  spinner,  or mouse is a USB or PS2 device.

Thanks!

[Zeppo]

I got no lag.
I use a mouse hacked spinner, and it works great.
Trackball as well.
I have used Mame 106, 107,109, and currently 114.

[Havok]

I don't see it, however I haven't played a "classic" since back in the day. It's been Mame only for me since the late 90's (except for my Sega Turbo)... But, I have a screamin' new pc running Mame with a PCI-e video card...

 

[ahofle]

Personally I see more lag in regular button presses.  Try firing (space invaders or centipede or something similar) and you'll see a very small delay between the time you press the button and the time you actually fire.  I hardly notice any delay for analog input.   

[shardian]

I have a TT1 and I think it is very responsive. Of course, I suck at spinner games, and I have zero experience on original equipment spinner games.

[Hoopz]

My tron spinner has no delay.  It's connected through my Opti-pac as is my trackball.  Both work very well. 

[u_rebelscum]

Any lag I see is easier seen in windows than in mame: my work wireless M$ mouse (very minor) and my laptop touchpad (a little more, but not too bad).  My trackballs & spinners are fine.

[Crowquill]

Part of the argument was that it wasn't that noticable on it's own, but compared to the original there was a definite lag.

Havok--do you have a spinner on your MAME cab that you could compare to the real Turbo?

Another thing I'm wondering is whether the type of input matters  (ps/2, serial, USB), if the OS matters (does Windows create a bottleneck), or has it changed within different versions of MAME.

Also, is there a way to quantify this or does it just "feel different"?

It still seems strange to me that the MAME devs are so obsessive on accurate emulation but would skimp on the controls.

[FrizzleFried]

I'm tellin' ya crowquill,  there is no lag.  It just isn't there.  I play Tempest ALL THE TIME at my local arcade and my spinner actually is MORE responsive.  I played Missile Command on my cabinet this morning and I ain' t BSing when I say there is no lag.  I am not sure what Wade is talking about...maybe he hasn't used a later version (I am on .108 with my horizontal cabinet) and man,  there's NO lag...none...zero...zilch.

As I said in your thread,  it may be a USB vs PS2 thing?  I am using a USB trackball...and USB spinners...

[RandyT]

This may be something that has more to do with an individual title than MAME itself.  The only game I can remember feeling "weird" or laggy is Centipede.  Keeping in mind that I'm not running an extremely recent version of MAME and also haven't played a game of Centipede on a real machine in quite some time, the control of the MAME version just leaves you wanting more.  The trackball control in Centipede under MAME feels nothing like, say, the trackball control in Missile Command.  Or, IIRC, that of the original game.

I'm not a MAME dev, so I can't really say what the reasons are for this.  But I would surmise that each game has a chunk of code that does it's best to convert the function of the actual input hardware for that title to something MAME understands, and then MAME handles communication with the OS.  If so, then that code will vary based on who wrote it, as well as the hardware used by the title.

So I would say MAME=No lag, but "individual titles running under MAME"=possible lag.

RandyT

[Jeff AMN]

I don't get any lag at all.

I'm using MAME 114, a Tornado Spinner (bought it before TT2 was out), and a Happs 3" trackball. Everything is via USB.

[u_rebelscum]

Part of the argument was that it wasn't that noticable on it's own, but compared to the original there was a definite lag

Just because there is a noticeable difference from the original doesn't mean it's mame's fault.  (see below)

Another thing I'm wondering is whether the type of input matters  (ps/2, serial, USB), if the OS matters (does Windows create a bottleneck), or has it changed within different versions of MAME.

They can, and most delays are due to these rather than mame.  Serial is too slow in most cases; the hardware speed slowness adds lag time.  "Windows" has a few bottlenecks, but most of these can be attributed to the device driver or any filters rather than the OS itself.  Example: joy2key is a filter that can add delay of one (or two) frame. 

There are very few cases where any lags are due to changes in mame source: mame's switch from directInput to rawInput for mouse inputs might be one case even if theoretically it doesn't make a difference.

Also, is there a way to quantify this or does it just "feel different"?

Not being able to quantify problems could be one of the reason fixable problems aren't fixed.  How do you debug something if you don't know the exact symptoms?

It still seems strange to me that the MAME devs are so obsessive on accurate emulation but would skimp on the controls.

Well, while some MameDevs care more about inputs than others, from what I hear, quite a few test only with a keyboard and don't have spinners, trackballs, joysticks, or lightguns.  [shrug]

However, since most problem points are outside of mame, mame can't do much anyway.  And most games are 8-way + buttons inputs; inputs mame cannot do anything about.  I was going to go into more examples, but let me just put up a quick flow chart instead:

Arcade:

controller --------------------------------------------------> PCB ----> ROM


PC & MAME:

controller --> interface --> motherboard --> driver --> OS --> MAME ----> ROM

MAME emluates the original PCB.  Notice all the extra steps between the controller and mame.  I agree some games can and need work on the inputs.  However, sadly most problems most people have can't be fixed by mame.  A many that can be "fixed", can be done only with either hacks (ie moving away from accurate emulating), or reducing compatibility with the majority of mame users.

[Rocky]

I saw Wade's comment in the other thread and it got me thinking  He was specifically talking about Centipede.

I've never been a Centipede fan until I restored a Centipede cocktail earlier this year.  So, I decided to fire the game up on my Mame machine.

Sure enough, the trackball response is bad compared to the original.  I haven't noticed it in other games, but I really notice it in Centipede (especially since I have something to compare it to)


I'm using Mame .81  with a USB mouse hacked to a 3" trackball.

[Wade]

I play Tempest ALL THE TIME at my local arcade and my spinner actually is MORE responsive.

There ya have it... Frizzlefried has confirmed his MAME setup is actually more responsive than the original.  That should tell you something about the dependability of his statements on MAME accuracy.


Anyway, the lag is definitely there.  I haven't noticed button lag, but many people complain of that problem.  Just because I haven't noticed it doesn't mean it isn't there.  Why is analog input so much harder to believe?

Here are the setups I've tried:

Mouse/Trackball: RS-232, PS/2, and Serial (SORRY... I meant USB, not Serial!)
MAME platforms: win98 real DOS, Win98, Win2k
MAME Versions: 0.36 and many versions up to 0.10... no very late versions.
Games: Missile Command, Centipede, Millipede, Crystal Castles  (others too, I'm sure... I seem to remember Super Sprint showing similar problems)

I'm thinking it might have been fixed in a later version, there could have been a MAME setting somewhere that affects whether the delay is there or not, and no one else is fessing up to trying their MAME setup right next to the real game (which I have done with Missile Command and Crystal Castles).

I suppose I could make a video clip demonstrating it if I HAVE to and have the time, but honestly, I'm getting tired of ending up in arguements on this forum and being the person who has to carry the burden of proof, when I already know I'm right.  If you don't CARE if the games play accurately, that's okay - I just want more people to be aware of the problem, so it might eventually get fixed.  If you care, put the time and research into it, and maybe the problem can be solved.  If you simply don't care if it's accurate, then fine... but don't DENY the problem exists.

As far as being able to quantify it.  Easier said than done!  We're talking about an analog control being spun by a human hand.  It's like trying to quantify the difference in steering "feel" in different cars - it's easy to feel when using your arms to turn the wheel and feel the car's movement, but trying to measure it and distill it into something repeatable and quantifyable would be extremely difficult.  To continue the analogy, using MAME with trackball and spinner games "feels like there's a sponge in the steering linkage."

Wade

[Rocky]

I've also got a Marble Madness cabinet.  I'm going to test how it responds against my Mame setup and let you know. Hopefully I can get to it tomorrow.


(I'll have to take the Peter Packrat kit out of it and put the Marble Madness board and CP in, then I'll test it out)

[Wade]

I've also got a Marble Madness cabinet.  I'm going to test how it responds against my Mame setup and let you know. Hopefully I can get to it tomorrow.

(I'll have to take the Peter Packrat kit out of it and put the Marble Madness board and CP in, then I'll test it out)

I definitely appreciate the support with your Centipede assertion...  But the nature of the ball "inertia" in Marble Madness would probably hide any delays present in that particular game, wouldn't it?  (Just my guess...) There isn't that direct 1:1 spin/travel link that exists in Centipede, MC, CC, etc.

Thanks,
Wade

[ahofle]

I for one would like to see a video simply because I have no idea how bad this lag you are experiencing is.  And you should also update your MAME to see if the problem has been fixed.

[Rocky]

I definitely appreciate the support with your Centipede assertion...  But the nature of the ball "inertia" in Marble Madness would probably hide any delays present in that particular game, wouldn't it?  (Just my guess...) There isn't that direct 1:1 spin/travel link that exists in Centipede, MC, CC, etc.

Thanks,
Wade

There's no doubt that the controls are interpreted differently.  Centipede is an exact match (shooter to ball), whereas MM is momentum.

But, I think I'd be able to tell if they play differently.  Although, the trackball sensitivity would play into it.

[Rocky]

I for one would like to see a video simply because I have no idea how bad this lag you are experiencing is.  And you should also update your MAME to see if the problem has been fixed.

I really have no need to update my version of MAME.  I love the classics and they are all in the version I use. Also, I play the my original machines more than my Mame machine  (although visitors, especially kids, love the multi-game better    )

The lag is minor but noticable.  As you all know, the feel of the controls makes a big difference in playing the game.  After playing a few hundred games of Centipede on an original machine, I can verify that it does "feel" and respond differently on Mame.

[u_rebelscum]

Marble Madness and Centipede are two games that might have problems with control, for two different reasons.  There's not much mame can do to "fix" the known problems.  (MM was going to be one of my examples I didn't post earlier.)

MM had it's TB rotated 45 degrees.  Mame has to convert the PC's (x,y) to the game's, umm, (Northeast, Northwest) coordinates.  In doing so, you only have half the precision as the original game no matter what settings you have in mame or windows, even (or especially) mouse drivers that let you roate which direction is up. 
Examples: mame can send the ROM (0,0), (0,2), (1,1), (2,0) & (2,2), but not (0,1), (0,3), (1,0), (1,2) or (2,1). 
The only way to be able to get the full precision is rotate your TB, remove the conversion code from mame and recompile.
Whether you can feel the reduction in precision due to mame is debatable.  Heck, even if there are differences from the original that you can feel, contributing it to mame is also debatable.  If all you feel is lag, it's not due to the conversion code.

Centipede has 4 bits per axis.  (For comparison, most PC mice and later arcade games have 8 bits per axis.)  4 bits results in 1 bit for direction and 3 bits for speed.  That means the max speed is only seven!.  A long running complaint is that centipede is too slow in mame (not lag).  So if it's true... either mame is missing a bit or two (and those bits are hidden some where funny), or the original game polls the inputs faster than mame, or something else.  It's been looked into a lot, and nothing found so far.

Here are the setups I've tried:

Mouse/Trackball: RS-232, PS/2, and Serial

RS-232 & serial are way too slow.  PS/2 might be, so the poll rate might need to be increased.  Search for posts at this forum on this: here are the first 2 posts I found: thread 1thread 2  (both talking about backspin, though)

MAME platforms: win98 real DOS, Win98, Win2k
MAME Versions: 0.36 and many versions up to 0.10... no very late versions.
Games: Missile Command, Centipede, Millipede, Crystal Castles  (others too, I'm sure... I seem to remember Super Sprint showing similar problems)[/quote]

Thanks for the info (one more question: all on same computer?).  They really helps debug problems.  Except...

... and no one else is fessing up to trying their MAME setup right next to the real game (which I have done with Missile Command and Crystal Castles).

...I wish I had one of those so I could help debug (or any original cab for that matter).

I suppose I could make a video clip demonstrating it if I HAVE to and have the time, but honestly, I'm getting tired of ending up in arguements on this forum and being the person who has to carry the burden of proof, when I already know I'm right.... but don't DENY the problem exists.

Although (or maybe because ) I don't have an original to compare side by side, the only lags I see in mame are with controllers I have lag in windows too. I'm not saying mame doesn't have any bugs on the inputs, or that there is not lag when playing games on you system in mame vs the original.  I am saying "It could be outside of mame, as many others have fixed their problems without changing mame."

As far as being able to quantify it.  Easier said than done! 

I totally agree.  Which makes it harders for other to know what to test.

[RandyT]

Centipede has 4 bits per axis.  (For comparison, most PC mice and later arcade games have 8 bits per axis.)  4 bits results in 1 bit for direction and 3 bits for speed.  That means the max speed is only seven!.  A long running complaint is that centipede is too slow in mame (not lag).  So if it's true... either mame is missing a bit or two (and those bits are hidden some where funny), or the original game polls the inputs faster than mame, or something else.  It's been looked into a lot, and nothing found so far.

I have a feeling that something is amiss with the code doing the translating..

 As I understand it, most games do their controller sampling during the vertical blanking period, which occurs 60x a second (please correct me if I'm wrong.)  With a horizontal resolution of only 240 pixels, it should only take about 1/2 second to traverse the screen width, moving 7 positions at a time.  It doesn't move anywhere near that fast, and lack of speed isn't the only odd thing this title exhibits.

The action on Centipede looks an awful lot like what one would get if they converted an optical control to analog joystick scheme, much like you might see with a mouse to XBOX FPS conversion.  I would think that if it were missing bits, there wouldn't be "delay and then catch up" movement, rather it just wouldn't move as fast.  Do you know if there is more logic involved in the translation than just capping the speed at 3 bits? 

Also, do you know whether Tempest (another Atari optical controller game produced at the same time) also used this 4-bit control scheme?  If so, much would be explained about that one as well.

RandyT

[Wade]

I for one would like to see a video simply because I have no idea how bad this lag you are experiencing is.  And you should also update your MAME to see if the problem has been fixed.

I might be able to make a video, but honestly I think it would be harder to see than it would be to feel.  Not sure it would demonstrate the problem.

I agree, I need to try a newer version of MAME and see if it has the same problem.  Maybe it's been fixed?

Wade

[Wade]

Centipede has 4 bits per axis.  (For comparison, most PC mice and later arcade games have 8 bits per axis.)  4 bits results in 1 bit for direction and 3 bits for speed.  That means the max speed is only seven!.  A long running complaint is that centipede is too slow in mame (not lag).  So if it's true... either mame is missing a bit or two (and those bits are hidden some where funny), or the original game polls the inputs faster than mame, or something else.  It's been looked into a lot, and nothing found so far.

Well, this sounds to me like the long running complaint is probably the same problem, but just described incorrectly.  It isn't too "slow", there's just a delay.  Move your mouse around in windows with no acceleration.  You get a 1:1 movement of the pointer versus the mouse.  Stop, it stops at the same time,  Start, it start ats the same time, and it follows your path perfectly.  Centipede and MC and others work exactly the same way, but in MAME it's like there's a delay behind everything you see onscreen versus what you do with the ball.  This is the best way I can explain it.

Here are the setups I've tried:

Mouse/Trackball: RS-232, PS/2, and Serial

RS-232 & serial are way too slow.  PS/2 might be, so the poll rate might need to be increased.  Search for posts at this forum on this: here are the first 2 posts I found: thread 1thread 2  (both talking about backspin, though)

Whoa!  I meant USB, not Serial for the last one (corrected).

I don't think RS-232 or serial are too slow.  Here's why.  I can use a serial mouse in Windows and there is no lag and the pointer reacts properly.  Why would there be a lag in MAME, then?

Regardless, I have found the same problem even when using USB.  I think this pretty much rules out speed as an issue.

MAME platforms: win98 real DOS, Win98, Win2k
MAME Versions: 0.36 and many versions up to 0.10... no very late versions.
Games: Missile Command, Centipede, Millipede, Crystal Castles  (others too, I'm sure... I seem to remember Super Sprint showing similar problems)

Thanks for the info (one more question: all on same computer?).  They really helps debug problems.  Except...
[/quote]

No.  When looking into this before, I tried it on a handful of other PC's, like a 1ghz notebook and some PC's at my office.  All had the same problem, regardless of mouse type/interface or PC speed.

... and no one else is fessing up to trying their MAME setup right next to the real game (which I have done with Missile Command and Crystal Castles).

...I wish I had one of those so I could help debug (or any original cab for that matter).

I wish everyone did.  Then there would be no debate about this problem.  People would be spending their time solving it instead.

I suppose I could make a video clip demonstrating it if I HAVE to and have the time, but honestly, I'm getting tired of ending up in arguements on this forum and being the person who has to carry the burden of proof, when I already know I'm right.... but don't DENY the problem exists.

Although (or maybe because ) I don't have an original to compare side by side, the only lags I see in mame are with controllers I have lag in windows too. I'm not saying mame doesn't have any bugs on the inputs, or that there is not lag when playing games on you system in mame vs the original.  I am saying "It could be outside of mame, as many others have fixed their problems without changing mame."

Well, I quickly ruled out Windows or the controllers individually as not being the root cause of the problem.  The problem either lies inside the MAME code (my bet) or in a subsystem that mame uses (however, that seems unlikely since the problem is apparent in DOS as well as Windows versions).

As far as being able to quantify it.  Easier said than done! 

I totally agree.  Which makes it harders for other to know what to test.

I don't know what else to tell you.  Aside from digging into the code myself, I don't know what else I can do.    I suppose someone could just start stripping parts of the trackball code until the delay is isolated.

  I'm starting to wonder if it's just an effect of translating and emulating the inputs.  It's possible that it CAN'T be fixed in MAME.  I hope that's not the case, though!

Wade

[telengard]

This topic has come up before in the past glad to see it discussed again.  Centipede is definitely one in my cab that exhibits lag.  I can't say that I notice in MM, there's a feeling of inertia in the original too, at least to me.  One other game I notice a significant lag from me moving the spinner and seeing on screen movement is Arkanoid.  I've tried a bunch of different spinners too, usb, serial, you name it.  Tempest, etc play fine for me though.

~telengard

[Crowquill]

OK--just did a quick informal test. Centipede definitely doesn't seem to be as responsive as even Millipede (which still felt at little behind). Missile Command, Tempest, and Arkanoid seemed to respond immediately. As did Super Sprint, Off-Road, Omega Race, Tron, Pole Position II, Super Breakout, and Bad Lands.

I don't have a trackball or spinner set up yet, I was just using a USB mouse in...

MacMAME 1.03u

I just noticed Centipede and Millipede share the same driver. I'm not sure how much of the input code is shared though.

[FrizzleFried]

I don't have a trackball or spinner set up yet, I was just using a USB mouse in...

MacMAME 1.03u

But does MacMAME count?!?   

 

[u_rebelscum]

I have a feeling that something is amiss with the code doing the translating..

 As I understand it, most games do their controller sampling during the vertical blanking period, which occurs 60x a second (please correct me if I'm wrong.) 

Forget what I said about centiped, above; I had it close but still wrong.  First, there are 4 bits for speed and another one for direction.  That means a max speed of 15 per poll.  However, quote from source:

Code: [Select]

* The counter is read 240 times per second. There is no provision whatsoever
 * to prevent the counter from wrapping around between reads.
If this is correct, then centiped is unusual in that it polls 4x per frame (with its screen refresh rate of 60 Hz).  (As Randy said, the normal is once per frame.)

Compair centiped's 240 Hz with the normal USB & PS/2 poll rate of 125 Hz - almost half the rate, and serial rate of ~40 Hz - about 1/6th.  To paraphrase Derrick "Chuck your serial mice."  Why centiped needs to poll 4x per frame, I don't know, but it being so much faster than standard PCs could be the major cause of the delay.

Also, do you know whether Tempest (another Atari optical controller game produced at the same time) also used this 4-bit control scheme?  If so, much would be explained about that one as well.

As for Tempest, it looks like it only polls once per frame, and yes only a total of 4 bits per axis.

I just noticed Centipede and Millipede share the same driver. I'm not sure how much of the input code is shared though.

They use the same.  Not sure about if they have the same polling rate, though.

[2600]

If this is correct, then centiped is unusual in that it polls 4x per frame (with its screen refresh rate of 60 Hz).  (As Randy said, the normal is once per frame.)

Compair centiped's 240 Hz with the normal USB & PS/2 poll rate of 125 Hz - almost half the rate, and serial rate of ~40 Hz - about 1/6th.  To paraphrase Derrick "Chuck your serial mice."  Why centiped needs to poll 4x per frame, I don't know, but it being so much faster than standard PCs could be the major cause of the delay.

I believe Derrick also mentioned something about not people listening to him when he recommend upping the USB poll rate to at least 250Hz for low speed USB devices.  Although, I admit I still prefer using full speed devices over low speed ones.

[Wade]

I think you're barking up the wrong tree.  Does the original centipede REALLY poll 240 times per second?  Seems unlikely.  What would be the point of doing that?  Not to mention, I see the exact same delay whether I use an RS232 mouse or a USB mouse, and I see the same delay in every trackball/spinner game I've tried.  But, please, exhaust all the possibilities.  It'd be fantastic if this could be resolved, and it's only going to happen if some people take real initiative and dive into it in depth and be persistent about it.

Wade

[RandyT]

I think you're barking up the wrong tree.  Does the original centipede REALLY poll 240 times per second?  Seems unlikely.  What would be the point of doing that?  Not to mention, I see the exact same delay whether I use an RS232 mouse or a USB mouse, and I see the same delay in every trackball/spinner game I've tried.  But, please, exhaust all the possibilities.  It'd be fantastic if this could be resolved, and it's only going to happen if some people take real initiative and dive into it in depth and be persistent about it.

I have to agree.  Control implementation for this title appears to need some tweaking, and I believe that Tempest is affected similarly.  I say this because of both titles incredible sensitivity to too much movement data.  I wish I could contribute in fixing the issue from the code side, but I'm not the guy for the job.  So some attempt at problem identification will have to suffice as the extent of my contribution.

I just did some more tests with Centipede using a TurboTwist2 connected to an experimental 500hz firmware under Win98 (so the rate actually gets honored.)  At the desktop, you can zing it like madman and the cursor gets welded to the edge of the screen.  Not the slightest hint of backspin, no matter the abuse.

I tested this control with Centipede, using a number of different sensitivity settings, and found that the behavior was pretty much the same as with the trackball.  IOW, polling rate has little to no effect on the issues.  However, I think I may have been able to get a better idea as to what is happening. 

At very low speeds, the movement appears to be accurate.  Same results with a trackball (using upgraded encoder wheels.)  But when a higher speed of movement is reached at the control, the "gun" movement actually slows down.  The faster the movement at the control, the slower the "gun" moves as it approaches a backspin condition (especially at higher sensitivity levels.)  As the control coasts and starts to move more slowly, the "gun" movement will again speed up.  This is why it feels "laggy".  You hit it with a hard and fast spin and it goes very slow (or doesn't move much at all) and then, as it gets into the proper "speed zone", it starts to move as it should.

Forget what I said about centiped, above; I had it close but still wrong.  First, there are 4 bits for speed and another one for direction.  That means a max speed of 15 per poll.  However, quote from source:

Code: [Select]

* The counter is read 240 times per second. There is no provision whatsoever
 * to prevent the counter from wrapping around between reads.

If this were true, a polling speed of 100hz would give you a theoretical screen width traverse time, if my math is correct, of about .16 of a second on a control that was capable of delivering a full 15 positions of movement per sample.  Honestly, this just isn't happening.  The idea that the polling rate is insufficient doesn't really hold up with these numbers either.  I would think that an insufficient poll rate would only be a problem in the event that the data was missed due to too infrequent polling.  However, using the example of 240hz polling by the game, with a maximum movement of 15 positions and a USB polling interval of 100 hz, the game is essentially doing a 2.4x oversample, which would greatly reduce or eliminate the possibility of missed control data.

It looks like what might be happening is constant overflow of the inputs at the driver level.  The interesting part is that the speed of the "gun" at overflow appears to be fixed at  a speed lower than what is possible when moving the control at a speed the game prefers. 

Some things to think about regarding the amount of movement data that is generated by the controls.  With a standard mouse interface operating at 4x on a trackball using the original encoder wheel, it is still 4x the data, assuming the control originally operated at 1x like Tempest did.  Now tack on the fact that most are trying to use it with a 3" trackball instead of the 2.25" of the original (about 30% more data based on the difference in circumference) and there are a lot of extra bits flying at the original hardware.  And this speaks nothing of upgraded encoder wheels, or higher resolution PC mice/trackballs.  If nothing is in place to cap the movement data at the max of 15, based on the 4 bit speed, then what happens when the movement data indicates a 16 or 30 or 50 position jump?  Perhaps it's not overflow at all and related more to the way sensitivity is calculated in MAME.  Is it possible that it might be somewhat incompatible with the 4-bit scheme? 

Hopefully all of  this rambling is useful to someone for finding out what's really happening here.  The worst part about all of this is that the code might not be "broken" from a technical standpoint, rather from the standpoint of usability with what is considered the norm for controls connected to a modern PC.

RandyT

[Wade]

I guess the week of people caring about MAME accuracy has ended. 

Wade

[Kremmit]

I guess the week of people caring about MAME accuracy has ended. 

Wade

I hope not.

[Scassidy24]

Well that is all rather mind numbing stuff.  I'be just got my cabinet together and got my groovy trackball and tt2's all working fine and windows and Arkanoid works flawlessly IMHO with the tt2 spinner but I can't even attempt to play centipede or MIssile Command because of what seems like a lot of cursor movements getting queued up and then slowly they all eventually act out in the game. Example. I can whip the trackball left right left right and then watch it happen afterwards in missile command and in centipede. Wondering if I should be looking at adjusting something somewhere or if it is a lost cause?

Mame 0.161
MaLa front end
USB (turbo twist and opti whiz and key whiz On USB hub)

Sent from my iPhone using Tapatalk

[RandyT]

Wow, this is an old thread

But sadly, I don't think much has happened to address the issue.  After re-reading what was written here nearly ten years ago, I have a theory as to what happens in MAME (and I could certainly be wrong).

If the title exhibiting lag was originally sampled at the hardware level at a rate 4x greater than the norm, which the driver may be attempting to do for reasons of authenticity, and the core MAME code is designed to handle this data at a different rate, it stands to reason that the driver would queue the data in a buffer, perhaps capping it at a size compatible with the title, and then deliver it to the ROM at a predetermined (slower) rate which is compatible with the rest of the emulation code.  The net result of doing things in this manner would likely be consistent with the behavior we have all observed.  I.e. slow movements (those not requiring any buffering) being an accurate 1:1 correlation, and faster movements feeling like they are lagging, because the small movement data would be fed out in a time frame possibly 4x larger than what would occur with the original hardware.

If this is the case, it will likely never be fixed without a hack being made, as the emulation would be correct, but is hindered by the standard code of the several layers between the ROM, controls and display.

Again, this is just theory based on a possible coding approach, having not gone through the actual code.

[Scassidy24]

So polling rates nowadays with Windows 7 and these turbo twists and groovy trackballs on USB.  Is adjusting polling rate something I shlould try?  I can live with some delay or lag, but currently centipede. Sprint and missile command (among others I'm sure) are un playable on my Machine.  Can I get them to a playable state by adjusting polling rate in Windows or does it all only come down to trial and error with tweaking the Mame analog settings?

Randy are your games (the usual culprits) at least playable for the novelty factor?  What is your setup?

I've been able to remove the backspin effect just by tweaking mame analog settings  for tempest, and I've gotten Tempest to a point where I'm happy having never played the original.  It would be nice to be able to at least play centipede and missile command even if it's not perfect.


Sent from my iPhone using Tapatalk

[RandyT]

So polling rates nowadays with Windows 7 and these turbo twists and groovy trackballs on USB.  Is adjusting polling rate something I shlould try?  I can live with some delay or lag, but currently centipede. Sprint and missile command (among others I'm sure) are un playable on my Machine.  Can I get them to a playable state by adjusting polling rate in Windows or does it all only come down to trial and error with tweaking the Mame analog settings?

Polling rates for these types of games, are IMHO, much to do about nothing.  The standard polling rate under Windows is 8ms.  This means that the controls are polled twice as fast as the polling done by MAME, if the games originally polled once per screen refresh (1/60th of a second, or 16.66ms.)  Any issues you might be seeing are a result of the MAME emulation, either in translation or in configuration.  IOW, if you don't see the same type of issues at the cursor in your OS desktop, then it has nothing to do with the controls or the interface. 

If MAME isn't polling the controls faster than the system, and it doesn't, then faster polling really does little more than add additional traffic to the USB bus (possibly slowing down other attached devices and/or the system), with virtually no practical gain.  What MAME does with the data it receives, and when, is the largest factor.

The only titles I have seen which are really poor are Centipede/Millipede.  The others you mentioned work quite well, once you have the sensitivity for those titles adjusted to your liking.  Some experimentation will be necessary to find what you personally prefer.

[opt2not]

Old thread indeed!
I remember feeling lag on my optipac w/ Advmame (v.106) for certain games on my cocktail unit nearly 7 years ago...wow it's been a while. One particular game where it was really bad was Nihon's Freekick, a soccer style variant of arkanoid. I know it was bad because I also owned the real PCB and was able to compare the responsiveness.  Certain games worked well though, like real Arkanoid and Tempest, but others had to be tweaked a lot and it still didn't get the right feel. 
This thread makes me miss my cocktail cab. Gonna have to build another, one of these days.

[Scassidy24]

interesting thread here talking about trackball movement and voltage might shine some more light on the issue, not that I can help it but more information in one place can't hurt.

https://www.reddit.com/r/MAME/comments/4e1ehy/golden_tee_mame_trackball_settings/

[RandyT]

interesting thread here talking about trackball movement and voltage might shine some more light on the issue, not that I can help it but more information in one place can't hurt.

https://www.reddit.com/r/MAME/comments/4e1ehy/golden_tee_mame_trackball_settings/

What is written there is so erroneous, I'm not even sure where to start.  While I suppose it is possible to get a usable analog voltage from spinning a trackball, with some extra circuitry to smooth out and average the pulse train coming from the encoders, it will never exceed the 5v powering the TB circuitry.  But that's all academic, because they just don't work that way. Trackballs aren't "power generators" and they certainly won't be producing any negative voltage, so how could one even start to use this as a basis for deciphering direction?

Trackballs, standard optical mice, and spinners are digital devices, but treated as "analog" controls, because they are not strictly on/off, like switches, with regard to the data being presented to MAME.  But at the lowest levels, they output 1's and 0's (high and low voltage levels) just like switches.  The difference is that there are two channels of these 1's and 0's for each axis, and the data streams are decoded to provide direction and distance information, by whatever circuitry the unit happens to be connected to.

All of that said, the OP's issue in that thread, has no real connection to MAME, beyond the sensitivity settings.  MAME just applies a multiplier to the data it is being presented with.  If the resulting value creates an overflow condition, then the game code will act accordingly.  But based on the statement the OP made with regard to the sensitivity settings making no difference to his issue, I am assuming he has a poor interface connected, which is incapable of handing such high speed spins, or just as likely, a hardware problem with his trackballs optical sensors.  IOW, garbage in, garbage out .

[Scassidy24]

I've concluded that the problems I'm having are not specific to analog inputs. Just bad delay on all inputs with certain games, and the  inputs all pile up and wait to be executed by the game


Sent from my iPhone using Tapatalk