| Main > Main Forum |
| New Product (In Stock/Shipping) - Apache Controls Blackhawk Push/Pull Spinner |
| << < (14/16) > >> |
| u_rebelscum:
--- Quote from: 2600 on July 11, 2006, 04:00:50 pm ---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. --- End quote --- Yup, now that I'm home and looking at the manual, it's not rotated. --- Quote from: RandyT on July 11, 2006, 05:27:00 pm ---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. --- End quote --- 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. ;) --- Quote from: RandyT on July 11, 2006, 03:35:58 pm --- --- Quote from: u_rebelscum on July 11, 2006, 03:03:58 pm ---IMO, the changes are happening between A & B --- End quote --- Ok, but then "A" should probably be re-defined as "Conversion of raw quadrature data to Mouse data". --- End quote --- 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.... --- Quote ---... What you stated originally was --- Quote from: u_rebelscum ---...as between each stage the sender can manipulate the data before sending it. --- End quote --- 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. --- End quote --- 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. :D |
| Kremmit:
--- Quote from: RandyT on July 11, 2006, 03:35:58 pm ---Now, if you had, as the encoder wheel, a circular LCD panel that could change it's aperture layout dynamically, --- End quote --- But will it have enough resolution to play Arkanoid? ;) |
| u_rebelscum:
--- Quote from: Xiaou2 on July 08, 2006, 09:14:01 pm --- 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..? --- End quote --- 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. --- Quote --- 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) ... --- End quote --- 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 ____|----------|_______ --- Quote ---...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? --- End quote --- Not AFAIK. And it can (in each driver), but not AFAIK. --- Quote --- 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"? --- End quote --- "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:
--- Quote from: u_rebelscum on July 11, 2006, 09:27:46 pm ---Sorry for the long, nitpicky posts everybody. :D --- End quote --- 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. --- Quote ---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. ;) --- End quote --- 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:
--- Quote from: u_rebelscum on July 11, 2006, 10:27:33 pm --- --- Quote --- 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) ... --- End quote --- 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. --- End quote --- 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |