Food Fight - joystick troubles, solved
-
@grant2258 if I change the code to use the counter even after calibration I get issues. He moves diagonals slowly and looks choppy. Then when exiting and re-entering the emulator he doesn't stop moving. If I don't use the counter it's fine just sometimes stops linear instead of diagonal.
-
Well i would suggest you delete your foodf nvram and cfg files since the input ports where added and it was save before that. Ive only tested on a windows machine will compile on pi and test it in my barcade. And be sure to have your cheat ports on.
-
it works for me like this instead
static READ16_HANDLER( analog_r ) { #define max 255 #define cent 128 #define bump 51; #define up 1 #define down 2 #define left 4 #define right 8 static INT16 xvalue = 0x80; static INT16 yvalue = 0x80; static INT16 currentx = 0x80; static INT16 currenty = 0x80; static INT16 center = 0; static INT16 counter = 0; int temp; UINT16 direction; if( options.cheat_input_ports) // use cheat ports { if(whichport == 0 || whichport ==2) direction = readinputport(6); if (counter == 8) { temp = direction & ~16; if ( temp == 0 ) center =1; else if ( temp == up ) { center=0; xvalue = cent; yvalue = max; currentx=cent; currenty= cent+bump; } else if ( temp == down ) { center=0; xvalue = cent; yvalue = 0; currentx=cent; currenty= cent-bump; } else if ( temp == left ) { center=0; xvalue = max; yvalue = cent; currentx=cent+bump; currenty= cent; } else if ( temp == right ) { center=0; xvalue = 0; yvalue = cent; currentx=cent-bump; currenty= cent; } else if ( temp == right+up ) { center=0; xvalue = 0; yvalue = max; currentx=cent-bump; currenty= cent+bump; } else if ( temp == right+down ) { center=0; xvalue = 0; yvalue = 0; currentx=cent-bump; currenty= cent-bump; } else if ( temp == left+up ) { center=0; xvalue = max; yvalue = max; currentx=cent+bump; currenty= cent+bump; } else if ( temp == left+down ) { center=0; xvalue = max; yvalue = 0; currentx=cent+bump; currenty= cent-bump; } else log_cb(RETRO_LOG_INFO, LOGPRE "unhandled condition %d\n",temp); counter = 0; } else counter++; if (whichport == 0) { if (center) return currentx; return xvalue; } else if (whichport == 2) { if (center) return currenty; return yvalue; } } else // use original inputs return readinputport(whichport); } -
ok just put the counter in if your horizontals arent sticking havent tested it on the pie yet just on a windows box will let you know how i get on. I have a few other things in tinkering with havent spent a great deal of time on this
-
@grant2258 the counter is in, I just moved where it is so direction is always defined on each read but the position is not updated unless it's on the right count.
We could probably initialize direction normally this way too instead of undefined and remove the if statement
Like this
static READ16_HANDLER( analog_r ) { #define max 255 #define cent 128 #define bump 51; #define up 1 #define down 2 #define left 4 #define right 8 static INT16 xvalue = 0x80; static INT16 yvalue = 0x80; static INT16 currentx = 0x80; static INT16 currenty = 0x80; static INT16 center = 0; static INT16 counter = 0; static INT16 direction = readinputport(6); int temp; if( options.cheat_input_ports) // use cheat ports { if (counter == 8) { direction = readinputport(6); temp = direction & ~16; counter = 0; if ( temp == 0 ) center =1; else if ( temp == up ) { center=0; xvalue = cent; yvalue = max; currentx=cent; currenty= cent+bump; } else if ( temp == down ) { center=0; xvalue = cent; yvalue = 0; currentx=cent; currenty= cent-bump; } else if ( temp == left ) { center=0; xvalue = max; yvalue = cent; currentx=cent+bump; currenty= cent; } else if ( temp == right ) { center=0; xvalue = 0; yvalue = cent; currentx=cent-bump; currenty= cent; } else if ( temp == right+up ) { center=0; xvalue = 0; yvalue = max; currentx=cent-bump; currenty= cent+bump; } else if ( temp == right+down ) { center=0; xvalue = 0; yvalue = 0; currentx=cent-bump; currenty= cent-bump; } else if ( temp == left+up ) { center=0; xvalue = max; yvalue = max; currentx=cent+bump; currenty= cent+bump; } else if ( temp == left+down ) { center=0; xvalue = max; yvalue = 0; currentx=cent+bump; currenty= cent-bump; } } else counter++; if (whichport == 0) { if (center) return currentx; return xvalue; } else if (whichport == 2) { if (center) return currenty; return yvalue; } } else // use original inputs return readinputport(whichport); } -
strange ill checkout it out on the pi. You need to understand something about this code. This function only reads one axis at a time x then y over and over at high speeds keep that in mind if you make changes.
-
It's seems to work good, the only issue I had was on the first run of the code direction wasn't defined so temp was trying to use an undefined variable and it caused glitches.
So I changed it slightly,
This version should solve it:
Outdated
static READ16_HANDLER( analog_r ) { #define max 255 #define cent 128 #define bump 51 #define up 1 #define down 2 #define left 4 #define right 8 static INT16 xvalue = 0x80; static INT16 yvalue = 0x80; static INT16 currentx = 0x80; // face left first round static INT16 currenty = 0x7F; static INT16 center = 0; static INT16 delay = 0; if( options.cheat_input_ports) // use cheat ports { if (delay == 8) // debounce protection { int temp = readinputport(6) & ~16; delay = 0; if ( temp == 0 ) center =1; else if ( temp == up ) { center=0; xvalue = cent; yvalue = max; currentx=cent; currenty= cent+bump; } else if ( temp == down ) { center=0; xvalue = cent; yvalue = 0; currentx=cent; currenty= cent-bump; } else if ( temp == left ) { center=0; xvalue = max; yvalue = cent; currentx=cent+bump; currenty= cent; } else if ( temp == right ) { center=0; xvalue = 0; yvalue = cent; currentx=cent-bump; currenty= cent; } else if ( temp == right+up ) { center=0; xvalue = 0; yvalue = max; currentx=cent-bump; currenty= cent+bump; } else if ( temp == right+down ) { center=0; xvalue = 0; yvalue = 0; currentx=cent-bump; currenty= cent-bump; } else if ( temp == left+up ) { center=0; xvalue = max; yvalue = max; currentx=cent+bump; currenty= cent+bump; } else if ( temp == left+down ) { center=0; xvalue = max; yvalue = 0; currentx=cent+bump; currenty= cent-bump; } } else delay++; if (whichport == 0) { if (center) return currentx; return xvalue; } else if (whichport == 2) { if (center) return currenty; return yvalue; } } else // use original inputs return readinputport(whichport); } -
Temp should also be defined inside the "delay" debounce section so it's not repeatily initialized. So it's initialized when we actually go to use it. Updated it above . I'll test it later
And great work. This is a very clever solution.
-
actually that code isint there at all i just told you can increase the loop.
this code always ensures the last direction is set was sent regardless if your missed read direction or not. the last position pressed is returned always. you should only have the delay around the reading the input port.
The only change you need to make is change
UINT16 direction;to static UINT16 direction =0; so its initialized at center when adding the delay loop.
if(whichport == 0 || whichport ==2) direction = readinputport(6);was only originally there incase somone set cocktail mode thats reads 1 and 3 for player 2
-
@grant2258
Correct it has to be static, That was my thinking. That's what I meant by the first time read it wasn't set. That's what caused my issue before.With that fixed, coded your way it updates direction once every 8 count but writes to the xcurrent, ycurrent, xvalue, yvalue on every count, which it doesn't need to since it's using the same direction value every time it writes. So I changed your code to update direction once every 8 count and write to xcurrent, ycurrent, xvalue, yvalue on every 8 count too.
They both do the same thing, my version of your code just uses more efficiency when setting the variables.
Then I moved int temp into it's scope so it's not initialized on every count but only when being used.
Im glad it's working now regardless, I can't help thinking if we did something similar we could fix true analog stops too. Obviously 8 way is the best we can do on digital. Making mame2003-plus the home of working food fight lol. 💪, Unofficially.
It's easier with digital because it's 8-way on or off movements but analog has range so you'd need to know the range of each direction.
-
Well this game isint 49 way its two pots on a gambit. Ie really big ass thumb stick. The code is sending back like this for a reason.
Say you read x pause and y doesnt get updated your centering will be off because your only sending one axis back (it only reads one at a time0) and the other one got missed the x and y being off can effect your positioning. You looking at the code like its digital and its not you need to mimic an analog stick it was reading at this rate in the first place. the original code always met this condition anyway so it wasnt an issue until a delay was added i just showed you some code how to easily implement it.
It seems you know what your doing hopefully this we help you understand a iittle more if you wanna try fix something else. To be honest I never payed this game before I like it but the music sucks balls! doorooh doooroho doooooooooooooooo aaaaaaaaaaaaarg
-
What I'm getting at is, I test games on my spare pi outside my arcade cab which uses a PS2 style controller so it has digital and analog to work with. If I set the new center digital feature off and the cheat input feature off my digital keeps running as expected and analog will stop but always facing right. While still moving, analog has crisp moving directions between that of a 8 way control as it should.
If I turn centering on both digital and analog stop to the right. Analog still has it crisp movements though.
Now turn on cheat input. Both digital and analog stop correctly but analog is cut to 8 way movements because of the returns in the cheat input feature (which I know it's not meant for analog).
If we coded this part:
else // use original inputs return readinputport(whichport);To instead look for current analog positions, and return stops positions, analog could also benefit from fixed stops without being reduced to 8 way. It just has a lot more positions to account for.
You'd need a grid chart to define each direction range of both pots(x and y) to use as a lookup table then determine a stop from it based on your position.
-
to be honest the game should re calibrate when you use it a while the game is coded this way. The grid you work out can change you need to know what the self calibrating code is doing in the game.
The ps2/3/4/xbox360 pads are useless for this game the analog resolution its too low on them its not too bad on a xbox one though. the digital code leaves you facing your last direction if you code it properly i have no issues with it. I will test this on the pi and let you know if i have any issues with the digital. The thing with the original is the joystick might not have self centered either.
-
@grant2258 so you're saying if you use a Xbox one controller analog stick it doesn't snap right everytime you stop? And because PS2 analog has less range it snaps right?
I have no issue with digital with the fix implemented here. I'll probably just optimize the hell out of it and test and bugs.
-
@mahoneyt944 yes if its centered it will snap right but it has a higher resolution you can circle the eyes easier ect
-
@grant2258 oh I see..... Well I don't care about moving the eyes when I'm stopped, as long as I stop facing where I last pressed. So this fix does just that for analog and digital. But the side effect is it reduces analog to 8 way movements....Since we are returning set movements and stops instead of actual positions when centering.
-
im lost now the digital code on runs when you set the cheat options it in the if condition.
-
@grant2258 I'm just saying this fix benefits when using analog sticks too but at the cost of cutting the analogs precision to 8 way. That's all. Analog always centers facing to the right and it sucks to play it that way. I know this input cheat is not intended for analog but using it with the analog stick allows you to center facing more properly.
So it got me thinking if we use the off section of our cheat input option to correct analog to stop facing in the direction last pressed too it would complete the driver. It's just a lot more directions to account for on analog.
Cheat Input Off would fix analog and on would fix digital.
I'll never use analog because my cab has digital but it would be cool to see fixed for the benefit of the games emulation.
To correct analog in this hypothetical cheat input off code it would be something like:
if (centered) { return stop_direction;} Else return readinputport(whichport);The stop_direction would be set based on the last position your stick was in before centering. Similarly to what you did to fix digital . Just more directions to account for.
-
you would need to look at that but thats not in the original games specs. The rolling just the eyes is important in analog controls in this game the gimbal lets you walk up to piles of food and throw it all directions without moving because it had such a big throw it would be easy to pull off. I think it would be a sane move to return 7f in digital if your going to switch between the two.
-
@grant2258 agreed.
So is Digital uses 0 to 255, 128 being center and analog uses 00 to FF, 7F being center? Correct?
I'll look into it at a later date. No hurry right now though.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.