| Main > Main Forum |
| 720 controls design - wouldn't this be better?? |
| << < (8/9) > >> |
| RandyT:
--- Quote from: Ummon on October 11, 2009, 10:33:08 pm ---Anyways, yeah, I totally forgot it was a chain-driven mechanism an all. --- End quote --- It's not really "chain driven", rather it's driving the chain. The chain is specifically there to burn off momentum, and probably add some resistance as well. I think it was mentioned earlier that the operator could adjust the screw to make it not free spin. --- Quote --- 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. --- End quote --- I'm having trouble with the terminology. What are you referring to when you say "race"? --- Quote ---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. --- End quote --- The spinning top wouldn't work (well), due to the angles. It would need to be something like a ball pivot, which would probably pinch the hell out of your hands. I think this is why they went with a shaft that was decoupled from the encoder shaft. This way, it feels like regular joystick in your hand in that the stick shaft can be turned, and it can still be spun. There might be another approach that gives the same effect, but I can't think of one at the moment that wouldn't drastically alter the feel and appearance of the control. RandyT |
| u_rebelscum:
I hate it when I'm put in a position defending points that aren't mind. --- Quote from: Xiaou2 on October 14, 2009, 12:30:59 am --- --- Quote ---Something I totally agree with Aaron is that if you don't enjoy what you're doing for fun, you wouldn't be able to continue doing it: for the mame project to continue, it has to be fun for the coders. --- End quote --- Thats all good and stuff... However... (good points removed for space) Mame can and would still continue if nobody else supported it.. however, its pace would be a heck of a lot slower. --- End quote --- That's what some MameDev want: slower development, less visible, less side issues. Which this (inputs) is to most mameDevs, sad to say. IOW, some mameDev say "so what" to your points. If you want to spend some time (~1 hour total) on seeing how Aaron thinks on how mame should (& is) be run, you can catch his talk on how to keep a project running for many years ( of 5). He addresses your points far better than I can, and is the head of mameDev, so far better authority on it than me. --- Quote --- --- Quote --- You're talking about adding a one game option to mame's Core Input Options? --- End quote --- No. Im talking about any and all games which have similar problems. Such as the problem with not being able to use a real arcade shifter in all racing games in mame. --- End quote --- You showed three new options, one that effects one game, the other two effect at most 236 parents (that number from all "driver" genre parents at Maws), or 5.5% of all parents in mame. (slightly higher percentage than if I included clones). The latter two option have a (very very small) chance, the one game option doesn't. --- Quote --- --- Quote ---Mame will never add a game specific option. Code bloat, code support, code maintainance, code upgradability, option bloat, help support, modularity, all point at not doing it. So your "solution" is not valid for official mame. --- End quote --- Never? I didnt realize I was speaking to the Leader of the band... --- End quote --- Prediction that will be true as long as Aaron or Haze lead mame. After that, who knows. --- Quote --- Every few releases... Mame has done some extensive changes which for the most part, are not all that necessary, and do not do much to change anything. Its simply more palatable and cosmetic than actually useful. --- End quote --- Almost all the changes you're alluding to as "not changing much" is for cleaner code, better modularity, better expandability, and preparations for further changes that many people (including you) here want (linked cabs, for instance). As you say, almost zero changes for the user. Not necessary for the current status quo, true. But it's necessary for future changes, future viablity, and the future of mame. --- Quote --- --- Quote ---I didn't say I came up with the idea. I helped implement it, and messed with the code, so know how it works. And know how much a pain it is to have multiple mame inputs combined to one game input, and it's not easy. --- End quote --- I also found your older builds confusing.. as with so many options.. a person would have a hard time figuring out how the heck the actual game was supposed to be controlled. However, this is Not that case. Its dead simple. You click arcade control if you have a real controller. Its not 55 ways to control a game all in one menu. --- End quote --- Again, you're looking at the user's point of view. The bigger issue, AFA mameDev cares, is the from a coder's point of view. Code-wise, what does the switch do? Is the difference in the core level, or in the driver level, or a mix? (Looks like 90% driver to me, which is the harder side, as each driver has to be updated, and if the driver is WIP this addes another thing that might break.) How does the user remap the two different (real vs PC) input? How is it coded? How does mame save the mappings? What other game "specific" "real options" are we going to run into (qbert & roadblaster OTTOMH)? The way I see it, the code is going to be just as mixed as mine was. Driver level if real_option then do this with these inputs, else do that with those inputs. Expanded input define MACRO sections. Either expanded info.c resulting bigger listxml, or the "real" inputs not ducmented in listxml. Either the hacked mess I had with fake player 2 & 3, or new input type(s) to cover the special "real" ports, or somme radical new way of doing it. I very well could be wrong on the details, but it looks hard to code to me. If someone doesn't love inputs as much as you or me, and doesn't know more about coding than I, they aren't going to do it. --- Quote ---Just like it doesn't do pong. --- End quote --- Mame is: Multiple ARCADE Machine emulation. Excuse me... But wasnt Pong an Arcade Machine?... [/quote] You -> Preacher Me -> Choir All you said on this is valid, and won't convince someone not already in the choir. :-\ Which is why I said "Just like pong". ;) |
| u_rebelscum:
--- Quote from: SavannahLion on October 14, 2009, 01:09:03 am ---What's to stop MAMEDev from defining raw input, allowing us to leverage that raw input and then let people like Randy develop the hardware to go with it? Isn't that exactly what 255 USB class is specifically for? For situations just like this. --- End quote --- 255 USB class? I'll have to look that up. But... AFA mame goes, a few things. First, the same thing that's stopping the spacenavigator from working: someone needs to write extra code for mame to reconize the non-game-control / non-pointer class input. Second, for mame to use the info, it either has to behave like the other classes (like the spacenavigator would) or mame has to setup special ways of storing and translating the data. Third, the same thing I've been saying above: aaron's policy is to avoid multiple ports for a single input. Some clean way to have the two ways (raw original & PC standard) to be there without confusing the source code, confusing the coders, and lastly and least importantly confusing the user more than needed. |
| Ummon:
--- Quote from: RandyT on October 14, 2009, 04:34:34 am --- It's not really "chain driven", rather it's driving the chain. --- End quote --- Technical bast. But, yeah. --- Quote ---I'm having trouble with the terminology. What are you referring to when you say "race"? --- End quote --- Flat, roller-type ball bearing assembly - that would either support the hub the crank/stick was mounted to, or as an all-in-one unit. Make more sense? --- Quote ---The spinning top wouldn't work (well), due to the angles. --- End quote --- I think it'd give a hell of a lot more relief than having to ease up on your grip. I hated that. Hell, go for broke, and put a crank assembly on it. I thought it was way weird as a 'stick' back then, but this is not surprising. |
| u_rebelscum:
--- Quote from: u_rebelscum on October 08, 2009, 01:04:55 pm ---What do you mean by "race"? --- End quote --- --- Quote from: Ummon on October 15, 2009, 10:16:17 pm --- --- Quote ---I'm having trouble with the terminology. What are you referring to when you say "race"? --- End quote --- Flat, roller-type ball bearing assembly - that would either support the hub the crank/stick was mounted to, or as an all-in-one unit. Make more sense? --- End quote --- I'm still not picturing it, of at least not seeing it like you probably are. Very rough pic below. Is the "race" the thing holding the lower disk? If not, could you draw a rough pic of you're talking about? |
| Navigation |
| Message Index |
| Next page |
| Previous page |