Trackball / Spinner Issues

[Farb]

Hi all,

Hope everyone had a great holiday!

I'm seeing a strange issue with my MAME cab using a Happ trackball / spinner with an OptiPac board via USB. Some games work just fine with the trackball or spinner (e.g. Tempest, Arkanoid, Missle Command). Certain games, however, have issues. They respond sporadically or with significant lag and it's almost like the control signals are "queueing up." For example, in Simpsons Bowling:

1. Spin the trackball right.
2. Character moves right.
3. Spin the trackball left.
4. Character continues to move right for two seconds then begins to move left.
5. Hit the exit button to quit the game.
6. Character continues to move left for four seconds.
7. The game exits.

I'm seeing it in Simpsons Bowling (trackball) and Pole Position 1/2 (spinner). I'm sure it's a problem with other games too but haven't found any additional ones yet. What's strange is that it's only specific games. I've tried adjusting the sensitivity settings in the MAME config and it doesn't seem to help. Has anyone seen this before?

Thanks and have a happy New Year!

[daywane]

I've tried adjusting the sensitivity settings in the MAME config and it doesn't seem to help. Has anyone seen this before?

Thanks and have a happy New Year!

what version of mame are you using?
what frontend?
when you adjusted settings in mame did you try this game only?
how far did you adjust? small adjustments ar did you try large adjustments.
spy hunter is the only one I have had problems with

[Farb]

I was using MAME 0.124 but also it tried 0.128. I was starting the games directly from the command line to take my frontend out of the equation. I adjusted the settings for Simpsons Bowling and Pole Position individually. I took sensitivity down by half (100% to 50% I believe).

[turnergw]

Sorry to dredge up an old topic, but I'm having very similar problems as the original poster here, and was wondering whether anyone ever got to the bottom of this.  I'm using MAME 0.130, with a minipac connected with an ultimarc U-Trak and Spintrak.  They both work perfectly in Windows, and some games work fine (no problems in tempest, tron, marble madness) but others have this 'queueing problem'.  Worst offenders seem to be arkanoid and cameltry - they both work fine for 20 to 30 seconds, then suddenly hit the slowdown issue seen in the above posts.  I've tried all sorts of ranges of settings in MAME, but can't seem to get rid of the problem.  Also tried in mame 0.129 to see if it was a specific version, but this had the same problem.

I don't really understand why the problem only occurs on some games - it's as if the polling rate is too low and the inputs are producing a large stream of analog positional data that's filling up a buffer (although I haven't delved into the MAME code at all).

It happens with both versions I've tried, running direct from the command line, or from a front end (hyperspin)

Has anyone else seen (and hopefully solved!) this kind of problem?

[turnergw]

Just in case anyone else does run into this, it seems to be caused by the vsync in MAME - Switching off triple buffer and vsync makes the problem go away.  Having either of these options switched on seems to cause the "input-queueing" effect.  Hence, I presume MAME isn't polling the analog inputs whilst waiting for the video sync.

It may be caused by the input rate of the devices I'm using - using http://www.softpedia.com/get/System/System-Miscellaneous/Mouse-Rate-Checker.shtml indicates that my mouse is polling at 125hz, whilst the spinner and trackball connected via the Minipac are polling at 250hz.  I wonder whether the increased rate is causing the problem - I've tried resetting the rate using various tools, but for some reason this only seems to disable the minipac completely.

Anyway hope this helps someone - At least the trackball and spinner games are playable now - unfortunately they're left with the screen tearing caused by not being able to vsync on   

[cnsf]

HELP!!!!

I am having the same problem - very evident in Centipede and Millipede.  I have Hyperspin, MAMEUIFX 0.134, Core2Duo, 4gb RAM, GIGABYTE GA-G41M-ES2L LGA 775 Intel G41 Micro ATX Intel Motherboard, EVGA GeForce 8600 GTS SSC Edition 256MB 128-bit GDDR3 PCIe x16, SVideo to TV, IPAC, OptiPAC - both running over USB, 4095k swap file, Windows XP SP3.

The game starts great, then after about 2-3 levels, the trackball starts to lose responsiveness, the shooter starts to bounce all over the screen, then I lose responsiveness altogether.  If I pause the game, wait a little, then play again, it's fine.  Very weird.  Seems like some sort of buffer issue.

Things I've tried to fix it that haven't worked:
Upgrade XP Pro to SP3
Change trackball from serial to USB (via OptiPAC removing power connector from IPAC)
Cranked down any accelerated BIOS settings
increased virtual memory swap file and made it fixed/custom at 4095.
Tried official MAME 0.134 build outside of Hyperspin
Tried MAMEUIFX 0.134 build outside of Hyperspin
Turned off joystick in mame.ini (I don't use one anyway)
Turned off artwork, bezels, etc.

I didn't have this problem in 0.90 or 0.128 - my last two cab builds of MAME.  I have not yet tried an old backup version of these to see if they work now.

I'd be happy to post my mame.ini if that would help.

[cnsf]

I also enabled triple buffering (it happened when it was disabled).  I will check vsync when I get back tonight.

[u_rebelscum]

Did (disabling) vsync fix it?  If not there might be a couple possible causes, but I don't know of fixs, so I'll just sumerize.

Centiped and milliped polled their TBs something like 240Hz, and mame has had, in the past, problems reading the inputs and seending it to the right places "in sync".  Centiped especially, this would lead to a very slow feeling.

This has been fixed recently, AFAIK by buffering inputs and doling it out equally to the multiple game polls until mame's next poll.  Maybe this buffering is getting out of sync or something.  I can see how mame's vsync or "triple buffering"* could mess with the timing, but that's without verifying in the source.

*The "triplebuffering" mame uses is not true triple buffering.  DirectX does not have a built in way to true triple buffer, but a fake substitute being called that, but really is "render ahead buffering", which mame uses.  Render ahead is like vsync in that once it's render-ahead buffer is full, it stops and waits (for vsync) for a space to open in the buffer.  If mame is able to render ahead just slightly faster than the game expects, the buffer will fill up "slowly", and once full, mame will act like vsync is on.  Which why both vsync and triplebuffering should be disabled if you're having this problem.

[cnsf]

It did!!! 

I had triplebuffer and waitsync enabled in mame.ini.  I turned off both and the buffer problem went away.  SO, I decided to find out the real cause. 

I enabled triplebuffer (which enables waitsync anyway) and the problem came back.  I then disabled triplebuffer and enabled waitsync.  The problem also came back.  Disabled waitsync and it's now fine.

The source of the problem is waitsync.

Now, I get some screen tearing in more demanding graphics games like Mortal Kombat - guess I'll have to live with that.

The problem was "not" related to Hypersin in any way or the IPAC or OptiPAC.  All are great products.

btw - Andy from Ultimarc helped me investigate this issue - he is awesome with support, even when it is not related to his product.  We all should buy from Ultimarc to make sure the business not only survives, but grows...

[u_rebelscum]

Glad you got it sorted out. 

Now, I get some screen tearing in more demanding graphics games like Mortal Kombat - guess I'll have to live with that.

FWIW, you are getting a lot of tearing in MK because MK refreshes at 54.8 Hz, quite a bit off from the 60 Hz you're probably running at.  The games you're not getting as much tear probably run at or close to 60 Hz (pacman: 60.60606 Hz, zaxxon: 59.999408 Hz).  These games will get a small "walking" tear moving up or down the screen.

[cnsf]

That is indeed what's happening.  But the response time on the controls is more important.  A lot of games have some level of tearing, but not enough to impact gameplay.

[u_rebelscum]

... But the response time on the controls is more important.

I totally agree.  (Others might say differently.)