MAME - 4-way emulation

[Le Chuck]

With the ability to implement an auto switching solution rapidly approaching plug and play and prices on such modifications dropping equally rapidly software solutions as currently being discussed are becoming unnecessary stop gaps for a shrinking and soon to be non existent problem.  If folks want to play classics they buy dedicated 4 way sticks that provide authentic performance.  Ditto 8 way.  Now you can have both in one package and have the game play be authentic for both for a marginal price hike.  Analogies about cars and guns seem to be out of place in my thinking but I'll add my own to the mix.  Screw drivers.  I don't screw phillips with a standard driver.  I could, but it's a PITA and the results are sub par.  I have both kinds of driver in my drawer but the one I use most is the little bit with philips on one side and standard on the other.  It has a nifty little chuck that allows me to flip around to the one I need.  It just works to use the right bit for the right head.  I wish I had one that knew what screw I was using and changed automatically. 

The stick currently on the market closest to doing this out of the box isn't even Randy's so I don't know why anybody would be all up in his grill about this issue.  I have high hopes that Randy will release a product with similar (not identical) automation and when he does I'm likely to be one of the first to sing its praises however that isn't the case as of right now. 

Kudos to Randy for taking the time to dispel myth and to share knowledge 

[rablack97]

I thought this was a innovation forum, so technically bottom line is don't try anything else new, it's all been tested by 2 people on this Earth.  So case closed?

I'll use a different word now instead of preference....It's a different option, to some people if it get the job done and your having fun then that's enough....

Now there is a Elite group of folks that won't settle for less than perfect, and that's fine.  His idea might be poor compared to the Lamborghini's of the world, but guess what there's a piece of s**t kia out there that will get me to point a to point b, and for a majority of the population out there that's enough.....

Poor is a strong word though, cause i use said 4 way logic today, and don't see a real problem with.  Will it revolutionize 4-way probably not, but will it get me through a game with pretty good high score, for sure. 

It's no different than business, you guys advertise multiple types of sticks, buttons, switches, etc. to give the population options. If we all looked at the logistics of perfecting one thing then there would be no other options, cause they would be considered too poor to even bother with.

So commend the man for trying instead of blowing his attempt out of the water with science and math, or telling him to give up.....

You know they laughed at Noah  too, and told him not to build the ARK.   Science, math, and testing didn't see the rain coming did it?

Don't hate participate, people....who know what will come of it...   going to timeout now...

[Le Chuck]

I thought this was a innovation forum, so technically bottom line is don't try anything else new, it's all been tested by 2 people on this Earth.  So case closed?

I'll use a different word now instead of preference....It's a different option, to some people if it get the job done and your having fun then that's enough....

Now there is a Elite group of folks that won't settle for less than perfect, and that's fine.  His idea might be poor compared to the Lamborghini's of the world, but guess what there's a piece of s**t kia out there that will get me to point a to point b, and for a majority of the population out there that's enough.....

Poor is a strong word though, cause i use said 4 way logic today, and don't see a real problem with.  Will it revolutionize 4-way probably not, but will it get me through a game with pretty good high score, for sure. 

It's no different than business, you guys advertise multiple types of sticks, buttons, switches, etc. to give the population options. If we all looked at the logistics of perfecting one thing then there would be no other options, cause they would be considered too poor to even bother with.

So commend the man for trying instead of blowing his attempt out of the water with science and math, or telling him to give up.....

You know they laughed at Noah  too, and told him not to build the ARK.   Science, math, and testing didn't see the rain coming did it?

Don't hate participate, people....who know what will come of it...   going to timeout now...

I'm sorry that my form of participation is stating my opinion and trying to add to the discussion rather than announcing that my trousers are messed.  The Noah analogy is a nice touch tho.  Next time I'm reading the epic of Gilgamesh I'll be sure and think of this.  I was trying to discuss that the effort may be late as controller choices are quickly adapting to negate the very necessity thereof and was not stating an evaluation of the software performance itself. I am of the opinion that a physical solution will always be superior to an emulated solution but I don't think that point of view is under fire here. 

I also wasn't aware that the current technique being attempted was new... and I'm not entirely sure that's an accurate assessment.  Please don't smite me.   

[RandyT]

I'll use a different word now instead of preference....It's a different option, to some people if it get the job done and your having fun then that's enough....

Finally a statement I can agree with.  If the default 8-way translation methodology in the apps is one which a player is having an awful time with, and they want to try an alternative which isn't already available through customizing the input handling logic (i.e. the AND, OR and NOT combinations) then there's no harm in giving something else a shot.  Most here would recommend foregoing the effort involved and just using the right tool for the job, but it's understandable that some may not have the money or space to do that, or just like tinkering for the sake of tinkering.

There is nothing wrong with presenting options, but presenting them in such a way as to indicate that they solve a problem which they don't really, and cannot possibly solve, is a different situation.

[CheffoJeffo]

I thought he left ... or was being graceful ... or summat like that ... 

I'll use a different word now instead of preference....It's a different option, to some people if it get the job done and your having fun then that's enough....

The bottom line is that, in order to make a decision about options, people need enough facts to make it an informed decision. Just saying an option is available and works for you, without any mention of the potential downfalls, does a disservice, to the option and to the community.

We all get that you think that Degen's solution is good enough. What has been posted are reasons why it may not be the case. I can think of a number of games, just off the top of my head, where his algorithm will be totally wrong, like, say, any game where you can't just switch directions to the cardinal opposite.

What may be more interesting is to have a number of algorithms that can be selected by the user as appropriate to the game being played.

RandyT has just been providing facts that should be considered in making an assessment.

We aren't telling you that you must use the same solution that we chose (or that you are a loser if you don't), but we are telling people what the potential downfalls of the proposed methods are. As RandyT says, this isn't exactly a new problem and I'm not seeing anything here that hasn't been tried before.

 

[Le Chuck]

If you want arcade authentic, you need a rusted joystick that barely works when you push left and a sticky button.

Preferably one that smells like a brewery and is covered in cig burns right?

[degenatrons]

We all get that you think that Degen's solution is good enough. What has been posted are reasons why it may not be the case. I can think of a number of games, just off the top of my head, where his algorithm will be totally wrong, like, say, any game where you can't just switch directions to the cardinal opposite.

What may be more interesting is to have a number of algorithms that can be selected by the user as appropriate to the game being played.

RandyT has just been providing facts that should be considered in making an assessment.

Thanks for your summary.

Exactly what I'm trying to achieve by talking to the arcade community.   If the algorithm doesn't work then it will be dropped from the device.  If it can be improved then it will be improved. 
I have some other ideas,  but for now,  I hardly dare raise them!

I take on board your idea to have algorithms that suit the users play style.  Considered and noted.  Thanks.   

[RandyT]

I have some other ideas,  but for now,  I hardly dare raise them!

There's no reason to feel the need to be reticent.  You could save yourself a lot of time and effort by presenting some of those other ideas to the community for feedback.  This seems to be some new territory for you, and at least a few active members have been wrangling these issues for over a decade.  I think you'll know pretty quickly whether they warrant development, or whether it's something which has been tried and didn't fare so well.

RandyT

[PL1]

I'm all for getting the best known info and ideas out there.  Thanks to those who have been around the block many times and still take the time to set us whippersnappers straight when we start to head down a dead end path.    

I threw my 2 cents in with the "gun" and "car" posts because it seemed that there was some excessive negativity toward Degenatron's encoder, including apparently comparing it with the TOKN encoder -- a matrix encoder designed without the diodes needed to prevent "ghosting" IIRC -- which was clearly proved to be bad despite misleading reviews. (Paraphrasing.  Let me know if I'm off on this.  )



Just trying to keep things positive so prospective innovators don't become gun-shy.  We never know what "crazy" idea will inspire the next amazing development. 

EDIT: D'oh! Deleted misremembered TOKN thread reference.  Sorry, Cheffo.  Time to go pull the plank out of my own eye. 


Scott

[CheffoJeffo]

I threw my 2 cents in with the "gun" and "car" posts because it seemed that there was some excessive negativity toward Degenatron's encoder, including apparently comparing it with the TOKN encoder -- a matrix encoder designed without the diodes needed to prevent "ghosting" IIRC -- which was clearly proved to be bad despite misleading reviews. (Paraphrasing.  Let me know if I'm off on this.  )

To be clear, I was NOT comparing the two encoders in any way or shape (although I now see that the example I used may create that impression).

I was highlighting the similarities between the threads, where Randy posted facts (and things to consider in an encoder) and people took it to be just him attacking a competitor. The same thing happened here -- people took a completely valid list of facts and things to consider and interpreted it as an attack against a new product.

Consider that *I* have no dog in this fight -- I don't sell arcade components and I have never bought anything from Randy (although I keep meaning to grab up a couple of spinners). I agree with pretty much everything Randy said because he is right and because I would hope that, by my chiming in, we could avoid people misconstruing things and see it as a fair and complete representation of the situation.

The more I think about it, the more fun I think it would be to come up with multiple algorithms (despite the fact that I will always go for the best physical option). Something like, say, a dedicated algorithm for  games where movement consists mostly of "rolling" the stick around. If the last position was Up and the current is any of Up/Left, Left, Down/Left, then use Left. I'd need to think about it a bit more, but that strikes me as a better algorithm for maze games, since I would think that 180 degree shifts are less likely to hit the diagonals when you are normally moving in a circle.

[RandyT]

The more I think about it, the more fun I think it would be to come up with multiple algorithms (despite the fact that I will always go for the best physical option). Something like, say, a dedicated algorithm for  games where movement consists mostly of "rolling" the stick around. If the last position was Up and the current is any of Up/Left, Left, Down/Left, then use Left. I'd need to think about it a bit more, but that strikes me as a better algorithm for maze games, since I would think that 180 degree shifts are less likely to hit the diagonals when you are normally moving in a circle.

I'm not sure there are any games where this would help.  The above still has the issue which would send the player right if they drifted off the exact vertical by mistake, something that's all too easy to do without the "notch" to hold the stick.

I've thought about this dilemma for a long time, and I've never been able to find a case where it provides a benefit, without adding an equally unattractive negative impact.  It's like trying to get more than 2 possibilities out of a binary number.  It doesn't work.

[Hoopz]

Just ask X for the right answer. He will have the definitive solution.  I do miss MattP though.  Too bad he deleted his account.

[rablack97]

I'm sorry that my form of participation is stating my opinion and trying to add to the discussion rather than announcing that my trousers are messed.  The Noah analogy is a nice touch tho.  Next time I'm reading the epic of Gilgamesh I'll be sure and think of this.  I was trying to discuss that the effort may be late as controller choices are quickly adapting to negate the very necessity thereof and was not stating an evaluation of the software performance itself. I am of the opinion that a physical solution will always be superior to an emulated solution but I don't think that point of view is under fire here. 

I also wasn't aware that the current technique being attempted was new... and I'm not entirely sure that's an accurate assessment.  Please don't smite me.   

Nobody is smiting you, i was writing my comment before you even posted yours, you just hit post faster than i did.

Why are you stuck on the messed comment....different thread now man, this thread merits some seriousness.

Anywho, i never said he was the innovator of 4-way, RandyT has mentioned this has been tried time and time again throughout the years.

Everyone on this thread has valid points, including yourself.  I'm just saying we shouldn't blow folks attempts out of the water due to our own personal failures or research.

This hobby would be sh*t if everyone listened to the why's or what stuff wont work.  Otherwise as you see earlier people will say F you and take their toys and go home.  The forum then doesn't benefit either way.

We all agree physical restriction is superior, no one has said different....

[mgb]

Just ask X for the right answer. He will have the definitive solution.  I do miss MattP though.  Too bad he deleted his account.

 please don't send that invitation 

[RandyT]

....different thread now man, this thread merits some seriousness.

Ok, in the spirit of being "serious", we should probably take a look at what MAME does in it's code to handle the 8-way to 4-way problem.

Here's the section which is responsible for this;

Code: [Select]

910  void digital_joystick::frame_update()
  911  {
  912      // remember previous state and reset current state
  913      m_previous = m_current;
  914      m_current = 0;
  915 
  916      // read all the associated ports
  917      running_machine *machine = NULL;
  918      for (direction_t direction = JOYDIR_UP; direction < JOYDIR_COUNT; direction++)
  919          if (m_field[direction] != NULL)
  920          {
  921              machine = &m_field[direction]->machine();
  922              if (machine->input().seq_pressed(m_field[direction]->seq(SEQ_TYPE_STANDARD)))
  923                  m_current |= 1 << direction;
  924          }
  925 
  926      // lock out opposing directions (left + right or up + down)
  927      if ((m_current & (UP_BIT | DOWN_BIT)) == (UP_BIT | DOWN_BIT))
  928          m_current &= ~(UP_BIT | DOWN_BIT);
  929      if ((m_current & (LEFT_BIT | RIGHT_BIT)) == (LEFT_BIT | RIGHT_BIT))
  930          m_current &= ~(LEFT_BIT | RIGHT_BIT);
  931 
  932      // only update 4-way case if joystick has moved
  933      if (m_current != m_previous)
  934      {
  935          m_current4way = m_current;
  936 
  937          //
  938          //  If joystick is pointing at a diagonal, acknowledge that the player moved
  939          //  the joystick by favoring a direction change.  This minimizes frustration
  940          //  when using a keyboard for input, and maximizes responsiveness.
  941          //
  942          //  For example, if you are holding "left" then switch to "up" (where both left
  943          //  and up are briefly pressed at the same time), we'll transition immediately
  944          //  to "up."
  945          //
  946          //  Zero any switches that didn't change from the previous to current state.
  947          //
  948          if ((m_current4way & (UP_BIT | DOWN_BIT)) &&
  949              (m_current4way & (LEFT_BIT | RIGHT_BIT)))
  950          {
  951              m_current4way ^= m_current4way & m_previous;
  952          }
  953 
  954          //
  955          //  If we are still pointing at a diagonal, we are in an indeterminant state.
  956          //
  957          //  This could happen if the player moved the joystick from the idle position directly
  958          //  to a diagonal, or from one diagonal directly to an extreme diagonal.
  959          //
  960          //  The chances of this happening with a keyboard are slim, but we still need to
  961          //  constrain this case.
  962          //
  963          //  For now, just resolve randomly.
  964          //
  965          if ((m_current4way & (UP_BIT | DOWN_BIT)) &&
  966              (m_current4way & (LEFT_BIT | RIGHT_BIT)))
  967          {
  968              if (machine->rand() & 1)
  969                  m_current4way &= ~(LEFT_BIT | RIGHT_BIT);
  970              else
  971                  m_current4way &= ~(UP_BIT | DOWN_BIT);
  972          }
  973      }
  974  }

Looking at the comments, you will find that diagonals are already handled very similarly to what is proposed.  Transitions are favored, meaning that if the stick is in the UP position and an adjacent diagonal is made, MAME transitions immediately to the cardinal direction which differs from the current one.  From what was described earlier, no difference here between the two methods, which leave both susceptible to the "user drift" and "extended roll" issues.

If the stick is UP, and goes directly to DOWN-RIGHT, this means that it must necessarily pass through the "idle" position (CENTER.)  In MAME, this creates an "indeterminate state", as the authors understood that there was no way to ascertain what the player's intention was.  The way it is handled by default is to "flip a coin" (randomize) to decide whether to go RIGHT or DOWN.  Passing through CENTER always allows for an indeterminate state, so crossing CENTER directly to a diagonal (meaning closing the contacts on both switches within the 1/60th of a second time frame) causes the "coin flip" decision.

What looks to be the difference in the proposed method is that, instead of the "coin flip", the opposite cardinal is always favored.  This would indicate that the proposed method would necessarily store the last cardinal direction, even when the stick is resting at CENTER, as it must necessarily pass through this state.  In other words, if the current position is LEFT, and the stick returns to CENTER awaiting the next movement, RIGHT becomes heavily weighted, meaning that an UP-RIGHT or DOWN-RIGHT condition will always favor RIGHT.  The problem which arises in this case is that when moving from CENTER to either of those diagonals, there is equal likelihood that the player intended to go DOWN or UP, but will always end up going RIGHT.  This is not an improvement.

The only possible advantage in doing this is tied directly to play style, but it comes at a cost.  A game like Pac-Man or Rally-X has the player in constant motion regardless whether the stick is returned to CENTER or held in a direction.  If the player releases the stick to center after making the movements, the chance of "user drift" is heavily reduced, but no clear advantage can be had from the heavily weighted opposite cardinal.  If the player holds the stick in a direction at all times, there is a possible advantage in the heavily weighted opposite cardinal, but the chance of "user drift" is greatly increased.  This does not indicate a net gain. 

If anyone has anything to add to this, or sees a failing on my part, please chime in.

[rablack97]

ok now that is a kick ass post.....I see your concern with said logic, now somebody with ninja skills might be able to turn this into something useful for the forum....


Thanks for taking the time to write this up RandyT...

 

[MTPPC]

Even the most casual of game players cannot be satisfied with a non-responsive or wrong-responsive controller. As far as I am concerned, I have two mame cabinets: one with an 8-way 6-button and one with a 4-way, 3-button, trackball. When I play pac-man on the 8-way, it always ends in frustration with the machine. When I play pac-man on the 4-way, it always ends with frustration in the player. This will not change based on a slightly more accurate 8-way. I use degentron's encoders for both an 8-way mame and a pinball. I love them, but I can't see how a slight improvement will make that much difference. I think this goes equally for the novice and expert and should in no way be considered an admonishment of the attempt. It is more sadly an admission that the attempt was begun in error.

The truth that matters in this case is the physical/logical limitation of the problem being solved. This problem does not provide enough inputs to get an acceptable output. In fact, the algorithmic estimation of the solution precludes the development of the actual skill that eliminates the problem. IOW, in this case, no solution is the best solution. So yes, people should not waste further time attempting to find an algorithmic solution to this problem. The inputs do not provide enough information to provide an accurate output. And any calculated output reduces the feedback required to learn to run the joystick with the accuracy required to prevent the problem in the first place.

[paigeoliver]

I wonder when that code went into mame? It wasn't all that long ago that mame was plain wrong about which games had 4-ways and which one had 8-ways for a huge number of games.