Optical Control Resolution - Info Needed

[Derrick Renaud]

I want to start keeping track of the resolution of the actual controls used for games.  This will (hopefully) be included in MAME.  This info will help to better document the controls, and possibly lead to auto-sensitivity adjustment based on the control used for MAME.

I need factual info of the number of optical counts for a full turn of the control.  Usually 360 degrees.  If it is less, eg 270, then I need to know that also.  No guesses please.

For example,
Tempest, 360 Spinner, 72 count

To show how the auto setting would work, if you tell MAME the control you use has 1200 counts per turn, MAME will do:
Sensitivity = 100 * 72 / 1200 = 6%

This will now make your control turn the exact amount of the original control.  I do not care about knob size or anything.  It does not effect the number of counts per turn.  It just makes it feel different in your hand.

thanks,
D.

[u_rebelscum]

Reminder to all posters, Derrick wants the count per full turn, which can 1x, 2x, or 4x the number of teeth per full turn.

The one I know OTTOMH is 720 degrees (not that this info is needed for the current faked inputs):

720 (skate or die), 360 spinner "joystick", 144 count (72 teeth)


And there was that post a little back about arkanoid and arkanoid 2 (revenge of doh) using the same hardware, but the second having twice the count as the first.

[crashwg]

I'm not sure I follow exactly what you're doing math for...

I just counted the teeth on my D.O.T. spinner though and there are 128! 

[Kremmit]

I can't get you the actual count per revolution that Robin is talking about, as that requires knowing what the game logic does with the simple optic count from the controller, but I can get you some accurate encoder wheel tooth counts.  I'll leave the game logic end to the MAMEDev types.   

From an old post of mine:  (http://forum.arcadecontrols.com/index.php?topic=50641.msg494624#msg494624) 

-------------------------

I've played around with lots of different encoder wheels, with different tooth counts.  Just for reference, here are the ones I actually saved the numbers for:

DOT spinner (original) has 128 teeth.
The Oscar DOT has 72, same as Blasteroids, Tempest, Oscar Vortex, and the 720 joystick.
The Pole Position wheel has 24 teeth, with the gearing you get just shy of 4 revolutions of the encoder per turn of the wheel, for somewhere around 80 teeth actually passing through the optics per one turn of the steering wheel.

Arkanoid is the special one.  The knob attaches to shaft #1, which has a 72 tooth gear on it.  That gear turns a 16 tooth gear on shaft #2.  Shaft #2 also has a 72 tooth gear on it, which then turns a 16 tooth gear on shaft #3.  Shaft #3 also has the encoder wheel on it, which has 24 teeth.

So, shaft 2 spins 4.5 times for every turn of shaft 1.  Shaft 3 spins 4.5 turns for every turn of shaft 2.  4.5 squared is 20.25 turns of the encoder for every turn of the knob, which is 486 teeth per revolution of the spinner knob!!

------------------------

Off the top of my head, I know that the Roadblasters wheel uses the same 24 teeth as the Pole wheel, but I don't know how many actually pass the optics with a full left/right turn, since it's a limited wheel.  Major Havoc roller uses the same 24 tooth wheel again, but with the big green roller turning the smaller metal roller that spins the encoder wheel, you'd need exact diameters of those parts to calculate the turn ratio.  Happ and Betson trackballs also use a 24-tooth wheel on each axis, but the same ball-to-roller turn ratio comes up again.   The Forgotten Worlds spinner looks identical to the Arkanoid one, but I haven't counted the teeth to verify. 

Sometime after Christmas I'll dig through the parts closet and get you the exact gearing on the Pole wheel, see how many of those others I can clear up, and get counts for few other goodies.

[Derrick Renaud]

Reminder to all posters, Derrick wants the count per full turn, which can 1x, 2x, or 4x the number of teeth per full turn.

Robin is right, I do need to know this.  But the easiest way if you can not precisely do that is:

Count the actual teeth that pass in 1 full turn.  Just tell me if that is full 360 or if that is a limited steering wheel type.  Then just tell me the degrees that the control can turn.

Also tell me how far the player moves across the screen in 1 full turn.  This may not apply for racing games.  It is for arkanoid type games where the player moves a set amount per turn.  Or for a cameltry type game, how many rotations on screen per 1 rotation of the control.  From that I can guess if the control reads 1x, 2x, 4x.

Thanks,
D.

[Derrick Renaud]

I (snip) get you (snip) goodies.

Thanks.

This is exactly the info I need.

So for Arkanoid with a count of 486 while using a spinner of 1200 resolution you get this sensitivity.

100 * 486 / 1200 = 40.5
so:
Analog Sensitivity = 41%

And that does work just like I remember arkanoid.

[Dream mode on]
Now if the spinners could be programmed with a drag value, so you could automatically go from a free spinning Tempest spinner to a slow/damped moving arkanoid spinner.  Sounds like a job for programable magnetic damping. 

D.

[Derrick Renaud]

I'm not sure I follow exactly what you're doing math for...

To automagically set your control to work like the original control, of course.

Lets say you have a spinner with resolution C.  Where C is 4x the tooth count of your spinner.

You also need to know the resolution of the original control used on the game.  Let's call that G.

To set the analog sensitivity, all you need to do is enter this value:
100 * G / C

 

So in practice, let say you have a Happ's optical rotary joystick.  It has 24 teeth, connected to a 4x mouse giving a count of 96.  Ikari controls had a full turn count of 12.  So:
100 * 12 / 96 = 12.5

So setting the Analog Sensitivity to 13 in Ikari, makes the Happ's control work similar to the original LS-30 SNK control.



D.

[Derrick Renaud]

The one I know OTTOMH is 720 degrees (not that this info is needed for the current faked inputs):

Hey, hey, hey... Slow down, you never know what may happen. 

720 (skate or die), 360 spinner "joystick", 144 count (72 teeth)

And the other input is once per 360?

OT, but, it does amaze me that the old games had already figured out 2x quadrature encoding.  And how long did it take mice?

D.

[Xiaou2]

 Derrick,

  How does one "Auto Sence" such a thing?

  If you do some sort of readings in game..  it could fluxuate.. thus changing the
values on the fly, and messing up gameplay as your sensativity rises and falls. 

 I think if anything, there would be a special program included with mame
that you run first to determine your encoders resolution... then it makes
an INI file for it or something.

 Also, there are encoders now that can be adjusted in sensativity.  Such as
my logitec laser mouse.

 
 Some other things to consider.. 

 RandyT made the comment about  'Knob Diameter"  effecting how many turns
per degree.

 Simularly, all Shaft Diameters also count too.

  I also wonder how accurate the translated polling times for mame are for each
driver.  For example.. if in marble madness, you have have perfect controller
match and the same encoder resolution.. but mame polls slower than the arcade
did.. then your marble will never be capable of moveing as fast.. or at least cant
accelerate as fast..ect.   Polling too much, I think, can give the player too great
of control, thus giving them an advantage.

 Ohh, and then we are talking windows too..   as I believe that different windows
versions have different polling times..err, checks per time unit.

[Derrick Renaud]

  How does one "Auto Sence" such a thing?

  If you do some sort of readings in game..  it could fluxuate.. thus changing the
values on the fly, and messing up gameplay as your sensativity rises and falls. 

You have to tell it the fixed rate your control works at.  Then MAME would do the math as I have already shown.

I think if anything, there would be a special program included with mame
that you run first to determine your encoders resolution... then it makes
an INI file for it or something.

Too complicated, and inaccurate.  It is up to you to find the real resolution of the device you are using.

Also, there are encoders now that can be adjusted in sensativity.  Such as
my logitec laser mouse.

Again, MAME can't work magic.  Your controls should use a fixed resolution with no acceleration, etc.  That is all useless as far as emulation goes.  You want to feed the game info similar to what it got on the real machine.

Also, this is not really meant for mice.  It is meant to make spinners, wheels, etc work like the real control.

RandyT made the comment about  'Knob Diameter"  effecting how many turns
per degree.

 Simularly, all Shaft Diameters also count too.

Um, as it stated in my first post, this has no bearing on anything as far as MAME goes.  If you take a real Arkanoid game, remove the knob and somehow fit it with a big steering wheel, the game play will "feel" different.  But the resolution is still the same.

So it all depends on how you use the control.  If you grasp a knob and just turn it, the knob size makes little difference.  But if you are rubbing the edge of the knob to turn it, then yes, the resolution changes similar to putting the wrong size tires on your car and finding the speedo is now wrong.

I'm not sure if I could convince the rest of the team that we need to keep track of "Knob Diameter."   

I guess it would not hurt to give me the knob/wheel diameter details and I will comment it in the code until we use it.  But, I imagine there may be different sized knobs/wheels depending on if the game is original or a conversion.

  I also wonder how accurate the translated polling times for mame are for each
driver.  For example.. if in marble madness, you have have perfect controller
match and the same encoder resolution.. but mame polls slower than the arcade
did.. then your marble will never be capable of moveing as fast.. or at least cant
accelerate as fast..ect.   Polling too much, I think, can give the player too great
of control, thus giving them an advantage.

 Ohh, and then we are talking windows too..   as I believe that different windows
versions have different polling times..err, checks per time unit.

NOTE: the following info really should be placed in an FAQ somewhere so I don't ever have to type it in again. 

Polling is a different beast.  It has no real affect on the above, but it is very important.  It affects the ability of the emulated control to match the real control, which would be perceived as smoothness.  There are 2 different polling things in emulation to be aware of.  One is the polling rate of the original game.  Usually done during v-blank.  And the other is the OS's polling rate.

The original game knows nothing about your OS, so it is up to MAME to get the info and feed it to the game when the game asks for it.

So lets say the game polls once each field for a polling rate of 60 times a second.  Now lets say you are using a serial mouse with a polling rate of 40Hz.  That means in every second of polling, 20 samples are missed because the serial mouse can't keep up.  The moral here is... Throw Your Serial Mice Away!

PS/2 mice are the bare minimum you should use.  You should also set the PS/2 sampling to 200Hz in the XP control panel, or by using a utility program such as:
http://www.majorgeeks.com/PS2Rate_Plus_d300.html

Even if you do not use a PS/2 mouse, you NEED this program because it will tell you the polling rate of your mouse.

Now the first thing you find on XP, is that your PS/2 200Hz polling rate, is limited by XP to 125Hz.  (I've said this many times, but here goes again.  Windows input handling blows!)  So you need to also do the USB fix below.

USB mice are the best if you have XP, even though windows limits the polling rate to 125Hz.  That is because you can use this nifty utility to up that rate:
http://www.majorgeeks.com/USB_Mouserate_Switcher_d4469.html

Set a rate of 250 or 500.  1000 is overkill.

One thing I did not mention is why we want an OS sample rate much higher then the original game.  This is so the values can get smoothed out to better simulate what the original control used.  If the original game used 60 and the OS uses 100, then during 40 of the games polls it uses the combined reading of 2 OS polls of the control.  For the other 20 game polls, it uses only 1 OS poll of the control.

For the same 60Hz game, lets say we now use 500Hz OS polling.  So now during 20 of the game polls, the OS supplies 9 polls.  For the other 40 game polls, the OS supplies 8.  From that you can see that the higher the OS poll rate, the closer the OS polling will match the original games polling.

This is also the same reasoning for wanting a high resolution control.  That way it can be scaled down to match the original control.  A lower resolution control can not easily match all games.  It will have a jerky reaction to it because it can not smoothly be scaled to match the original game.

Wow, I need a beer after all that rambling. 

D.

[u_rebelscum]

The Pole Position wheel has 24 teeth, with the gearing you get just shy of 4 revolutions of the encoder per turn of the wheel, for somewhere around 80 teeth actually passing through the optics per one turn of the steering wheel.
...
Sometime after Christmas I'll dig through the parts closet and get you the exact gearing on the Pole wheel, see how many of those others I can clear up, and get counts for few other goodies.

I was looking for something else, but found my pole position wheel.  I'll post the info I got so you don't feel you need to hurry (but would be great for some to verify my info):

60 tooth gear on wheel shaft, 14 tooth gear on 24 tooth encoder disk shaft ==>
(60 / 14) * 24 = 102 6/7 encoder teeth per wheel rotation.

Pole Position: 360 steering wheel: 102 6/7 teeth (guessing with 1x count due to date)

The one I know OTTOMH is 720 degrees (not that this info is needed for the current faked inputs):

Hey, hey, hey... Slow down, you never know what may happen. 

What, who me?  No, I didn't make any hints at changing any game's inputs.

720 (skate or die), 360 spinner "joystick", 144 count (72 teeth)

And the other input is once per 360?

This was the hardware I was looking for I mentioned earlier, so I could measure the spacing of the gap between the sensors.  Didn't find it (yet), but IIRC the sizes, the signal is four per rotation assuming it's 2x like the other axis, or twice if it's 1x, but it might not even be standard grey code counts.

edit: found it, and I was wrong.  See my next post.

Here's my logic:  The normal encoder wheel has 72 teeth, and is over 4" in diameter.  Each tooth and each gap are 2.5 degrees wide (which is ~0.174519" or ~11/64" wide).  The index disc has two gaps, spaced exactly over two teeth on the normal encoder disc, but the two teeth are non-consecutive.  IOW, the index gaps edges are spaced ~ 3 * 2.5 degrees apart, and their centers are spaced ~ 4 * 2.5, or ~10 degrees.  I'm guessing the sensors are spaced so that both sensors see the two gaps at about the same time.  The output of the two sensors as the two gaps pass the two sensors would be

00, 10, 00, 10, 11, 01, 00, 01, 00
or
00, 10, 00, 01, 11, 10, 00, 01, 00

depending on the exact spacing of the sensors.

How the PCB interperts the above I don't know.  The easiest is count only when both are "on", which is once per rev and not a grey code decode, but it could more complicated with normal grey code counts.[/color] 

FWIW, besides the initial time when the index "centers" the player up, each index count in mame covers one missed count in normal encoder wheel ("recenters toward straight up"), based on my notes from testing in analog+.  I'll see if I can find the hardware and do some more testing "soon".

OT, but, it does amaze me that the old games had already figured out 2x quadrature encoding.  And how long did it take mice?

AFAIK, arcades were late in the mix, and PC mice were 4x from at least the mac (1984).  I don't have any supporting evidence I can link, though. 

NOTE: the following info really should be placed in an FAQ somewhere so I don't ever have to type it in again. 

Polling is ...

Thanks, Derrick!   That sums up all the peices I "knew", but lines them all up so I understand them better.

[u_rebelscum]

720 (skate or die), 360 spinner "joystick", 144 count (72 teeth)

And the other input is once per 360?

I think it's 2 or 4 per rotation, but all counts close to each other:

The two gaps are spaced farther apart than the two index sensors.  This cuases the sensors to send (assuming 0 is blocked and 1 is unblocked sensor):

... 00, 10, 00, 01, 00, 10, 00, 01, 00 ...

See attachments of a drawing close to 2:1 scale, vertical pink lines are the sensors.  Compare with the normal quadrature 00, 01, 11, 10, 00 (also see attachments).

The index "tooth" between the gaps is a little under 7.5 degrees wide, and the gaps are a little wider than 2.5 degrees.  If we called when the "tooth" is centered to the sensors as 0 degrees, and assumed that the gaps were eactly 2.5 and the tooth was exactly 7.5, and that the sensors are exactly (2 * 2.5) + (2.5 / 2) degrees apart (a "perfect" spacing for 72 teeth encoder), then:

degrees	sensor output
-180* - -9.375	00
-9.375 - -6.875	10
-6.875 - -3.125	00
-3.125 - -0.625	01
-0.625 - 0.625	00
0.625 - 3.125	10
3.125 - 6.875	00
6.875 - 9.375	01
9.375 - 180*	00