New Product (In Stock/Shipping) - Apache Controls Blackhawk Push/Pull Spinner

[2600]

I doubt Arkanoid is using anything more then 1x on it's 486 tooth count.

I don't have the exact numbers in front of me, but I believe there were about 176 possible positions for the paddle.  This would mean, with 1x on an original Arkanoid spinner, one would need to turn the knob roughly 132 degrees to move the paddle from one side of the screen to the other.  I seem to recall that particular game having much finer control, meaning a shorter range of movement (~65 degrees?)  which would put it 2x.  If someone listening has an original, please measure this for us

You may be right.  I should of said I doubt they are using 4x.   I was really trying to put the DOT information down for archive, the arkanoid comment was pure speculation.  I haven't found a schematic for that board anywhere and haven't tested it.

I smell an entry for the wiki or maybe a seperate thread with the information from Kremmit, u_rebelscum, and any other factual information on games like what RandyT was asking for.

And when engaging in a discussion about resolution and spinner controls, the topic of analog paddle games, which can require even higher resolution than Arkanoid to be playable at a decent level, should probably at least be brushed up against.

Again, you may be right and it probably should, but I think it is hard enough for some to keep on and understand one topic, then three: spinner, geared spinner, and analog.

Also, for everyone else my comments were just meant for listing in some sort of list.  When it's all said and done, I'm more inclined to go Kevin's route and just see if I had fun.



As for Xiaou2,
I usually avoid any thread after you post in it like the plague.  You seem to have enough knowledge to think you know what you are talking about, but like this example you seem to have it @$$ backwards, even after u_rebelscum pointed out your misunderstanding.  Before you blow up, I highly suggest you do a quick google and research this subject before you say anything else.  If I'm wrong in my understanding of how the resolution of encoder wheels and optics work, please someone let me know I'm wrong.  I'll fully admit it as I'm not an expert on the subject.  I definitely don't want to pull a Xiaou2 and spit out the same wrong information out everytime any topic comes up for discussion.

[MameMaster!]

Hey Kev,

How does this compare to the GGG spinner, which seems to be the highest resolution spinner available today?

...actually I did the review on that one (GGG)...and it just so happens that I just bought the Apache DOT spinner as well (OK, I'm almost as odd as Kevin as now I own 4 spinner (including 2 Oscar Control ones).

I literally just opened the package on this thing....and I have to say as Kevin did...this thing is really well built and heavy. Everything screams quality.

I haven't tried it yet, but I have a feeling that my findings would be similar to Kevin's.

That being said the GGG spinner and this one are two different products with a big price difference for the push/pull function.

I am totally thrilled with the GGG spinner and I have a feeling I will be as well with this one...but again, I see them as having made 2 very separate purchases as personally I've made my "modules" with custom controls as I like to get to the original control schemes as closely as possible for games.

Bottom line....it all comes down to $$....just like life. There's a lot to like about both of these spinners if you're just comparing the 2.

As a matter of fact.....I picked this up for module 10....the DOT Module! 

[1UP]

I will say one thing about Xiaou2--he has the amazing ability to review ANY product without ever putting down the $$$ to try it out.  I wish I had that ability.  I could save a lot on testing.   

And now while I wait for the backlash of my comments to follow...

I am going to try this product, then formulate my own opinions.  I really dont' care how it works, as long as it works well!  I have been waiting for someone to make a new up/down design, and now it is here.  Thanks for putting up the money and effort it takes to bring a new product to market, many here may not realize what that really means.  Any new product runs the risk of not even selling, and it takes a certain amount of guts for a small business or individual to go ahead and make a product you believe in.  I hope you will be well rewarded.   

[Kremmit]

You just dont get it...   

Mame is most likely set up in such a way as to REDUCE counts...

...

...This isnt opinion, its Fact.

It seems your "facts" are predicated on what you consider to be "most likely". 

You understand how controllers work, I know you do.  But when it comes to how Windows and MAME handle mouse input data, I'm sticking with U_Rebel.

[Xiaou2]

Kremmit,

 You are quoting two differnt parts of my post and putting them together into something
else. 

 ALSO..  as far as Urebel  goes..  I do not see ANYWHERE where he mentions how mame
handles each game at both a driver level, and internally elsewhere in mame.  Do you???
------------
" The original controller had a 72 tooth encoder, and the game saw 144 'clicks' per rotation.  (If I hacked a mouse on to the same controller, mame would see 288 'clicks' per rotation due to the increase in technology.)

Basically, there were 1x, 2x and (now) 4x 'clicks' per number of teeth.  So you can't just go by number of teeth.  For comparison, the 48 tooth BlackHawk generates (AFAIK) 192 (4x48) 'clicks' per rotation, while the '720 controller generated 144 (2*72)."


 "So even though it has less teeth than '720, the BlackHawk has a "higher resolution" than the original '720 controller"
-------------

 That statement would be true Only IF mame didnt mess with the values being sent to it.  Only if mame didnt choose to ignore, pole less frequently, or subtract data..etc.   So untill you get those facts -  all of this above prooves nothing.

 And trust me, I do respect  Urebel.

 
 1up,  you dont want backlash.. yet you post in a way that deserves it. 
When did I say I was REVIEWING this product?   I was offering suggestions
for improovments.     

 As for knowing how something may react,  thats from
knowledge and years as a repairguy and manager at an arcade.. as well
as from failed attempets from building my own controllers and other devices.
There is a true "Logic"  behind what I say.   Logic that is deteremined by
true mechanical properties.   

MameMaster,  I believe you may have a better ability to accuratly review
the differences between the two spinners.   Unlike other Review sites,
maybe you wont kiss --I'm attempting to get by the auto-censor and should be beaten after I re-read the rules-- and say they are both swell.  Instead, actually
having the Brass to say there are differences and what those differences
are. 

Try heading over to any other review sight and seeing how much more
critical they are.. and to the depths of comparison they go to...


 Its very LOGICAL that Randys higher resoltion encoder will give much more
control than that of the Appache.  Hard to believe anyone doubts that at all.

 But, Apache does have the  Up/Down  function..  which is great for the few
games which require it.   So most many may choose to buy both spinners,
such as MameMaster has.   
 

 I, like many, am a customer.  If I see something I like I buy it.  If not,
I dont.  I may request it.   But if its not made, I will just go and build it
myself.  Or buy an origianal arcade part.

 If people dont like that Im honest and direct.. that I dont Kiss --I'm attempting to get by the auto-censor and should be beaten after I re-read the rules--..
then thats just too bad for them.

[1UP]

I was sincere when I said I wished I could tell how good a controller was without buying it.  I have so many piles of unused controllers laying around, I don't know what to do with them.  Actually, most of them are cool, I just don't have room for enough machines to put them in!

I don't think that you can claim to know everything about optical controllers, and to say that it is impossible to get a desireable amount of control out of a specific resolution encoder may be uninformed.  Do you know exactly what optics and electronics are being used?  Is it possible to monitor not only the distinct pulses of light in order to determine speed and direction, but also to read the actual brightness of the light received at any moment, so as to extrapolate more precise information about the state of the encoder?  I thnk Apache could answer these questions most accurately, but may be reluctant to do so in order to protect trade secrets.

In the end, it really doesn't matter what methods they use, if they actually give good results--I'm sure this will be reflected in their sales numbers.  If it has been said that this controller has produced the "best game of Tempest ever" then I would take it to mean that the controller was more responsive/less prone to backspin than previous controls.  Unless you assume they are lying, in which case, the review would be meaningless.  I'm not sure why you say that Retroblast is "kissing --I'm attempting to get by the auto-censor and should be beaten after I re-read the rules--", otherwise, every review would state that every product is fine and dandy.  They always give the pros and cons, and while their opinions may be different than yours, they are entitled to them, and obviously many people find their opinions useful in choosing their controls.

The only way to know for sure is to try the spinner yourself.  If you are not currently in the market for a spinner, maybe you should give this one a pass.  Otherwise, all you can do is either try it yourself, or wait until enough other people have tried it and posted their reviews, so that you can be assured that not everyone is in Apache's hip pocket.

[Xiaou2]

"I don't know what to do with them. "  hmm, send them here, Ill take em off your hands 

 
 "I don't think that you can claim to know everything about optical controllers" 
Never claimed that.

"Do you know exactly what optics and electronics are being used?"
Dont want to drag him into it, but Randy believes he does know what the encoder is.

"but also to read the actual brightness of the light received at any moment"

I believe thats a no.  The type of optics you are mentioning would be a laser
reading device..  and that wouldnt need any holes at all.. in fact, holes would 
create a problem.    The  older Infered mice type optics are simular in that
way,  and are not very accurate in thier reads for such an application.

 Laser is relatively new for mice actually.  I believe only Logitec has
used this so far, and  its expensive in that mouse.  Not sure if
its as expensive in standalone hardware..  and also not sure how
far away from an object the laser can accurately  read.   Which 
in the case of an up/down spinner.. could cause some major
problems for accurate reads when it changes focus..

"impossible to get a desireable amount of control out of a specific resolution encoder "

 Not so.   If one uses a high res encoder,  they can also use electronics and
or software to reduce the resolution for games that do not require it.

 However, theres no way to ADD resoliton to a very lo resoltion encoder.
The only thing you can do is multiply the values read.. which results in
choppy 'steps'.  Which is not really accurate smooth control.

"less prone to backspin than previous controls"
Is NOT indicative of better control.   Backspin is usually caused by an
encoder that is TOO sensative for the game being played.

 Or, it can be caused from an encoder that is 'mis-aligned'.. such as
a slight wobble..  or poorly cut teeth.   Whereas the  optic gets
confused by the readings and reverses the direction.

 It might also be caused by the actual optic not being capable of
reading pulses fast enough... thus again, it misses a tooth and
thinks directions have changed.

 Anyone with better knowledge of this, feel free to correct me.

 I have some experience with backspin problems when I made
my own encoders for my first versions of a dual skateboard bearing
spinner.   It used a clear encoder that was laser printed.  This was
even before oscars products.   The things teeth had to be ecactly
perfect in spacing and direction.. and misalignments of the
position of the optics would cause the reverse.  As well as if
the encoder wasnt  centered and wobbled.
 
 Too fine a tooth.. same thing.   Too wide a tooth spacing can
also cause it.  Its a very precise thing.. and was very tricky to
pull off.   Eventually I realized that it wasnt a good idea to
use hand printed encoders.. and just find a machined encoder
instead.
 
"best game of Tempest ever"
Such a claim doesnt mean much.. as there is no real comparison here.
Maybe he just finally got better at that game.  Maybe he was having a
stroke of luck.   Was that only one game?  Or did he play 10 games in
a row?

 Did he directly compare 10 games in a row with the Apache.. to 10 games
in a row with the GGG spinner?   

 Did he alternate between the two spinners to see if he could spot any
control accuracy differences?

 As for the rest..  Im also entitled to my opinions.  If people dont like
them, they dont have to read them      heheh

 I merely pointed out that the Apache would benefit from a higher
res encoder and hardware or software reduction for lower res
games..   as well as the addition of Roller switches for longer lifespan.

 I think that people take these comments as threats.. thinking that the
company will cease production because of them.   This is not the case.
If anything, a company is cappable and may often make revisions to
a product.  (esp if theres demand, and or hard competiton.. In which
case, they would NEED to adjust to keep customers)   OR, they will
just keep on going with buisness as usual.  A comment isnt going to
stop a company because their feelings are hurt.

 And while Im not yet at that point where I NEED the spinners for my
new cabinet.. I am closer to that goal, and have been aquireing more
parts. 

 I was / am..  considering a purchase for this spinner as well
as the GGG spinner..   But would rather the Appache had higher tooth
count.    Else, I can just use the original DOT spinner.   The original
however.. is a bit poor with friiction..  and is slow and hard to move.
(due to its monster e-clip design which creates too much friction)
This is why this new spinner is a possible better alternative to the
real thing.

 If all else fails, I may choose to build my own from a new design.  Only
time will tell.

 

[Timoe]

There should be a word limit on posts.  ^  who's gonna read all that nonsense?

 

[RandyT]

Is it possible to monitor not only the distinct pulses of light in order to determine speed and direction, but also to read the actual brightness of the light received at any moment, so as to extrapolate more precise information about the state of the encoder?

No.  WYSIWYG.  As urebel stated, 4x is the maximum and is done in firmware.  There is no magic hardware, at least none in the standard quadrature encoder setup (disc with holes in it and 2 sensors), that will accomplish what you are talking about.

Backspin and Tempest in particular;

Tempest, as implemented by MAME, has very low requirements from a spinner.  The original used, I believe,  a 72 aperture encoder wheel, but appears to have been used at only 1x.  In other words, one movement for every hi > low or low > hi transition, but not both.  So assuming this is true, a modern spinner would need only 18 (!!!) apertures to be accurate, due to the 4x decoding scheme.  Higher resolution spinners than the original just throw way too much data at the game and it gets confused, causing backspin  Since no spinner would (or should) have only 18 apertures, an adjustment to lower the sensitivity for that title is almost always in order.

There are other causes for backspin, but this is the situation with Tempest.  Other games will behave very differently.

It should also be noted that, as Xiaou2 was saying, just because the original control behaved a certain way with the original hardware, that does not automatically mean the drivers in MAME have been written to behave exactly the same way.  If one were to asume that a PC mouse were to be used to play the game, it is entirely possible that too much data would be sent to the game even at the lowest sensitivity levels.  This would cause all kinds of problems and make the game unplayable.  So the only thing that can be done is to have the driver scale the incoming data accordingly.     

Any thoughts on this, Robin?

RandyT

*edit* Incorrect supposition about Tempest as handled by MAME removed

[1UP]

Thanks for the clarification Randy.  Could you explain briefly how 4 "clicks" are able to be captured with the same 2 sensor setup?  It seems it must be looking at something other than distinct on/off pulses if it is able to get 4 times as much info out of a single click.

I guess then, the best test of what level of control a spinner is getting: how far do you have to turn the dial before your "guy" moves one pixel?  Does it skip pixels?  Do you get backspin at high revs?

Really, nothing else matters, other than, can you get the same level of control with a given spinner as you get on the original game?  Or if you don't have the original game to compare with, do you feel that you are fully in control of your postion on the screen at all times?  Is the response fast enough (for you), without requiring extreme revolutions on the spinner?  This all comes down to experiencing it for yourself, whether the encoder is 72 teeth or 144 or 288, whether the hardware is 1x or 4x.  Hopefully we can get some more specific reviews/comparisions.  I personally will be happy to report my experiences when I get one of these to try.

I am also interested whether any of the other folks (Randy? Christian?) are still persuing an up/down design.  I would definitely like to see an up/down spinner with a smaller footprint, if possible.    The more options the better.

[Xiaou2]

Randy,  Thanks for the help 

 1up,

  An interesing idea here...

 If tempest had 10 distinct walls on a tround tube..   the game designers
could have made a spinner encoder with only 10 teeth.  Each click equal
to one movement to a new wall.

 However, that would make it a bit too sensative, and may be hard to
keep your guy on a single wall without it accidentally jumping because
your spinner turned a hair too much.

 So..  the designers would instead create a form of  'dead zones'.    THe
encoder may now have 50 teeth instead.   The game will read each tooth,
but wont actually move the character untill it reads the 5th tooth.   So
4 out of every 5 teeth will not result in an onscreen character movment.

 Still, the game IS reading those positions.  They again act as a 'dead-zone'
to add a bit less sensativty to a game..  which actually gives that person
more control.


 Other games are much different..  such as DOT.  In DOT, it may be that every
click movies the crosshair an actual pixel in distance.   As there are a lot more
than 10 positions...


 So as you can see,  there are so many factors at play.   Its not just hardware, optics,
mame, mames individual drivers, windows.. but also the actual games programming..  that all add up to how a game responds via input.
     

[u_rebelscum]

WARNING, long post, too much information!!!   Skip to the middle if you don't care about mame vs teeth arguement.

Gahh, I try to research my data, and I'm too slow to keep up!  RandyT touched some of what I mention here (I started this post last night).  Late or not, complete or not, here goes:

ALSO..  as far as Urebel  goes..  I do not see ANYWHERE where he mentions how mame
handles each game at both a driver level, and internally elsewhere in mame.  Do you???
------------
" The original controller had a 72 tooth encoder, and the game saw 144 'clicks' per rotation.  (If I hacked a mouse on to the same controller, mame would see 288 'clicks' per rotation due to the increase in technology.)

Basically, there were 1x, 2x and (now) 4x 'clicks' per number of teeth.  So you can't just go by number of teeth.  For comparison, the 48 tooth BlackHawk generates (AFAIK) 192 (4x48) 'clicks' per rotation, while the '720 controller generated 144 (2*72)."


 "So even though it has less teeth than '720, the BlackHawk has a "higher resolution" than the original '720 controller"
-------------

 That statement would be true Only IF mame didnt mess with the values being sent to it.  Only if mame didnt choose to ignore, pole less frequently, or subtract data..etc.   So untill you get those facts -  all of this above prooves nothing.

I think you're reading my statements wrong.  Let me slightly rephase them:

If a '720 controller was hacked to a mouse (ipac, ect), it would send the computer 288 'clicks' (MS calls them 'mickeys', and mame is sent the 'mickeys' "raw" through directInput or rawInput).  The original arcade game '720 expected 144 mickeys per rotation.
The BlackHawk has a higher resolution in windows than the '720 controller did hooked to the original arcade machine.

What mame sends the game (any game besides '720, since mame isn't using a dial for '720 anymore) during emulation was not addressed (as you mentioned).  Since the statements are outside or prior to mame, both statements are true regardless if mame "choose to ignore, pole less frequently, or subtract data..etc".  Whether a specific game in mame sees a higher mickey count per revoltion of new hardware than the original game with the original hardware is IMO a few seperate issues:

I like to seperate
A) "raw quadrature mouse data"
B) "mouse data sent from device to computer/PCB" 
C) "mouse data sent from OS to application (ie: mame)"
D) "data sent from mame to emulated game"

as between each stage the sender can manipulate the data before sending it, and looking at only C does not address an issue in D or B, and makes finding the real problem hard.  IMO, these four stages should not be confused.  (If this sounds familiar to some, it's the basically the same as my "there are three different 'mouse's: the device, the directInput/rawInput data, and the pointer (or game character); don't confuse them" rant. ) 
And original arcade machines almost always combined A, B, C & D as the raw quadrature data was usually sent directly to the game's PCB, although there are exceptions (someone mentioned arkanoid cotroller as sending count and direction instead of the normal quadrature, meaning that game has two stages for the data: A & BCD).

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

Clean up points:
When I say 1x, 2x or 4x, I'm just talking about the number derived from one quadrature cycle.  One quadrature cycle occurs by rotating by one tooth distance: example: move 10 degrees on a 36 tooth single axis spinner.  There are four states/transitions inside one quadrature cycle; old hardware triggered on one of the transitions, while new can do all four states.  With one cycle, Tempest would see one mickey, '720 would see 2 mickeys, and a PC would see 4 mickeys.  The mouse is not actually multiplying 1 * 4, but can count all 4 states of the quadrature cycle, while Tempest only triggered on one (for more info on the 1x, 2x & 4x quadrature data, try reading <a href="http://www.gpi-encoders.com/technical_articles.htm" >the first two links on this page</a>).
Many PC mice have two sensors in one container, while the arcade you could see each sensor seperately.  The PC mice save money by being smaller and usually sharing the same light source; arcade devices had one lightsource per light sensor.


So,...
I've been looking at mame source for any indication that the mame core reduces or otherwise modifies the relative analog data (aka "mouse type data") for any problems occuring in C or D (areas I didn't talk about before) and not A or B (areas I did).

The only place mame (core) does any sort of thing like 'reducing' is with the sensitivity setting; however at 100% mame does no scaling at all, and > 100% mame multiples.  With mame putting a max of 255%, you can only apply a 2.5x multipler, while you could divide by 100 at 1%; this is a little lopsided toward reducing, but you can't still can't say mame reduces all mouse data becasue of this...

Mame at one point does divide the relative analog data by 512, but this is not done to the raw data; it was multipled by 512 earlier (at the same time it was applying the "sensitivity" factor).  This multipling by 512 is done to store the data in mame's internal -64k to 64k range varibles at near the same scale as the absolute analog data (aka joysticks), and in prep for the "super sensitive mice" MS says is coming "soon" (more likely is already here, see below*).  Multipling by 512 and then dividing by the same number isn't a reduction.

So on mame's core, I don't see any reduction of all mice data like you mention.


For what mame does on the driver level, that really depends on the game.  First off, most game's default sensitivity for relative inputs is between 25 & 50, and no defaults are over 100%.  Here's some stats I pulled out of the driver:

	Total	Dial	Track
Ave	45	41	49
Median	30	25	30
Total #	541	363	178
% =100%	18%	14%	24%

Note: these were calculated per total number of dials, ect; not per number of games with those inputs like they could have been.  Also, rotary joysticks and hacks like the DOT trackball one were not filtered out.

This puts ~75% of all trackballs and ~85% of all dials being "reduced".  These can all be "not-reduced" by changing the sensitivity to 100%, however.

Next we have to look at each driver and see what it does with the input data, or if there are any errors.  I've looked at a dozen or so, and came up with some, not all, game specific 'reductions':
For example, IMO Major Havoc is passing the spinner data incorrectly; I'm quessing the driver is sending the data offset by 6 to 8 bits (6 bits is closer to what the keydelta hints at, 8 bits is more logical).  Another possiblity is the original did not count in 8-bit binary as the driver is written; for example 0001 could be one 0010 could be two, 0100 could be three, ect, vs the binary 0001, 0010, 0011.  Major Havoc was the one that first hinted to me the next point.
Another possible indication: some (~25%, including Major Havoc) drivers have the sensitivity not matching the keydelta.  For example: sensitivity set to values < 25, but the keydelta > 25.  'Keydelta' is the multiplier used to convert a button (digital) to an analog input, AFAIK on at per frame: a keydelta of 5 equals the mouse sending 5 mickeys per game refresh rate (usually ~60 hz).  The average sensitivity to keydelta ratio is ~ 2.5 (again for relative analog ports).  While variances in this ratio are expected with "fast spinning" games having lower ratios and "slow spinning" games higher ratios, ratios under 1 or over 25 seem a little "out of wack" which, IMO, either hints the emulation isn't perfect or the designer didn't have a mouse to test with :p.
Another example: Marble Madness mounted the trackballs at 45 degrees from the normal X,Y  coordinates.  The driver has to rotate the movement data.  This can cause some resolution differences as the driver is written due to rounding.

What does this mean?  First set the sensitivity to 100% if you're having problems or an original arcade control.  Then you need to look at the driver and the original hardware, and see if mame is wrong, or you're just not as good as you remember.


*(this is the place I was refering to "already here")
It also means that we should look other places than just the number of teeth and mame.  The OS (WindowsXP/9x) is a major factor here.  WinXP assumes the mouse resolution is "400dpi", higher than the original hardware, but lower than the 1000dpi and 1600dpi of "gaming mice".  Add that the windows mouse settings (speed or enhanced) shouldn't effect the data mame gets (my step "C", above) according to MS, but it seems like it does in some computers.  If they are effecting the data what is the closest setting to keep the data as close to not being changed?  Are they different for different drivers or devices?  Also, how does the 400dpi standard (optical) mouse compare to the resolutions of the ball mice, arcade trackballs, and spinners?


I can post the hack I made to mame to output the inputs more completely if someone wants it.  Reading the posts made after I started my post, I touch on some points but might not answer the questions asked later ("How do you get 1 2 or 4 times info out of same data?" specifically). 

[Xiaou2]

 Robin,

 Thanks for the postings.   Tho a bit hard to follow,            they are very informative and interesing

 I have more questions..

 Besides windows, mouse drivers, and or actual mouse hardware possibilities..

 What about how mame itself  Polls for the data?

 A real  arcade machine may have polled at a certain rate.   It could have been at a per
frame basis..  or maybe it was tied into something else. 

 If mame  generically just polls at every Nth milisecond..  it may in fact poll too many times,
or too few times..  thus changing the sensativity, correct..?


 Also,  I believe a few games had some pretty whacky optical situations.  I think DOT spinner
has an analog to digital encoder built onto the optic board.   I think you mentioned this,
(i may be confused)   but It makes you wonder how fast the arcade encoders were at
reading and sending the data... and maybe even changing it within that chip itself. 

 Was there any harware acceleration in some of those machines?  Does mame consider this on a
per game basis? 


 It would seem that the key delta,  while a nice way to change settings of mouse sensativity..
only works on a per frame basis.  Where as the original hardware did it on the fly...

 Shouldnt mame have an  option for setting the exact multiplier for data changes in "realtime"?

 
 Thanks again for your comments
 

 

[1UP]

Randy,  Thanks for the help 

 1up,

  An interesing idea here...

 If tempest had 10 distinct walls on a tround tube..   the game designers
could have made a spinner encoder with only 10 teeth.  Each click equal
to one movement to a new wall.

Tempest actually doesn't work like that.  The claw moves with every little movement of the spinner, actually shifting farther away from one track, until it clicks over to the other.  At the furthest extreme, it actually breaks away from the edge of the track, thus allowing you to shoot one of the red X'es in the adjacent track before it flips over and kills you.  So I don't think there is much of a deadzone in the controls.  I think RandyT is right, Mame must scale the info, rather than just creating dead spaces, I think that would make it unplayable.

[Havok]

So, I think it really boils down to this: you can't compare teeth to teeth with today's more sophisticated, sensitive optics?

[RandyT]

I need to make a retraction based on this post, which I was fortunate enough to dig up.  The wealth of information stored here is amazing if one can manage to find it.  A big thanks to Telengard for this one.

2600:  You da man!  Sorry I doubted your doubts   Based on my calculations on the range of motion for an original Arkanoid spinner being read at 1x and the information contained in the above post, they match almost perfectly.  So I think we can state now rather definitively that; while Arkanoid uses a very high resolution, geared encoder system, it's using it at only 1x, as you guessed.  That means that the number of "mickeys" (where are the Disney IP guys when you need them ) per revolution required to play this game at full resolution are 486 and the range of motion should be somewhere around 130 degrees.  The extra precision seems to just be a side effect of the feel of the gearing system. 

I did learn something interesting from all of this.  There is already a spinner on the market that actually operates above original Arkanoid resolution without a gearing system, which is good to know  .

Robin:  While I still believe it to be possible (maybe even probable) that some of the games are a bit whacked at the driver level and don't show 1:1 correlations to the same types of controls, I withdraw my earlier supposition that Tempest is one of them.  After some more calculations and testing using the info provided by Telengard, it looks like Tempest is indeed doing exactly what it should and my earlier numbers were flawed due to being given bad information on how the original game behaved.

But I have some comments on your 4 types, which are technically accurate, but in practical terms aren't as large a hurdle as one would think.

I like to seperate
A) "raw quadrature mouse data"
B) "mouse data sent from device to computer/PCB" 
C) "mouse data sent from OS to application (ie: mame)"
D) "data sent from mame to emulated game"

A) Confuses me   You stated that the data can be modified between each stage. Certainly the controller can translate the electrical signals how it wishes at the B level (the data derived by the decoding method of choice) so it can be sent to the computer.  How can the data be modified between A and B?
 
B) "mouse data sent from device to computer/PCB" will be based on the internals of the chip on the decoder board.  With most modern "canned" mouse controllers, this will use the 4x decoding scheme on the X and Y.  But you have to watch out for the Z axis.  Some of these controllers offer only 2x on the Z and even sample it at lower rates.

C) From what I have seen, MAME and other applications honor the system mouse settings.  If acceleration and speed are both set to the minimum setting, there should be a nearly 1:1 correlation between a "micky" produced by your spinner and 1 pixel on the desktop.  If your spinner produces 192 "mickeys" per revolution, and your desktop is set to 1280 pixels wide, then it should take about 6.66 full revolutions of the spinner to get across your desktop.  If it does, then the OS is seeing your spinner at 1:1.

D) This is the one to wonder about.  While, based on the code I pawed through, MAME doesn't appear to molest the input from the OS other than to apply sensitivity, apparently anything is possible at the driver level.  Maybe this is mostly a non-issue, but I can understand why it might happen if a game's input code could not be handled appropriately using only MAME's sensitivity control. 

Also, how (and why) does DPI fall into the mix?  It doesn't seem like it should, at least for ball-type (quadrature encoded) devices, as this is more of a mechanical consideration (size of ball, diameter of shaft, etc.)

RandyT

[ahofle]

I need to make a retraction based on this post, which I was fortunate enough to dig up.  The wealth of information stored here is amazing if one can manage to find it.  A big thanks to Telengard for this one.

Wow, thanks for that.  This makes me think, since the mamedevs are so interested in the preservation of the games, that these rough analog 'benchmarks' should be captured somehow in MAME (analog.dat or something) so that an in-game 'calibration' can be done to match the controller to the particular game's analog settings.  Something like 'Turn dial control 360 degrees and then press enter' or something similar.  Of course people using controls like mice wouldn't have much use for it, but that would be fantastic to have your arcade controls work the way they should.  Of course, someone will have to gather all the data from the real machines as Telengard has done.

[Xiaou2]

 An interesting thing about  Crystal Castles..

 I looked up the picture, and indeed, the trackball  is mounted at a 45 degree angle.

  I thought..  Can this really affect gameplay? 
 
 So I took out a Happs trackball  (unconnected)  and tried a few spins...

  Sure enough, at a 45 degree angle the ball travels faster and more fluid
when moving in Diagnal directions.


 Why?

 Its due to the placement of the rollers and the friction that is creates.

 When rolling the ball in such a way that makes Both rollers spin
at the same time..  it causes more friction.   
 
 This means that even when you roll the ball
very hard..  it will slow down very quickly.  Its also harder just to "start"
getting both rollers to roll at the same time. 

 If the ball weighed more,
it might actually be better..  but as it stands,  the ball  sometimes
wants to hop a bit between the rollers, as well the ball  "slipping"  instead
of actually turning the rollers.

but...

 When rolling only "One"  roller..  its smooth as butter!   The  "spin time"
will be very long (as long as yout T.ball is clean and bearings are
lubed properly).     To stop and start is effortless, and theres no
"slipping" at all.   Perfect control, smooth feel, fast and accurate.


 So... I guess I will have to build a  Rotating Trackball Mounting Plate  now

 
 I think someone needs to find a way to make a near frictionless trackball...
Or at least,  much less that whats currently available.



 

[Kremmit]

Some of Telengard's #s may be meaningless, or at least mis-leading. 

On Super Sprint, for examle, the amount of on-screen movement derived from one revolution of the wheel is either a) wheel-speed sensetive; or b) limited by a movement celing.  Try playing a Super Sprint machine by just turning the wheel with smooth, slow turns, and then play it the way I do, by spinning the wheel as hard and fast as you can.  You will be amazed to discover that you can turn the car just as sharply around the corners with about a 3/4 rotation as you can by throwing the wheel into a 10-revolution free spin.  This may be true of other Atari games on the list, such as Pole Position and (original) Sprint.  I know it's also true of Ivan Stewart's Super Off Road. 

In addition, on these games, how many degrees of turn the car does on screen is affected by how fast the car is traveling, and how many "Super Traction" powerups the player has purchased.

What this means, is that the on-screen movement measurement obtained by Telengard may well have been influenced by how fast he turned the wheel, how fast the car was traveling, and powerups purchased.  A definative test for these games needs to have these variables defined and controlled in order to be re-produceable.

(someone mentioned arkanoid cotroller as sending count and direction instead of the normal quadrature, meaning that game has two stages for the data: A & BCD).

Not Arkanoid, unless the spinner hooks up to a separate controller board before hitting the game code.  The original optic board is very plain-jane.  Tron and DOT, on the other hand, have all kind of circuitry and a big controller chip on the optic board, so they might very well be doing some data massage between A & B.  Which brings us to:

...I have some comments on your 4 types, which are technically accurate, but in practical terms aren't as large a hurdle as one would think.

I like to seperate
A) "raw quadrature mouse data"
B) "mouse data sent from device to computer/PCB" 
C) "mouse data sent from OS to application (ie: mame)"
D) "data sent from mame to emulated game"

A) Confuses me   You stated that the data can be modified between each stage. Certainly the controller can translate the electrical signals how it wishes at the B level (the data derived by the decoding method of choice) so it can be sent to the computer.  How can the data be modified between A and B?

A) "Raw Quadrature" is the 4-step light pulse data as read by the optics.  If you've got a plain-jane optic card with nothing more than some optics and a resistor or two, such as a Tempest spinner or standard trackball optic, then there's no room for change between steps A and B.  But if there's an on-board encoder chip such as a mouse chip or the afore-mentioned extra circuitry on the Midway spinners present on the optic board, then it may well be reading the raw data and then modifying it before it passes it downstream to either Windows or the game PCB.

I suspect this is the precicely the case with those Midway spinners, and that's why the original optic cards can't be hooked directly to a mousehack, OptiWiz or OptiPac.  There's nothng unusual about the actual optics on board, as demonstrated by Gl.tter here:  http://gl.tter.org/spinnerhack/.  So it the hang-up must be that the circuitry that Gl.tter bypassed was sending something other than the raw quadrature that we know is present earlier in the circuit.


Wow, this topic really does spawn long posts, doesn't it?

[RandyT]

A) "Raw Quadrature" is the 4-step light pulse data as read by the optics.  If you've got a plain-jane optic card with nothing more than some optics and a resistor or two, such as a Tempest spinner or standard trackball optic, then there's no room for change between steps A and B.

Correct.

But to clarify, that "A" stage data is not alterable.  Consider it mechanical.  Anything that happens beyond those 4 states is, IMHO, relegated to "B".  Therefore, "A" should not even be considered separate, as what happens there is buried behind the circuitry that ultimately sends the data to the computer / game PCB.  The quadrature data can be modified to be anything up to the 4 full states, including half, quarter, etc.  But it always happens at the "B" stage.

RandyT

[u_rebelscum]

A) "Raw Quadrature" is the 4-step light pulse data as read by the optics.  If you've got a plain-jane optic card with nothing more than some optics and a resistor or two, such as a Tempest spinner or standard trackball optic, then there's no room for change between steps A and B.

Correct.

But to clarify, that "A" stage data is not alterable.  Consider it mechanical.  Anything that happens beyond those 4 states is, IMHO, relegated to "B".  Therefore, "A" should not even be considered separate, as what happens there is buried behind the circuitry that ultimately sends the data to the computer / game PCB.  The quadrature data can be modified to be anything up to the 4 full states, including half, quarter, etc.  But it always happens at the "B" stage.

RandyT

Sorry, so late getting back.

IMO, the changes are happening between A & B.  You have the quadrature signal (A), and you have the USB signal (B).  In between, the mouse firmware does the translation and, if any (I have a mouse that can) hardware acceleration or other messing with the data.  As Kermmit, mentioned, most arcade trackballs/spinners don't do anything to the quadrature signal (besides "cleaning" the signal, if any coughHappsRedBoardcough).

To me A, B, C & D are just the data, not what happened to it just before that point.  IOW, B does not include the mouse firmware stuff (it's just the data that is passing from the mouse to the computer). C does not include the OS messing with the data (just the data being passed from the OS to mame), D does not include what mame does to the data (just the data being passed to the game from mame). 
(Should I have seperated my list into seven parts, 4 data steps & 3 possible data processing parts? )


Xiaou2,
I looked at crystal castles code but couldn't find mame rotating the signal, and don't have the rom here at work, err, just here.   Are you saying that all we have to is rotate the trackball and no make any code changes?

RandyT, here's a game that edits mouse data in the driver:
Marble Madness also had the trackballs rotated 45 degrees.  Mame has code that converts the mouse x,y to the game's p,q (made up letters) so that every possible mouse x,y combo has exactly one p,q combo (p=x+y, q=x-y).  The only problem is the p,q combos output are checkerboaded:  you can get (0,0), (0,2), (1,1), (1,3), (2,0), & (2,2), but not (0,1), (1,0), (1,2), or (2,1).  Some might suggest setting the sesitivity to 50%, but that's applied to the mouse data (from my step C) by mame core before the driver rotates it (after it sends it, step D).  IOW, on the original hardware the game could get direction combos that mame can't send.

So if you make a 45 degree trackball panel, edit the MM driver and remove the rotating code, too.  You'll probably get better play (how much better is debatable).

[RandyT]

IMO, the changes are happening between A & B

Ok, but then "A" should probably be re-defined as "Conversion of raw quadrature data to Mouse data".  What you stated originally was

...as between each stage the sender can manipulate the data before sending it.

There is no way for the sender in step "A", which you defined as "raw quadrature data" to modify it before sending it to step "B".  Quadrature data is opto-mechanical in nature and the sender is literally the opto-sensors and the output generated as the apertures pass through them.

Now, if you had, as the encoder wheel, a circular LCD panel that could change it's aperture layout dynamically, I might be more inclined to agree with your first statement.

RandyT

[2600]

We've had the Crystal Castles Discussion before.   The trackball is NOT rotated.  Look at the manual and ask someone with a real one, it is NOT rotated.

Never knew MM was, that's kinda cool.  I wonder why they did that.

[KevSteele]

We've had the Crystal Castles Discussion before.   The trackball is NOT rotated.  Look at the manual and ask someone with a real one, it is NOT rotated.

Never knew MM was, that's kinda cool.  I wonder why they did that.

It makes perfect sense: since the game is an isometric layout, most of the time you are going to be moving the ball in a diagonal direction. Twisting the assembly 45 degrees ensures the smoothest movement possible, since you'll be rolling the ball directly towards one of the rollers.

Very neat design touch, and a fascinating bit of trivia -- thanks, u_rebelscum!

Kevin

[RandyT]

We've had the Crystal Castles Discussion before.   The trackball is NOT rotated.  Look at the manual and ask someone with a real one, it is NOT rotated.

Never knew MM was, that's kinda cool.  I wonder why they did that.

It makes perfect sense: since the game is an isometric layout, most of the time you are going to be moving the ball in a diagonal direction. Twisting the assembly 45 degrees ensures the smoothest movement possible, since you'll be rolling the ball directly towards one of the rollers.

Hmm...I'm still baffled.  MM uses 360 degrees of motion, so the most benefit would be gained by placing the rollers against the direction most often required by the game.

Most of the time in MM, you are rolling the TB down and to the left or right, so rotating the unit such that the ball is sitting above a "V" formed by the rollers would make the most sense.  This would mean 135 degrees, not 45.

But there will always be a couple of directions that just aren't as good as others with a traditional 3 sided roller arrangement, regardless of the angle.  Maybe they did it for space considerations, as the trackballs get a lot narrower horizontally in that orientation, but that depends on which direction it was rotated. 

RandyT

[u_rebelscum]

We've had the Crystal Castles Discussion before.   The trackball is NOT rotated.  Look at the manual and ask someone with a real one, it is NOT rotated.

Yup, now that I'm home and looking at the manual, it's not rotated.

Most of the time in MM, you are rolling the TB down and to the left or right, so rotating the unit such that the ball is sitting above a "V" formed by the rollers would make the most sense.  This would mean 135 degrees, not 45.

You're right, the rollers were in a "V" shape, and yes that's actually 135 degrees counter-clockwise.  (Looking at the manuals now.)

I said 45 degrees because it's easier to understand, even if it's 180 degrees off the full truth.

IMO, the changes are happening between A & B

Ok, but then "A" should probably be re-defined as "Conversion of raw quadrature data to Mouse data".

No, no, no.  You just described what's between A & B!  Let me try again.

- A) The raw data from the sensors (quadrature data)

-  optional betweener #1) Conversion of raw quadrature data to "Mouse data, USB", "Mouse data, ps/2", "pulse and direction data", or any other format.  This is done by the device sending the next step.
- B) "the data sent from device to computer/PCB"

- optional betweener #2) Any convertion of data from step B before the data is sent on.  This includes from USB to directInput mouse state, (if any) speed scaling, (if any) enhancements, etc.  This is done by the OS sending the next step.
- C) "the data sent from OS to application (ie: mame)"

- optional betweener #3) Any convertion of data by mame, be it in the core or in the driver.  This is done by mame, the sender of the next step.
- D) "the data sent from mame to emulated game"

The three "betweeners" are the convertions, between the four data steps.  Notice I paired the "betweeners" with the next step....

...  What you stated originally was

...as between each stage the sender can manipulate the data before sending it.

There is no way for the sender in step "A", which you defined as "raw quadrature data" to modify it before sending it to step "B".  Quadrature data is opto-mechanical in nature and the sender is literally the opto-sensors and the output generated as the apertures pass through them.

My bad writing.

A) the data is sent.  B) the data is sent.  In between A & B, "the sender can manipulate the data before sending it."  Here, 'A' already sent it, so A can't maniplulate before sending it.  What does that leave?  The sender of B: the mouse board.  The board does the convertion and sends it.  Who sends C?  The OS; the OS/directX does the convertions and sends it.

That's what I meant.  Between each step, "the sender [of the next step] can manipulate the data before sending it."   

I know this leaves A as different from them rest, but nothing is before A, so there is no "between" before A, so the sensor senders don't do any manipulating.


Sorry for the long, nitpicky posts everybody.

[Kremmit]

Now, if you had, as the encoder wheel, a circular LCD panel that could change it's aperture layout dynamically, 

But will it have enough resolution to play Arkanoid? 

[u_rebelscum]

What about how mame itself  Polls for the data?

 A real  arcade machine may have polled at a certain rate.   It could have been at a per
frame basis..  or maybe it was tied into something else. 

 If mame  generically just polls at every Nth milisecond..  it may in fact poll too many times,
or too few times..  thus changing the sensativity, correct..?

Only if the polling is slower than the original.  Let me rephrase that.

As long as the OS and hardware polling is at least as fast as the original arcade, there's no problems.  The hardware and OS mame uses add the previous 'deltas' until polled, where they zero the 'deltas' and start counting again.

Mame is supposed to poll at the same rate, or some multiple there of, as the original hardware.  If mame is polling faster as it does in some drivers, those should be written so the extra polls are taken into account.

So if written correctly, no problems.  If not, problems, but should be easy to see.

"What if the polling timing is off by just a little for a game?"

Then the whole game's timing is off by that same amount, or if only part, then the whole game is not syncing correctly.

Also,  I believe a few games had some pretty whacky optical situations.  I think DOT spinner
has an analog to digital encoder built onto the optic board.   I think you mentioned this,
(i may be confused)  ... 

I believe in that case it is just translating the quadrature data format into a "pulse and direction" format.  Pulse and direction actually needs a faster data link than quadrature would, but was "easier" to design the motherboard for.  IOW, make the motherboard dumber, the encoder smarter by a fraction of a percent.

FWIW, most industrial relative encoders used to output both pulse and quadrature, and many still do for backward compatibility, but the industry is moving away from pulse.

Other encoders "more-digitized" the raw output from the sensors by "more-squaring" the square waves the sensors output, but otherwise left it alone:

Something like:

____/----------\_______

to

____|----------|_______

...but It makes you wonder how fast the arcade encoders were at
reading and sending the data... and maybe even changing it within that chip itself.

Was there any hardware acceleration in some of those machines?  Does mame consider this on a
per game basis? 

Not AFAIK.  And it can (in each driver), but not AFAIK.

It would seem that the key delta,  while a nice way to change settings of mouse sensativity..
only works on a per frame basis.  Where as the original hardware did it on the fly...

 Shouldnt mame have an  option for setting the exact multiplier for data changes in "realtime"?

"Key delta" is the multipler with which mame uses for simulating analog inputs from a digital one; it shouldn't effect the mouse data.

It is derived the same way as the default "sensitivity" is: by hand.  It is adjustable just like sensitivity.  I was using it just for comparisons for something to gauge the default sensitivity against.

I'm not sure by what you mean "on the fly" vs "only per frame".  Sure, per frame makes it hard to compare the keydelta on one game against it on a different game if they have different refresh rates, but "10 per frame" vs "600 per second" is the same thing on a 60 hz game, and most games polled inputs on the screen blank anyway.  "Per second" is like trying to make a silk purse out of a pig's waste: simulating analog input from digital inputs stink no matter what.

[RandyT]

Sorry for the long, nitpicky posts everybody.

Nothing to apologize for if the end result is clarity.  Thanks for taking the time.  I knew what you were talking about, it just seems like there is a better way to convey it.  IMHO, the quadrature signals, as a separate entity, should just be left out of the discussion.  It's a constant.  It seems that it would be more appropriate not to focus on the data, but rather the elements that affect it on it's way to the final destination.  The context was "Why does encoder wheel resolution not necessarily equal data seen, or used, by the game driver in MAME".  As such, I believe the following possible variables, which are pretty much your "between" steps, explain it more clearly;

A) Translation of quadrature signals to step quantity and direction by hardware
B) Conversion of step quantity and direction to mouse or other format usable by the PC/OS
C) Alteration by OS (acceleration, DirectInput, etc)
D) Alteration by MAME's "sensitivity" routines.
E) Alteration by the individual game drivers.

You're right, the rollers were in a "V" shape, and yes that's actually 135 degrees counter-clockwise.  (Looking at the manuals now.)

I said 45 degrees because it's easier to understand, even if it's 180 degrees off the full truth.

Ok, that makes more sense.  Except that 45 degrees doesn't do it in either direction.  It would need to be rotated 135 degrees counter-clockwise or 225 degrees clockwise to get to that position.  Again, for the sake of clarity, not nit-picking

RandyT

[2600]

Also,  I believe a few games had some pretty whacky optical situations.  I think DOT spinner
has an analog to digital encoder built onto the optic board.   I think you mentioned this,
(i may be confused)  ... 

I believe in that case it is just translating the quadrature data format into a "pulse and direction" format.  Pulse and direction actually needs a faster data link than quadrature would, but was "easier" to design the motherboard for.  IOW, make the motherboard dumber, the encoder smarter by a fraction of a percent.

FWIW, most industrial relative encoders used to output both pulse and quadrature, and many still do for backward compatibility, but the industry is moving away from pulse.

This is what I consider 1x.  The data is still "quadrature", but you are using one signal as the clock and the other as data.  Sticking with the DOT example, they stuck a counter on the optical board, instead of the main pcb.  Why? who knows for sure, but maybe they were having problems with signal.  On the rising edge of the "clock", the state of the data line has the counter count up one or down one.  This allows for the 128 states per revolution for DOT.  1x is easy because you don't need to know the previous state.

Stating this part for completion and I think 1UP asked:
2x would be the same, except you are polling both rising and falling edge.  And 4x would be polling of rising and falling edge of both signals.  This is what allows the increase in resolution, with NO "jumpiness".  The data is there you just have to read it correctly. These also require a bit of memory and you need to process faster.  This was my rational for Arkanoid, I didn't think the processor was fast enough to do 4x with 486 tooth count.  Plus it seems pretty common to label the lines as clock and data when you are doing 1x.

[u_rebelscum]

...1x is easy because you don't need to know the previous state.

Stating this part for completion and I think 1UP asked:
2x would be the same, except you are polling both rising and falling edge.  And 4x would be polling of rising and falling edge of both signals.  This is what allows the increase in resolution, with NO "jumpiness".  The data is there you just have to read it correctly. These also require a bit of memory and you need to process faster.

Agree, except most current hardware now does 4x by "change of state", not at edges.  (source (pdf file))  Basically the same thing, except now there can be errors.

Or is this what you meant by "These also require a bit of memory"?  (And you need four bits of memory: 2 bits for current state, 2 bits for previous state, with each bit coresponding to one of the two sensors. )

[u_rebelscum]

... It seems that it would be more appropriate not to focus on the data, but rather the elements that affect it on it's way to the final destination.  ... the following possible variables ... explain it more clearly;

A) Translation of quadrature signals to step quantity and direction by hardware
B) Conversion of step quantity and direction to mouse or other format usable by the PC/OS
C) Alteration by OS (acceleration, DirectInput, etc)
D) Alteration by MAME's "sensitivity" routines.
E) Alteration by the individual game drivers.

You're right; that's much clearer and direct to the point (and shorter ).  Any and all of these (can) change the resulting number the game sees.

I was stuck in my old train of thought ("mouse" means different things at different times) for so long (since before I started editting mame code) and been applying this train to everything, it's good to get the rust shaken off with a new view.

[telengard]

 An interesting thing about  Crystal Castles..

 I looked up the picture, and indeed, the trackball  is mounted at a 45 degree angle.

  I thought..  Can this really affect gameplay? 
 
 So I took out a Happs trackball  (unconnected)  and tried a few spins...

  Sure enough, at a 45 degree angle the ball travels faster and more fluid
when moving in Diagnal directions.


 Why?

 Its due to the placement of the rollers and the friction that is creates.

 When rolling the ball in such a way that makes Both rollers spin
at the same time..  it causes more friction.   
 
 This means that even when you roll the ball
very hard..  it will slow down very quickly.  Its also harder just to "start"
getting both rollers to roll at the same time. 

 If the ball weighed more,
it might actually be better..  but as it stands,  the ball  sometimes
wants to hop a bit between the rollers, as well the ball  "slipping"  instead
of actually turning the rollers.

but...

 When rolling only "One"  roller..  its smooth as butter!   The  "spin time"
will be very long (as long as yout T.ball is clean and bearings are
lubed properly).     To stop and start is effortless, and theres no
"slipping" at all.   Perfect control, smooth feel, fast and accurate.


 So... I guess I will have to build a  Rotating Trackball Mounting Plate  now

 
 I think someone needs to find a way to make a near frictionless trackball...
Or at least,  much less that whats currently available.

 

Sorry to dreg up such an old post but I played Crystal Castles again not too long ago (with the latest mame) and was still frustrated with the controls & my 3" happ.  Did a search to see if anyone had found any new info and found this.  Not sure how I missed it.

I was aware of the orientation being different but I am happy to hear that it does affect gameplay.  Looks like I too am going to have to make a 45 degree rotated module so I can play CC the right way!  It's one of my favorite games but it's so frustrating to have it so close but still not "right".

thanks so much for the info...

~telengard

[Xiaou2]

 Sorry,  It turns out that I was mistaken.    I got confused because I
saw the bolt holes at 45 degree angles.  If the trackballs are mounted using
a happs mounting plate, the holes will be aligned differently.  However,
the arcade machine did not use a mounting plate.

 

[brandon]

so if Arkanoid had 486 teeth but the screen resolution is only 224 pixels wide would all that resolution be nesessary since there arent even 486 descreet positions?  maybe I'm confused...

[Kremmit]

so if Arkanoid had 486 teeth but the screen resolution is only 224 pixels wide would all that resolution be nesessary since there arent even 486 descreet positions?  maybe I'm confused...

I think you're assuming that the game should move the on-screen paddle one pixel for every encoder tooth, and that it should take one full rotation of the spinner knob to move all the way across the screen.

On the one pixel-per-tooth half of that, . 

As for the other half, you can move the paddle all the way across the screen with considerably less than a full turn of the spinner.  That's good in a game like Arkanoid, you have very fine control on-screen without ever letting go or adjusting your grip, and you can move all the way across the screen very quickly without ever losing that control.  That's what the extra-high resolution is for.