Main > Main Forum
MAME - 4-way emulation
RandyT:
--- Quote from: CheffoJeffo on October 19, 2012, 06:49:18 pm ---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.
--- End quote ---
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:
--- Quote from: Le Chuck on October 19, 2012, 04:36:40 pm ---
--- Quote from: rablack97 on October 19, 2012, 04:12:34 pm ---
--- End quote ---
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.
--- End quote ---
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:
--- Quote from: Hoopz on October 19, 2012, 07:09:50 pm ---Just ask X for the right answer. He will have the definitive solution. I do miss MattP though. Too bad he deleted his account.
--- End quote ---
please don't send that invitation :D
RandyT:
--- Quote from: rablack97 on October 19, 2012, 10:55:17 pm ---....different thread now man, this thread merits some seriousness.
--- End quote ---
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: ---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 }
--- End code ---
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.