| Main > Main Forum |
| 720 controls design - wouldn't this be better?? |
| << < (5/9) > >> |
| Xiaou2:
Mames Policy is the Policy of ---smurf-poo---. There is No reason whatsoever that there can not be two different ways to control a game. None. Im not a programmer.. But Ive coded simple 'basic' on a TRS-80 & the c64, and so I understand the concepts very easily... as well as Logically. Nobody wants to be bothered to add dual support. That is the only real reason. |
| Ummon:
--- Quote from: Xiaou2 on October 11, 2009, 06:20:45 pm ---Mames Policy is the Policy of ---smurf-poo--- --- End quote --- Hmmm...maybe the auto-censor is dominating? Anyways, yeah, I totally forgot it was a chain-driven mechanism an all. Partly, I was caught up with my own idea - which is it being a spinner-type device, with a race/spoke deal at the top that the angled shaft is connected to - kinda like a manual mixer or drill with a slanted shaft, rather than a crank. The dexterity required to turn the race might be more than enough to compensate for the slickness of the spinner element. Even re-designing it further by putting in a crank with a spinner handle could be cool (I've actually presented this idea in years past), and the race set-up still possibly present enough resistance. Regardless of design, the handle should be a spinning top - it should've been on the game, and I thought so the first time I played it in '86. I really thought they missed the cherry on that sundae. |
| SavannahLion:
u_rebelscum & 720. I didn't realize it, but I read about that work on jstookey's page and the hack to support the 720 stick. --- Quote from: u_rebelscum on October 11, 2009, 05:16:40 am ---...and most importantly mame's policy is to do only one (mame) input per game input, it was either an input that didn't work for any controller, or the analog joystick simulation. --- End quote --- Doesn't this ideology go against the ideology of accurately emulating the hardware? Oh well... At least the consolation prize is we have the actual source. I recall jstookey created a patch for just such a purpose. |
| u_rebelscum:
--- Quote from: Xiaou2 on October 11, 2009, 06:20:45 pm --- There is No reason whatsoever that there can not be two different ways to control a game. None. --- End quote --- As one who hacked multiple ways to control one input in a few games for mame:Analog+, I disagree. The headaches trying to explain the differences between the player 1 dial & dialV (the "original" 720), the analog joystick, and the 8-way joystick inputs, and how they all controlled the same thing was a Major pain, and one reason I really don't like doing game specific hacks. (The other multiple input types example was the dial vs impulse buttons vs 12 buttons inputs for the rotary part of rotary stick.) Add to that, if mame did what you want, mame would output (listxml), and romlister would incorrectly think, that those games had way more inputs than they really did. Incorrectly documenting the inputs in either case. If someone could change mame's input handling/mapping, and someway say "720 controller" and have two totally different input mapping (analog/8-way stick and original controller), I'd agree with you. In fact, mame's "positional" input type was originally projected to combine the three inputs I listed above in the second example. However, it only combined two (dial and pulse inputs), and it's beyond my skills to add the third, twelve switches aka original raw data. And doing the same to cover 720 is even harder.* So the question is use a simulation that works for 99.9% of the users and document it correctly in the source, or add code so the original controller that noone uses works but also adds to the headaches of coding, helping users, garbage in garbage out, and document it in the source. MameDev IMO smartly & correctly has chosen the first. We are free to add hacks to the the code to support more inputs. But I see no reason for me to do so yet, until ram-controls actually starts selling the controllers. *I can picture it though: For all spinner (dial type) inputs, you could have seven "translations": normal spinner (no translation), indexed spinner (two axes or one axes + index buttons), analog joystick (two axes), analog joystick (one axis absolute), analog joystick (one axis relative), direction buttons, and X switches. Positional type does two of these already. however, the whole input code would have to be redone, probably breaking all current cfg and ctrlr files, and overall be a pain. To help fix less than 1% of the the games (720 & rotary games) for less than 1% of the users (those with 720 controllers & original mechnical rotaries)? MameDev won't waste the time, and would take one of that 1% of 1% (ie: one of us) to code it cleanly and for better documentation. |
| RandyT:
--- Quote from: u_rebelscum on October 11, 2009, 05:16:40 am ---After that, the index sequence seems to correct for up to one missed tooth and one gap (72 teeth = 144 counts per rotation, and the index can correct for 2 out of the 144). The game know which direction to correct for by the order the index sequence happens. I assume it can do two per index sequence because there are two gaps in the index wheel. (constant correction index) *Note that the current code in mame only does one count per revolution, however, which is why I say partially. Mine did the same. --- End quote --- Ehhh...talk about overkill. It's hard to understand why it was done like this, considering there are far more possible positions reported by the encoder than the 16 possible angles programmed for on-screen character. Considering that, I'm really surprised they didn't just tie a single break (rising edge) in the index wheel to a specific character position. The tiny error would have been unnoticeable, and it could have tightened it up even more with this method if it corrected based on the current direction. Regardless, since the code doesn't seem to care whether the index wheel transitions ever occur, why not emulate the hardware by simply tying one of the inputs to the index? If you have the real hardware, it modulates the input (button, keypress, etc) and MAME can act on it. If not, leave the input hanging (assigned to "none") and it never comes into play. Should offer the best of both worlds without the specific need to support two different types of controls. Or have I missed something? RandyT |
| Navigation |
| Message Index |
| Next page |
| Previous page |