Main > Main Forum
Yie Ar Kung-Fu has THREE buttons, not TWO!?!
<< < (20/35) > >>
nipsmg:
Wow this thread turned crazy.

I feel I need to toss in my $0.02 sense in.

I agree with Xiaou2's point that if MAME is truly documenting the hardware, that support for that 3rd button should be included in one way or another.  The think that Xiaou2 doesn't realize is that the support for the 3rd button IS included. 

The 3rd button is coded into the game's software in the first place.  Now, the original PCB (according to many people) didn't specifically expose the 3rd button (i.e., it was not connected to the wiring harness in any way).  Although there was a 3rd button in the game, getting to it would have involved hacking a 3rd button by adding a wire to the stock harness and jumping whatever pin exposed the 3rd button over to the connector for the harness.

So, in exactly the same was as the hardware didn't expose it, the MAME team removed the exposed interface for button 3.  Now, if you really want to expose button 3, you essentially have to put in your own hack (or patch) to enable it.  MAME emulates the hardware MORE ACCURATELY by removing the interface to the 3rd button actually.  The control interfaces relate DIRECTLY to the hardware and also should be implemented accurately.

Someone can easily create a patch using code prior to u3 and allow people to "hack" in that functionality, just like there are plenty of other patches for that purpose.

What I don't agree with Xiaou2 about is how "easy" it would be to change text color for an unsupported control interface or any of the other features that he touted as "easy to implement".  As Xiaou2 fully admits he's not a developer, he has NO CONCEPT of the complexity of software in general, nevermind something as complex as MAME.  Something as "easy" as changing the text color would involve numerous changes such as:  Creating some designation in the core mame code to support "unsupported" controls, changing the menu code to be able to query for that identifier and display it differently, change whatever base code defines what controls types can be used and changing that, and I'm sure tons more.  It's a lot of code that DOESN'T GO TO HELPING ACCURATELY DOCUMENT THE ORIGINAL HARDWARE.  It's a ton of work.

I also think Haze is being a little disingenuous about how easy it is to "learn programming".  As a professional developer and project manager with over 10 years of development experience, I can say with confidence that learning programming is NOT that easy.  And that there's also a big difference between learning how to code, and learning how to code WELL.  It's like saying that anyone that can cut a piece of wood and nail it together is a Carpenter.  It's just not the case. It takes years of experience.

However, I do agree with Haze's assertion that if you want it fixed, you'll have to learn programming, or find someone who knows how to code in order to get it implemented.  Just like if you had the legitimate cabinet and you wanted to expose the button the manufacturer didn't want exposed, you'd have to either wire it up yourself or find someone that knows how to solder electronics to do it.  It's not sufficient to say "I don't know how to solder", and call up the company complaining, it's just not the way to get it done.

Haze:

--- Quote from: nipsmg on November 15, 2010, 10:57:41 am ---I also think Haze is being a little disingenuous about how easy it is to "learn programming".  As a professional developer and project manager with over 10 years of development experience, I can say with confidence that learning programming is NOT that easy.  And that there's also a big difference between learning how to code, and learning how to code WELL.  It's like saying that anyone that can cut a piece of wood and nail it together is a Carpenter.  It's just not the case. It takes years of experience.

However, I do agree with Haze's assertion that if you want it fixed, you'll have to learn programming, or find someone who knows how to code in order to get it implemented.  Just like if you had the legitimate cabinet and you wanted to expose the button the manufacturer didn't want exposed, you'd have to either wire it up yourself or find someone that knows how to solder electronics to do it.  It's not sufficient to say "I don't know how to solder", and call up the company complaining, it's just not the way to get it done.

--- End quote ---

For commercial programs and products, yeah, it can be tricky, there is a lot more to learn.

For MAME, the skills needed are a more specific subset (although I think a fair number of Aaron's recent changes have increased the learning curve somewhat, the C++ stuff isn't as immediately understandable as the plain C code for beginners)

Actual emulation (of systems) is pure logic, and understanding of the original game code, and what a piece of hardware can do within reason; for the most part it's identifying addresses and bits and coming to reasonable conclusions about what they do.  Tracing things from original schematics / reverse engineering protection devices are different skills however, a protection device black box simulation can be pretty complex, and schematic reading generally requires an understanding of electronics rather than just logic.

But yes, there is a significant amount of work involved in adding the features X2 is requesting, and an overhaul of the input system in general.  Remember that every single driver in MAME has some form of input port definition, which right now includes details of how the game reads the inputs, as well as what they actually are, and in some cases flags to indicate cabinet behavior (4-way etc.)

For a complete overhaul every single case in MAME would have to be split into at least 2 different structures to allow a cleaner separation between the actual bits read as inputs as read by the game, and the actual devices / cabinet.  This is non-trivial and further increases the complexity of the codebase.  Even 'simple' things as suggested aren't so simple, if you observe carefully MAME makes no use of coloured text right now, I doubt there is even support for it.  The UI code is basically Aaron's territory, and input code is basically Derek's these days, and to achieve anything they would have to work together which is something I'm not seeing a great deal of as of late.

MAME in many cases is an easy project to contribute towards, and yes, readding things like the 3rd button is a fairly trivial source mod, it would be a push to say you even need programming skills for it as most of the 'code' you'd have to change is a bunch of mame structures / macros which don't really resemble code at all (they exist for the purpose of clearer documentation)  From that point of view MAME might be considered a strange project, because such extensive use of preproccesor MACROs is usually heavily discouraged, but in the case of MAME it works well, and aids readability no end.

There is no point in bugging the devs about such things, because for the most part they just want to get things running, the rest can be taken care of later, the actual system emulation is the interesting, and important part, and there is still plenty of that to do (albeit with sadly few devs to do it)

I've worked on big projects, console-based projects, windows-based projects as well as other emulation projects, and MAME is by far the easiest of the bunch to work with and learn (or at least was, but I still think it is significantly easier than many others)

FrizzleFried:
RosieMonster says...

"IN BEFORE THE LOCK!"

abaraba:

--- Quote from:  nipsmg ---I agree with Xiaou2's point that if MAME is truly documenting the hardware, that support for that 3rd button should be included in one way or another. 

--- End quote ---

documenting - support - included; It's interesting that we all kind of agree "what" needs to be done, yet there is disagreement on "how" it should be done and what exactly it applies to.



--- Quote ---The think that Xiaou2 doesn't realize is that the support for the 3rd button IS included. 

--- End quote ---

No, not any more.

MAME devs had to do nothing about it in particular to include or support it, it comes within the game itself, and game ROMs are not part of MAME that only provides "drivers", emulation layer for "hardware" part, and together with game ROMs, the "software" part, we get complete virtual PCB.

So, what MAME should support/document is Inputs and Outputs of the PCB and emulate it in whichever internal way, where the point is for each and every input to produce the output as what the actual PCB would.

Now, to fully and properly DOCUMENT a PCB via emulation, the driver must INCLUDE all the Inputs/Outputs present on the actual PCB, it also must SUPPORT those virtual pins can be virtually wired or "mapped" in control panel, just like all the other I/O (test, service, dip switches), otherwise it's simply not documented.

Yes, that control panel in MAME, where you set "game default keys", that is supposed to be a document describing PCB connector pin-out, so once Luigi removed "support" for those pins, he undocumented the PCB I/O in favor of documenting the harness.


Do you see the problem?

We should be able to look at MAME input control panel and know all about every pin and I/O on the PCB of any given supported game, but now we have documentation before and after Luigi. First we learn there was available 3rd button input and we could virtually wire it, then Luigi came, however he is not even talking about the PCB anymore, but about the loom and cabinet wiring, about operators manual!!

After Luigi's patch there is not even any trace left of this functionality ever existed. It is NOT documented/included/supported by MAME, not any more. Yes, it will always exist embedded in game ROMs, but no one will know about it, which is in contrast to 'preserving' and 'documenting'.


Haze said he is familiar with MAME input, I think, so perhaps he can confirm whether this 3rd button could have been supported in older MAME without it actually being accessible and *legitimate I/O on the actual PCB to start with.

*legitimate enough to be documented, just as dip switches (often with unknown functionality) and everything else is, like service and test buttons that no one goes on to disable even though they are not implemented on many boards.
Xiaou2:

--- Quote ---The difference between a dual shock analog stick and robotron's dual joysticks is NOTHING like the difference between a Beetle and an F1 car.
--- End quote ---

 While it is a bit of an exaggeration, its still a good analogy.


--- Quote ---but as far as the controllers are concerned this is virtually no difference, and it could easily be argued that the analog stick, due to only requiring smaller movements (the deadzone isn't that big, and it's a smaller device) will give you far tighter and more accurate control anyway.
--- End quote ---

 You see, this is where software people get things all wrong.  Do you know what a Lever is?   The original stick isnt like a see-saw.  Its got a leveraged advantage of like 2 to 1.  So, the bottom of the stick moves twice as far as the top.  The switches themselves are tweaked to a hair trigger.

 The leaf switches have like a Millimeter clearance between contacts, and the Joystick actuator which presses the switches, is actually Touching all the switches. Meaning, that with about a single MM of travel, you are changing direction.

 NOW...

 An Analog stick is not leverage the same way.  Analogs need a wider range of motion to provide much more resolution.  Because of this, you have about 5 times as much travel to the furthest extents.  Then you take away a dead-zone for poor accuracy, and that leaves you even more problems.  Then you add in the fact that an analog has a dual spring system that puts major tension in the middle, & little tension on the middle to outside edge... and that compounds things even more.
(much more apparent in a game like Sinistar, where even the tiniest move can make you go warp speed, & or the wrong vector)

 A Wico 8leaf has a rubber center ring, and its a central pivot. The center is easiest to move within (low to no resistance at all), with the outer edges being a touch more spring to it.  Yet because its center pivoted, the negative effects of control loss (reaction times/speeds ) & fatigue thru resistance, are almost gone in totality.

 You see, for every time you have to move from left to right, the wico will beat your stick by about 3mm in each direction, for 6mm travel total loss in efficeincy.  And thats in ONE "juke" move.  Then, if your analog stick is like most, with a squared guide edge... every time your stick gets deep into a corner, you will lose even more distance and time.  The wicos have a round edge, and can glide effortlessly in circular directions without any physical corner-jolt, nor the extra distance the stick travels to get into that corner (about 1.5 to 2 mm).

 Yes, an analog can be set with a low deadzone... and if you could somehow play without going to the extreme edges of the ministick (nearly impossible due to the heat of battle, and the lack of resistance to properly hold you away from the edge), you might be a little better off... but even then, you still wont beat the 1mm wico activation gap... and you wont beat the corner losses.

 As such, in a game like Robotron, with a mini analog, you will effectively be lapped by the F1 car about 100 times in a single level.  That is how much loss you will have in extra distances, frictional spring resistances, and corner friction+distance losses.


--- Quote ---  That's what I find.  I'd actually say the dualshock was a better controller than the antiquated original design.
--- End quote ---

 Its a good think programmers stick to programming, and not building cars or at best.. joysticks.   You really dont understand a single thing about simple mechanics, physics, leverage..etc.   Study up, cause you just got "Schooled" Hardcore by a self admitted dummy.


--- Quote ---Also, take into account things like height, on a real Robotron cabinet it's incredibly uncomfortable for me to play because I'm too tall
--- End quote ---

 My buddy, who got over level 35, is about 6'3.  He played along on the Original standup game, for several hours at a time without problems or complaints.


--- Quote ---The bottleneck of Robotron ability is not in the controls, but in your reactions, and ability to plan where you want to go / shoot.
--- End quote ---

 Its more than just planning.  You have to be able to change plans fast, because things get out of hand very quickly.  Especially when you have a zillion bouncing balls flying all over the place, or being pommeled with ememy fire from multiple directions + nearly getting run over by flying and walking enemy.  Basically, you need to be able to Juke and change direction at close-shave pixel miss speeds. And if your controller reaction is too slow, that pixel wont miss.. it will hit.. and you will lose a life.  I cant count how many times my character was 1 pixel away from death.. on even a single level... let alone in a full game.


--- Quote ---   Using real controls, even if I could use them perfectly would not change that.  I've never played the game with a dualshock and thought I died *because the controls sucked*.  Every time I died it's because I made the wrong decision.

--- End quote ---

 There is partial truth to this, but that is because you are an extreme beginner.  
When you get good enough with correct strategy, then it comes down to precision and lighting fast jukes/escapes.  All of which cant be preformed on a mini analog. There simply is way too much travel and resistance for that.

edit...

 And finally,

 Age does not change PHYSICS.  Once you realize that, you can realize that there is no such thing as antiquated mechanics.  It either works better or worse based on mathmatics & physics.  As such, you cant apply your Childish attitude of "Because its not from my Generation, it must Suck"  card.  Quite simply put, this isnt Opinion. Its pure undisputed undeniable Fact.
Navigation
Message Index
Next page
Previous page

Go to full version