Main > Main Forum

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

<< < (12/16) > >>

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.


--- Quote from: u_rebelscum on July 08, 2006, 07:27:22 pm ---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"

--- End quote ---

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:

--- Quote from: RandyT on July 09, 2006, 12:54:44 am ---
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.

--- End quote ---

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.



--- Quote from: u_rebelscum on July 08, 2006, 07:27:22 pm ---(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).

--- End quote ---

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:


--- Quote from: RandyT on July 09, 2006, 12:54:44 am ---...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.


--- Quote from: u_rebelscum on July 08, 2006, 07:27:22 pm ---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"

--- End quote ---

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?

--- End quote ---

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:

--- Quote from: Kremmit on July 10, 2006, 11:20:02 pm ---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.

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version