Main > Main Forum
New Product (In Stock/Shipping) - Apache Controls Blackhawk Push/Pull Spinner
<< < (11/16) > >>
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:


--- Quote from: Xiaou2 on July 07, 2006, 06:13:55 am --- 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.

--- End quote ---

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. ;D) 
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:
TotalDialTrackAve454149Median302530Total #541363178% =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. ;D


*(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,   :dizzy:   :notworthy:      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:

--- Quote from: Xiaou2 on July 08, 2006, 06:47:05 pm ---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.


--- End quote ---

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

Go to full version