Food Fight - joystick troubles, solved
-
if the counter isn't 8 direction wont be set to be used with temp. is that an issue? Or should this be a while loop
-
it intentional it uses the last read. The problem is it reads so fast you get button debounce you need to slow the reads down unti you get horizontals without issues.
-
@grant2258 right but on first time run your direction wasn't set yet to have a last read position.
-
@mahoneyt944 are you having any issues ? you shouldnt be. The analog reads far too fast for button debounce you need 10 - 20 ms for the debounce. Even when you dont press a button it will read zero as center it will happen so fast you wont notice it and teh buttons will be read in less time than you could press it.
-
@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.
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.