MAMEWorld Forums - Programming - Re: Food Fight Rev 3 looking or walking to the right when not touching joystick

> 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