|
Food Fight Rev 3 looking or walking to the right when not touching joystick
#169891 - 10/31/08 06:12 AM
|
|
|
I'm playing "Food Fight (Rev. 3)" (foodf.zip) using SDLMAME 128u1. I played the original game while a teenager in the 1980's, and was happy to find that I could dork around playing this game again. But, I discovered two annoying problems with that game I am unable to resolve, and would like some tips or help on the matter. Here are the two annoying behaviors I see:
- When the game is first initialized, and I begin playing using the joystick (a Logitech Cordless RumblePad 2), and then let go of the joystick, the character moves to the right as if the joystick is pressed to the right. This continues from game to game within the same MAME session, until for some unknown reason, it stops this behavior, which leads me to the second mode of behavior.
- The second mode of behavior is similar to the first above, but instead of moving to the right when I let go of the joystick, he just looks to the right without moving.
Both of these conditions really hampers game play. The first one is a bit more severe than the second, as it means I can't really pause and have to keep moving. The second hampers a main strategy I could use on the real machine: I need to rotate the character around without moving very far from the spot containing the fruit items to throw, so that I can repeatedly pick up bits of food, aim, and then fire, thus racking up points. This issue is most frustrating on those levels of the game containing watermelons which offer an inexhaustable supply, unlike bananas, parsley (don't ask), etc., but since I can't stay on the melon, I get to die quickly. <sniff> 
When I approached the people on the SDLMAME forums, I was thinking that this problem was due to misconfiguration or a bad joystick. The helpful folks at the SDLMAME forum helped me work through the obvious questions about a bad joystick, and eliminated that possibility. Reference the long post at Logitech Cordless RumplePad 2 stuck to the right for more background and detail. You will note from that forum posting that others see similar behavior, even on a completely different OS, leading me to wonder if this is a bug in the ROM or a bug in input handling in the underlying MAME that SDLMAME builds upon.
All of that was leadup to ask these questions:
- Did the original Food Fight game suffer from this flaw? I'm hoping someone that reads these posts has access to the real game and can check out what really happens when they let go of the joystick: Does it spring back, and if so, which direction does Charlie Chuck look? I would expect him to stay looking in the same direction in which he is walking. Also, can you stay mostly put by moving the joystick around in a circle?
- Related to the above, is the original Food Fight joystick of the spring-back kind, or was it one of those that just flops around (like the flimsy plastic kind that came with the Tandy (Radio Shack) Color Computer)?
- Can someone point me to some info on how the values produced from this joystick are mapped into values the Food Fight ROM expects? Specifically, where in the MAME code is that translation done? I would want to instrument the code with additional diagnostics (printf's, or equivalent MAME-specific data dumping macros) to monitor: (a) what MAME sees from the OS's joystick device (On Linux, this would be from the /dev/input/js0 device file) as compared to (b) what it stuffs into the ROM's RAM for it to monitor?
Any help you can provide is greatly appreciated. I really like MAME and would like to continue to use it to play this little Food Fight game again!
Thanks,
bgoodr
|
My name is ${SLICK_TALKING_POLITICIAN}, and I endorsed this message.
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: bgoodr]
#169954 - 10/31/08 09:16 PM
|
|
|
> I'm playing "Food Fight (Rev. 3)" (foodf.zip) using SDLMAME 128u1.... Reference the long
> post at Logitech Cordless RumplePad 2 stuck to the right for more background and detail...
Interesting read, and good, complete testing.
I can help on how mame works (question 3). If you look at the source foodf driver (src/mame/drivers/foodf.c), the inputs are defined (lines ~260-300), and the inputs are read (lines ~195-205). It looks like mame just passes the 0-255 values to the game without any changes. More info on the port defines in src/emu/inptport.h (~690-805 mostly), and src/emu/inptport.c (~2400-3000 for decoding the tokens).
In short, foodf's define goes like this: PORT_BIT( 0xff, 0x7f, IPT_AD_STICK_X ) PORT_SENSITIVITY(100) PORT_KEYDELTA(10) PORT_REVERSE PORT_PLAYER(1)
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".
PORT_SENSITIVITY(100)
100% analog sensitivity set as default for this port. Can be changed in game tab "Analog Controls", just like the others below.
PORT_KEYDELTA(10)
Sets speed a digital input is translated into an analog value for the game when digital input is pressed. This is why the keyboard input wasn't instant you mentioned in your prior thread. The number sets the change to 10 (in the 0-255 range defined earlier) per frame. 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.
PORT_REVERSE
Reverses the analog values just before sending to game. Usually, left is min, right is max. When reversed, right is min, left is max.
----------
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.
|
Robin
www.urebelscum.speedhost.com/ or
www.angelfire.com/retro/u_rebelscum or
rain.prohosting.com/urebel
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: bgoodr]
#169985 - 11/01/08 02:51 AM
|
|
|
And I can answer question #2
The original Food Fight Joystick was, in fact, a spring loaded, rerturn to center stick.
Detailed drawings are available as part of te Operations Manual (available at http://www.tamdb.net/index.php?page=Manuals&lettre=F)
Hope this helps!
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: MAMEBase]
#169998 - 11/01/08 08:06 AM
|
|
|
Thanks MAMEBase!
Quote:
Detailed drawings are available as part of te Operations
Manual (available at
http://www.tamdb.net/index.php?page=Manuals&lettre=F)
That does help a bit. I noticed the following on PDF page 18 (physical page 2-3) of the second printing of the Food Fight Operators Manual:
Quote:
Food Fight is equipped with a self-calibrating joystick, which
checks its maximum and minimum values while the game is being
played. Initial values are set at the factory and stored in
NVRAM. When Food Fight is turned off, the NVRAM values are
updated. Each time Food Fight is turned on, the current values are
read out of NVRAM. If NVRAM fails (see the description under Automatic
Self-Test), then the joystick is recalibrated as the game is being
played. In this case, the control will be sluggish for the first game
or two aafter the game is turned on.
That may explain the changing behavior over time. I suspect if I do not remove the Food Fight NVRAM file each and every time I run, then the behavior will start out initially in running-to-the-right-when-joystick-is-let-go mode of behavior, but eventually switch over into the less severe looking-to-the-right-when-joystick-is-let-go mode of behavior (this is actually what I verified happens; see test run below).
So, to prove this is happening, I ran a few experiments as follows:
- Game #1: No .nv file: Moved to the left, let go, and the character moved to the right. I moved up/left and then down/left to avoid touching the other characters and then let go, and then the character stopped and looked right but did not move to the right. I then died. Upon the second sequence (same game) I tried moving out to the left and it became sluggish and it seemed as if the left joystick would not even move to the left, and I died again. On the third frame after dieing, I saw the beginnings of the same behavior where I could not move to the left but then kept at it, moving around in a wide circle and then the ability to move left came back again. I went to the next level and was seemingly able to move around without harm, but then forgot that I didn't have a throw button configured on the joystick buttons and promptly died again.
- Game #2: Same MAME process: A new game started, same MAME process. I moved up and around and then let go of the joystick. The character looked down this time. I moved around a bit more and died. Upon the second play, I tried moving around in random directions, avoiding the persistent Chefs, and stopped frequently, and this time consistently saw the looking-to-the-right-when-still behavior.
- Game #3: Same MAME process: Started new game, same MAME session. Moved to the left and let go, and the character looked to the right. Repeated that same maneuver again, and again the character looked to the right. Had to avoid a Chef, so moved straight up and then let go and this time he looked downward and to the right, but not straight right. And then the Chef caught up to me and I died. On the next screen of this same game, the character started out looking downward and to the right. I moved the joystick and let go, and same thing: looking downward and to the right. and then I died. Upon the next screen, I tried again, and got the same thing, then moved up, then up/left, then left, and then left/down, and then let go of the joystick, and then the character looked right (not down/right this time). I then exited the MAME process entirely.
- Game #4: New MAME process, same .nv file as previous games above: This time I tried moving in all sorts of directions, but every single time when I stopped, the character consistently looked to the right.
I think that pretty much proves that the NVRAM file is recording calibration state. Now, could that calibration state that is stored in the NVRAM somehow dictate that the character end up always looking to the right when stopped? I don't think so, but I don't have any hard facts to back up that claim.
|
My name is ${SLICK_TALKING_POLITICIAN}, and I endorsed this message.
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: uRebelScum]
#170001 - 11/01/08 09:00 AM
|
|
|
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.
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: bgoodr]
#170230 - 11/03/08 11:18 PM
|
|
|
Don't give up just yet!
Extensive testing seems to indicate that this is a legitimate bug, and as such, it should be reported, and addressed,
The next step would appear to be having the bug confirmed by someone with an 'official' (Non SDL) version of MAME, and submit a bug report to MAMETesters.
It is unfortunate, in some respects, that no other games are included in the Food Fight driver, because finding other games for comparison purposes seems meaningless (I have been unable to find a similar problem in games like Road Runner, or Escape From the Planet of the Robot Monsters, both of which feature a return to center, analog stick).
This leads me to believe that the problem is in the driver, and not in the joystick system.
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: bgoodr]
#170238 - 11/04/08 01:45 AM
|
|
|
> 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? :->
>
> ... 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....
>
> 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.
Heh, opens up questions is right. 
Sort of. Mame takes OS dependent input, be it windows & directX or linux & sdl, at whatever range that OS & api run at. Then it translates that info into mame's internal data with it's own range (~17 bits, more info in src/emu/inptport.c first comment section). And then translates that into the game's range (in this case, 8 bits). I doubt the shifting ranges would be the cause, but it's possible.
> 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):...
Err, I'm not as versed in the memory emu part, but... NVRAM is Non Volatile RAM, and it's part of what's being emulated. The READ & WRITE macros are like the ROM reading or writing to its I/O or RAM memory. So the READ16 is reading the input from mame's internal storage and putting it where the original game held the inputs (drivers/foodf.c, line 239). Yes, the READ16 means 16 bits are read, but in mame it looks like the upper 8 bits are not touched by the analog inputs. (Not sure, but see last suggestion at end of post, maybe.)
> About autocenter speed:
>
> 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)?
If autocenter is not explicitly set, then it's the same as the digitalspeed by default. It's done in the core part of mame, src/emu/inptport.c, lines 2714 - 2737. Notice how keydelta (aka digitalspeed) also sets the centerspeed ()line 2724)?
You can change them differently in the analog controls UI menu, of course.
One thing you might want to do (with all analog stick games) is set autocenter really high (and deadzone small). Mame autocenters only when that axis is centered; if the game is getting any non-center value (ie: anything outside the deadzone), mame will use that exact value instantly. By decreasing the deadzone, mame will rarely autocenter, but will quickly when the stick is centered if the autocenter speed is high.
However, even with defaults (30% DZ, 10 AC) 30% of 128 is ~38, so mame will autocenter within 4 or 5 frames (1/15 or 1/12 of a sec), assuming the stick is polled close to the deadzone edge the frame before entering the deadzone.
> About your deadzone suggestion:... decrease mame's deadzone....
>
> Let's assume the joystick driver does not in fact have its own deadzone.
Yup assuming that, or that the driver deadzone is smaller that 30% (which is a big deadzone for most analog games, IMO).
I was hoping the smaller deadzone would help with the "looking not moving" being easier to direction with small stick movements or, better, calibrated into the play (see above). Looks not.  Great testing BTW.
Starwars is another game that calibrates as you play (I thought this was a BTNAB, but can't find it?). You can see how the "centered" crosshairs changes in the select screen (more toward center the more the is used in it's full range). With SW in mind, and the test results you did:
does moving around the right side more (to "over-equal weight calibrate"  ) help?
Does moving the stick after the game loads but before you put in the first coin, have the same effect as moving the stick after starting a game? (It helps in SW.)
What about "720"ing a whole lot?
How about if you compile your own mame, with the default value 0x80 instead of 0x7f? (Since the axis is reversed, lower is righter.)
Heck, what about changing the mask to 0xffff and the default value to 0x7fff? (Might break emulation if more going on than I know.)
|
Robin
www.urebelscum.speedhost.com/ or
www.angelfire.com/retro/u_rebelscum or
rain.prohosting.com/urebel
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: uRebelScum]
#170300 - 11/04/08 07:10 PM
|
|
|
All of that is good info, that I'll have to take time to ponder
through and try to understand, along with reading through your source
code references.
What does OSD (or OSD layer) stand for (top of src/emu/inptport.c)?
Hmmm, after reading through your post about 3 times, I think I will
remain confused by any further testing or experimentation unless I
have playback and record working in the Food Fight driver. Once I can
replay the game with repeatable joystick and keyboard inputs, I could
combine that with slowing the emulation down (I believe there is a
command line option to do that). Once that is working, I could then
inject printfs or other forms of instrumentation at appropriate spots
to monitor how mame is processing the various states and settings, and
figure out how they are interacting for this specific driver.
What games implement the playback/record interface that I could use an
example of the changes I need to make for the foodf driver?
Additional questions:
What is a "BTNAB"?
What does "over-equal weight calibrate" mean?
(Ummm, introducing testing of a different game (Star Wars) I think will
just confuse me even more by opening up a bigger can of worms.)
What does '"720"ing a whole lot' mean?
I'm not going to do this quite yet:
> How about if you compile your own mame, with the default value 0x80 instead of 0x7f?
Because that will start changing values before I understand them, but
getting playback/record working for Food Fight will allow me to come
back and experiment with those values after I fully understand what
they do.
> If autocenter is not explicitly set, then it's the same as the
> digitalspeed by default. It's done in the core part of mame,
> src/emu/inptport.c, lines 2714 - 2737. Notice how keydelta (aka
> digitalspeed) also sets the centerspeed ()line 2724)?
Are you refering to these lines:
Code:
2714: /* analog keyboard delta */
2715: case INPUT_TOKEN_KEYDELTA:
2716: TOKEN_UNGET_UINT32(ipt);
2717: if (curfield == NULL)
2718: {
2719: error_buf_append(errorbuf, errorbuflen, "INPUT_TOKEN_KEYDELTA encountered with no active field\n");
2720: TOKEN_SKIP_UINT32(ipt);
2721: break;
2722: }
2723: TOKEN_GET_UINT32_UNPACK2(ipt, entrytype, 8, curfield->delta, -24);
2724: curfield->centerdelta = curfield->delta;
2725: break;
2726:
2727: /* analog autocenter delta */
2728: case INPUT_TOKEN_CENTERDELTA:
2729: TOKEN_UNGET_UINT32(ipt);
2730: if (curfield == NULL)
2731: {
2732: error_buf_append(errorbuf, errorbuflen, "INPUT_TOKEN_CENTERDELTA encountered with no active field\n");
2733: TOKEN_SKIP_UINT32(ipt);
2734: break;
2735: }
2736: TOKEN_GET_UINT32_UNPACK2(ipt, entrytype, 8, curfield->centerdelta, -24);
2737: break;
2738:
If so, then why "analog keyboard delta" in the comment at line 2714?
I have a digital joystick, so why is analog keyboard involved?
Perhaps I'm not viewing the same copy of the code you are viewing? If
so, then perhaps I'm not using the latest code, and you are? How do
we arrange to view the same code? I'd be willing to check out
differently from CVS or whatever is being used, but all I could find
for SDLMAME was a tarball.
Thanks!
|
My name is ${SLICK_TALKING_POLITICIAN}, and I endorsed this message.
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: MAMEBase]
#170302 - 11/04/08 07:14 PM
|
|
|
> Don't give up just yet!
Giving up will of course have to happen if folks get tired of my endless stream of questions. My apologies!
> This leads me to believe that the problem is in the driver, and not in the joystick
> system.
I agree, but I will have to understand a bit of the core and it relates to the driver to know for sure.
Adding playback/record capability into the Food Fight driver should enable non-SDLMAME users to compare their results with my results, otherwise I bet it will be intractably complex problem.
bgoodr
|
My name is ${SLICK_TALKING_POLITICIAN}, and I endorsed this message.
|
|
Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: bgoodr]
#170305 - 11/04/08 07:51 PM
|
|
|
> What does OSD (or OSD layer) stand for (top of src/emu/inptport.c)?
Normally On-screen display, but in the MAME universe it means OS-Dependent. Basically all it takes to write a port of MAME is wrap the MAME video/audio/input framework to your OS (say for Windows, DirectX and Win32). Details in http://mamedev.org/source/src/osd/
> What is a "BTNAB"?
A Bug That's Not A Bug - basically, a bug present in the original game, or something that is actually by design in the game. Pluralized as Bugs That Aren't Bugs. You can find a list here: http://mametesters.org/mantis/search.php...de_status_id=-2
Although it is somewhat incomplete, leaving other categories out. I can't recall the origins of the phrase, but it's tied to MAMETesters.org.
> What does "over-equal weight calibrate" mean?
He made up a phrase. He's saying that on some games that have self-calibration routines, moving the joystick mostly on one side would skew the calibration results.
> What does '"720"ing a whole lot' mean?
I think he's saying if you spin the joystick through its axis of rotation multiple times before you push start, or before you insert a credit, does it make a difference to your ability to control the game, in case the game has some sort of self-calibration code.
(I don't think it will, in your other thread you mention the game has a joystick calibration menu in the Test menu). But I'm sure he'll be replying soon.
- Stiletto
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: Stiletto]
#170306 - 11/04/08 08:39 PM
|
|
|
Ok I was experimenting with this game for some time now.
Using keyboard as AD_Stick:
You will always look to the right cause 0-255 does not have a perfect middle. 7f or 127 is not a perfect middle. 127.5 would be it. That's why looking always to the right because autocentering is always to 7f. Using 80 will cause looking always to the left.
The original joystick is analog with springs for autocentering but there is a great deadzone programmed in the game for it. So letting your hand off of the joystick you will be looking in the direction where you have last pushed it. (Tested it with a mouse pushing it far enough that your character starts running in one direction and pulling the mouse a little back so your character stops running; looking in the test menu shows a decent percentage for the 8bit code, this is the deadzone)
Using a keyboard in mame for this game and games like that mame needs a deadzone for keyboard digital to analog.
Using a joystick:
sorry can't try it, but using one as ad_stick no matter if it is analog or digital would give you the opportunity to use the joystick deadzone in the mame.ini
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: Stiletto]
#170308 - 11/04/08 09:45 PM
|
|
|
> ...But I'm sure he'll be replying soon.
Confirmed. Just a more details:
"Over-equal weight calibrate" is a play on words, in the line of "Everyone's equal, just some are more equal than overs." The OP tested the game's calibration by moving mostly left and up/down with a visible effect. And I've had other games/apps where the fix for off calibration was counter-intuitive: move the stick/mouse toward the direction it was off (example, starwars in mame).
"720" was a refferance to the game 720 (skate or die), and its controller that looked like a joystick that could only be moved in a circle along the edge. Moving the analog joystick like this three or four times helps starwars calibrate really quickly.
I really suggest looking at starwars, if only to visibly see a game autocalibrate. Don't worry about the driver or anything, just start SW and without moving stick, start a game. Note where the crosshairs start on the select level screen. Do a quick 360 with the stick and let go. Note how the crosshairs have moved more toward the center? Repeat a few times (don't worry about playing, not like you're losing money). Try exiting/restarting SW, and moving the stick just on the left or right half and how that effects the autocalibration. Considering SW and FF are both from Atari and released one year apart, they might share some calibration code. And SW you can see exactly how the "center" moves, while FF you can see hints on what's going on. Note that it seems like SW does NOT use NVRAM to store autocalibration info, so all you have to do to "start over" with calibration is exit and restart SW, or even just press F3 (emulated reboot).
However, adding playback and savestate would be great for this and other debugging. 
> Are you refering to these lines:
>
> 2714: /* analog keyboard delta */
> ...
> If so, then why "analog keyboard delta" in the comment at line 2714?
> I have a digital joystick, so why is analog keyboard involved?
There's some history here. Mame used to treat keyboard and joystick inputs differently, and this option used to be called IIRC, -keyspeed & -keydelta. However, since I've been following mame (0.37u13), this delta/speed setting effected both keyboard and digital joysticks inputs. So semi-recently the UI name (what the user sees in the menu) was changed to a more accurate "digital speed", but the internal names didn't. (Maybe they should for clearer code.)
So be assured that this effects the digital to analog simulation of all digital devices, be it keyboard or digital joystick, on all games' analog inputs. And, as I said in prior post, its related autocenterspeed does effect analog joysticks too, when an analog joystick axis centers (or goes into the deadzone).
BTW, for some reason I thought you were mostly using an analog joystick? (and doing side testing with a digital stick?)
Anyway, yes that's the code I was referring to. SDL derivative has very few changes from official vanilla mame, all in the OSD (OS Dependent) code AFAIK. If you want quick view of a single source file, both mameDev and MAWS have online access to the up to date code. (MameDev's is color coded for easier read, IMO.)
|
Robin
www.urebelscum.speedhost.com/ or
www.angelfire.com/retro/u_rebelscum or
rain.prohosting.com/urebel
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: Canim]
#170309 - 11/04/08 10:13 PM
|
|
|
> You will always look to the right cause 0-255 does not have a perfect middle. 7f or
> 127 is not a perfect middle. 127.5 would be it. That's why looking always to the
> right because autocentering is always to 7f. Using 80 will cause looking always to
> the left.
Theory or did you change the default? (Can't test at work , but will try tonight.)
> The original joystick is analog with springs for autocentering but there is a great
> deadzone programmed in the game for it.
Err, I wouldn't call that deadzone. If you move the mouse around in that short range, the eyes follow. And since the throw follows where you're looking, that's not dead in game play. To me it seems the game's deadzone, zone where moving the stick has zero effect on the game, is very small if existing at all. I'd say FF has three zones: movezone, lookzone, and centerzone. The last might not exist, if 7f is look right and 80 is look left.
Even if we call the "lookzone" a type of deadzone, mame's deadzone is very different. In mame's deadzone, moving the joystick doesn't change what value mame sends the game. Within mame's deadzone, mame sends the game default values (well, after it centers them at the autocenterspeed).
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: uRebelScum]
#170311 - 11/04/08 10:59 PM
|
|
|
> > You will always look to the right cause 0-255 does not have a perfect middle. 7f or
> > 127 is not a perfect middle. 127.5 would be it. That's why looking always to the
> > right because autocentering is always to 7f. Using 80 will cause looking always to
> > the left.
>
> Theory or did you change the default? (Can't test at work , but will try tonight.)
>
That's not a theory.
> > The original joystick is analog with springs for autocentering but there is a great
> > deadzone programmed in the game for it.
>
> Err, I wouldn't call that deadzone. If you move the mouse around in that short range,
> the eyes follow. And since the throw follows where you're looking, that's not dead in
> game play. To me it seems the game's deadzone, zone where moving the stick has zero
> effect on the game, is very small if existing at all. I'd say FF has three zones:
> movezone, lookzone, and centerzone. The last might not exist, if 7f is look right and
> 80 is look left.
>
> Even if we call the "lookzone" a type of deadzone, mame's deadzone is very different.
> In mame's deadzone, moving the joystick doesn't change what value mame sends the
> game. Within mame's deadzone, mame sends the game default values (well, after it
> centers them at the autocenterspeed).
You are right about that Eyeroll-Zone. Technically the 7f-80 should be a dead zone, so that turning around does not occur.
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: Canim]
#170666 - 11/08/08 02:24 AM
|
|
|
> That's not a theory.
True  , I should have asked:
"Does this mathematical fact apply to this game, or did the game code around it?"
Example, the game might have defined 127 or 128 as the center in the code logic (such as "if value is greater than 127 else if less than 127"). Or the game might be coded as if instead of 0-255, the range was 1-255 making 128 the mathematical center. OTOH, the game could have used the fact and have 127 as look right, and 128 as look left.
Either way, why is the character looking only right, and not down/right? (Both axes are reversed, so unlike most games, right and down are the lower numbers, and mame has both centering at 127.)
> You are right about that Eyeroll-Zone. Technically the 7f-80 should be a dead zone,
> so that turning around does not occur.
Yeah, if there's any deadzone at all. Since the original game had analog sticks, probably with flaky atari POTs and flaky variable centers anyway, the coders might have expected the player to lightly press (within the lookzone) in the direction he wanted to throw, and so coded no deadzone and thus not coded to continue looking the last direction before entering the (non-existing) deadzone. Which goes back to the "general rule vs game specific" of "what is center?"
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: uRebelScum]
#170708 - 11/08/08 08:51 PM
|
|
|
> Either way, why is the character looking only right, and not down/right? (Both axes
> are reversed, so unlike most games, right and down are the lower numbers, and mame
> has both centering at 127.)
That's easy, should it be .
The diffrence between left right makes the character turn around, but up down looking for just a little bit isn't really noticeable.
127-128 looking up down is perhaps just one pixel diffrence on the screen.
See ya, just so easy .
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: bgoodr]
#170714 - 11/08/08 11:53 PM
|
|
|
> Adding playback/record capability into the Food Fight driver should enable
> non-SDLMAME users to compare their results with my results, otherwise I bet it will
> be intractably complex problem.
It is not a hard problem to reproduce though.
It's either:
1. a bug in the original game
2. the game detects a centered joystick differently to how it reads the position.
3. something weird.
the only way to track it down is either by running tests on an original food fight game or trace through the game code ( or both ).
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: ]
#170820 - 11/10/08 05:05 AM
|
|
|
> the only way to track it down is either by running tests on an original food fight
> game or trace through the game code ( or both ).
Well, tracing is my only option, seeing as how no one has replied with something akin to: "Oh, I have the real Food Fight console in my basement, let me go and check its behavior. Be right back ...".
Frankly, I really have no desire to learn the assembler instruction set for that old game and was hoping "tracing" meant of the driver code, adding a few printfs basically and looking at expected values.
However, the discussion of deadzones, lookzones, speeds, etc., without some way of seeing what the game ROM code is doing relative to the inputs coming from my digital joystick, albeit slowed down a lot, is going to be very well beyond my comprehension. I feel very comfortable with C/C++, but old "outdated" assembler instruction sets, ummm, that's a no It just feels just too much like work.
Thanks for everyones input. I'll keep up on the thread in case someone has any new insights.
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: bgoodr]
#172661 - 11/27/08 03:24 AM
|
|
|
I've submitted a bug report to MAME Testers, referencing the testing you've done, and the bug is currently listed as 'confirmed'.
With any luck, someone will be looking into this, and we may see a resolution sometime soon...:)
|
|
|
|
Re: Food Fight Rev 3 looking or walking to the right when not touching joystick
[Re: MAMEBase]
#172708 - 11/27/08 09:44 PM
|
|
|
Thanks. I'll test out any patches that anyone submits to this thread.
|
|
|
|
Index 
Threaded 
Food Fight Rev 3 looking or walking to the right when not touching joystick
Reply
[Re: 
Great testing BTW.
) help? 
, I should have asked: 