Thanks for that detail. That does clear up some things for me. Yeah, so that opens up a whole bag of questions doesn't it? :->
You stated:
Quote:
PORT_BIT( 0xff, 0x7f, IPT_AD_STICK_X )
mask = 0xff (0-255), default value = 0x7f (127), and the input type is analog stick, X axis. The default value is the game's "center".
The mask of 0xff implies a range of values of 0 through 255 as you said, but that implies the port that the ROM code sees is really an 8-bit unsigned integer (i.e., one byte). The values I see reported by my jstest output (the utility on Debian Linux to see the output reported by joysticks) seem to be 16-bit signed integer values spanning from a min of -32767 to 32767, not 0 through 255 (shown below is the left joystick begin held all the way to the right (Axis 0)):
brentg@hungover:~/sdlmame/sdlmame0128u1/src/mame/drivers$ sudo jstest /dev/input/js0
Driver version is 2.1.0.
Joystick (Logitech Logitech Cordless RumblePad 2) has 6 axes (X, Y, Z, Rz, Hat0X, Hat0Y)
and 12 buttons (BtnX, BtnY, BtnZ, BtnTL, BtnTR, BtnTL2, BtnTR2, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR).
Testing ... (interrupt to exit)
Axes: 0: 32767 1: 0 2: 0 3: 0 4: 0 5: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off
Could it be that MAME is somehow (and if so where?) translating the range of operating-system-provided joystick values from [-32767..+32767] to [0..255], thus loosing some precision along the way, or bumbling it up, or loosing a bit or two (or conversely, the ROM having a similar bug)? Your answer to this question will help me understand the expected behavior of the code when I start instrumenting it. And it will help me understand the "glitchy" values when I see them.
About the READ16_HANDLER macro
Is that "16" in that macro name of "READ16_HANDLER" meaning 16 bits of NVRAM are being read? That seems to confuse me a bit given the port description mask implying 8-bits (0..255):
static READ16_HANDLER( analog_r )
{
static const char *const portnames[] = { "STICK0_X", "STICK1_X", "STICK0_Y", "STICK1_Y" };
return input_port_read(machine, portnames[whichport]);
}
About autocenter speed:
Quote:
Notice that autocenter speed isn't set in this define, so mame sets it to the same value. Autocenter speed is like keydelta, but is the speed mame returns the value to center when the digital input is released.
Can you clarify where the autocenter speed is set in this driver? Or, is it not explicitly set, and therefore, some global default comes into play? Since I am focused on the behavior when the joystick is let go, perhaps the logic that moves back to center via the autocenter value is not quite right (or the Food Fight ROM is reacting to it with adverse results)?
About your deadzone suggestion:
As for this:
Quote:
Okay, something you might want to try: for playing with your analog stick, decrease mame's deadzone to 5% or even 1% (0.05 or 0.01). I'm assuming your joystick driver doesn't have it's own deadzone, and that the stick is decent quality. Might help with looking needing less movement, but depends on the original code.
Let's assume the joystick driver does not in fact have its own deadzone (I wouldn't know where to look in the Linux joystick driver code as of yet, anyhow). Ignorance is bliss on that front, and I hope/pray that is not necessary.
Note that in my previous post to the SDLMAME forum, I had experimented with the deadzone, and had concluded that increasing its value made the two abberant behaviors worse. But, that was: (a) before I was informed about the possible accumulating and possibly changing behavior as due to state stored in the NVRAM file between MAME sessions, and (b) before the idea that the ROM code is trying to autocalibrate as game play progresses (thanks to MAMEBase's reference to the Food Fight Operations Manual), and of course (c) that was increasing the deadzone, not decreasing it as you suggested. And so one or more of those things could have confused my reasoning at that time.
So, another swipe at the deadzone is in order for completeness, or elimination of it as a key factor. Here are my test results below. Note that starting at Test #5, I am reusing the last foodf.nv file from the last game I played in the experiments I did for the response to MAMEBase (Post #169985), and that means storing it into foodf.nv for each of the subsequent tests versus reusing the one that might have been updated from the n-1 test:
- Test #1: Using unspecified and assumed default deadzone of 0.3 (30%) and no .nv file at startup: No surprise here. Same auto calibration behavior, eventually ending up with the consistent looking-to-the-right-behavior I described in Post #169985.
- Test #2: Changing deadzone to 0.05 (5%) and no .nv file at startup: Same result as in Test #1.
- Test #3: Changing deadzone to 0.03 (3%) and no .nv file at startup: Noticed that it took a bit longer for it to auto calibrate. At early stages, trying to move to the left just wouldn't move, but strangly, I could move up and to the left (i.e., diagonally) just fine. Eventually moving to the left "unstuck" and I could move around. In the end, I ended up with the consistent looking-to-the-right-behavior I saw in Test #1.
- Test #4: Changing deadzone to 0.01 (1%) and no .nv file at startup: Same as for Test #3.
- Test #5: Changing deadzone to 0.05 (1%) but re-initializing from a known .nv file at startup: I once saw the looking down and to the right condition when stopped, but after that one occurance, I ended up with the consistent looking-to-the-right-behavior I saw in Test #1.
- Test #6: Changing deadzone to 0.03 (1%) but re-initializing from a known .nv file at startup: Same result as in Test #5.
- Test #7: Changing deadzone to 0.01 (1%) but re-initializing from a known .nv file at startup: Same result as in Test #5.
Thanks for your patience. I think I am investing way to much of my time and yours in this, so at some point I'm going to stop torturing you with pesky questions and just give up on it.
bgoodr
My name is ${SLICK_TALKING_POLITICIAN}, and I endorsed this message.
|
Index 
Flat 
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
Reply
