The Another Try To Improve Gp2x's Stick

[Radek]

Hi,

First the picture:

Second link to the file: timefilter.zip

You must have installed Python to run this program. The start button exists it.
All files (except the readme.txt) must be placed in a root directory of your
SD card.

What it's doing?

Well... it's filtering stick events in a time domain. I had that idea for some time now and finally made a program demonstrating it.

Experiment with it and you will get idea how it's working probably.

If not then let me tell it's delaying stick's events so fast incidental moves will not register. You can tune up its sensitivity for both ordinals and diagonals. Unfortunatelly it can introduce visible latency at higher settings. For make up that drawback I included the "pseudointelligence" option. It isn't really that intelligent but so what?

This filter can give best improvements for moves like the up->right and to lesser extent the left->right. It'd be good for games what are using the upper diagonals for jumping. In some games when I want to rapidly change movement in horizontal axis I very often get diagonal too. It's because of gp2x's stick mechanics as it can move freely and doesn't have any microswitches (unlike the DPad where movement is forced by construction to only 8 directions).

 

[Paradox]

cool..too bad no devs seem interested in implimenting these new stick things..

 

[DaveC]

So what this does is delay the inputs on diagonals? I don't see how this will help. It will still give you an unwanted diagonal, it will just take longer for you to realize it. I could see that being a problem if you want diagonals, it would delay your input. Honestly it is like you are just moving the problem from one thing to another but the stick itself is still FUBAR.

 

[Julius]

I haven't tried it yet, but if it only hits a diagonal if you pressed it for a certain time, instead of hitting it every time you might accidential hit one for a 1/x of a second, it would be benificial I guess.

 

[Minkoff]

So what this does is delay the inputs on diagonals? I don't see how this will help. It will still give you an unwanted diagonal, it will just take longer for you to realize it. I could see that being a problem if you want diagonals, it would delay your input. Honestly it is like you are just moving the problem from one thing to another but the stick itself is still FUBAR.

​

It's not a cure for the stick, but it improves 2D games. Basically, since there's a diagonal bias, when switching from one direction to another you'll more often than not hit the diagonal in between. In alot of types of games, specifically those that need you do input precise combinations of directions/buttons, this problem makes them completely unplayable.

Now, when you move the stick from right to up, even without seemingly touching the diagonal, the input will likely be something like Right UpRight UpRight Up, because of the stick's diagonal bias. By delaying the reaction of UpRight, it will simply be read as Right Right Right Up, which, while not perfect, should definately help.

 

[woogal]

cool..too bad no devs seem interested in implimenting these new stick things..

​

You posted 30 minutes after Radek posted about his idea. Were you expecting all apps to implement this in that space of time :blink:. I think you will find that the vast majority of devs have spent time playing with different methods for reading the joystick and trying to find ways that fit best with their apps. Those that haven't have probably been concentrating on improving other areas of their apps that are more important to them.

Has anyone tried this test app yet? how well does it perform? I had a similar idea a few weeks ago and in theory something like this should work well, but I haven't had the time to create any tests.

 

[Radek]

So what this does is delay the inputs on diagonals? I don't see how this will help. It will still give you an unwanted diagonal, it will just take longer for you to realize it. I could see that being a problem if you want diagonals, it would delay your input. Honestly it is like you are just moving the problem from one thing to another but the stick itself is still FUBAR.

​

It's not a cure for the stick, but it improves 2D games. Basically, since there's a diagonal bias, when switching from one direction to another you'll more often than not hit the diagonal in between. In alot of types of games, specifically those that need you do input precise combinations of directions/buttons, this problem makes them completely unplayable.

Now, when you move the stick from right to up, even without seemingly touching the diagonal, the input will likely be something like Right UpRight UpRight Up, because of the stick's diagonal bias. By delaying the reaction of UpRight, it will simply be read as Right Right Right Up, which, while not perfect, should definately help.

​

When the diagonal latency will be set to half and ordinal to none it will you give you just right up. It's because the every stick's switch has its own time counter and acts independently. I included options to only set diagonals and ordinals to make it suited to gp2x's number of buttons.

Another good way to show it to make fast moves from left->right and right->left. Normally there will be almost always upper diagonal for a very short moment but long enough to be registered. Effect? Messed up gameplay for games what depends on precise jumping like PrinceOfPersia running in the Castaway.

Some games are more immune to gp2x's stick imprecision. I think it is because they are polling the stick at lower rate so latency of input is higher therefore they're doing some time filtering already by accident.

For the "pseudointelligence" option it is just turning off the filter when the stick is idle. It kicks in immedietaly and I found that's not optimal - there should be "delay" time for it. I will later add such option so the best compromise could be set.

 

[shrubberyrobbery]

what an interesting idea! that really is thinking out of the box.

I haven't tried it yet, but it seems that to get the lowest latency overall, the best setup would be as you said: to have the latency at zero for ordinals, and 'some' for diagonals.

I guess there's even more room for tweaking. How about filtering out certain combinations altogether, so that you only ever get 'up' OR 'up-right' but never 'up' AND 'up-right'. that way you'd possibly have a tiny dead-zone between ordinals and diagonals, but you'd be back to a pure 8-way response and each direction would have the same 'range' of response area.

I suppose it depends on the app, it could be disastrous for some games

 

[Radek]

OK...

A second version of my filter - improved and with changed names.
(to reflect its functionality better)

Download here.

Could it be putted in the GP32x's archive? I humbly think it's worth it.

For functionality... there is one parameter extra - the dynamic gating strength.
(the former "pseudointelligence" but with threshold). At zero it turned off and at highest setting it becomes like that old option.

For me it works best at zero for ordinal relase, 4 for the diagonal relase and dynamic gating at 6.

How do you like its effects?

 

[rokdcasbah]

this is a great idea. also, going off of what shrubberyrobbery said, would it be possible to have a filter that acted based on every -pair- of direction hits, rather than looking at single ones?

so:

[N > E] replaces [N > NE > E]

N > S replaces [N > NE > S], [N > NW > S], [N > SW > S], and so on.

This way, it becomes impossible to hit a diagonal except from center, and combined with Radek's latency, it becomes impossible to hit diags at all.

 

[Radek]

this is a great idea. also, going off of what shrubberyrobbery said, would it be possible to have a filter that acted based on every -pair- of direction hits, rather than looking at single ones?

so:

[N > E] replaces [N > NE > E]

N > S replaces [N > NE > S], [N > NW > S], [N > SW > S], and so on.

This way, it becomes impossible to hit a diagonal except from center, and combined with Radek's latency, it becomes impossible to hit diags at all.

​

Yes and my filter already can do that to an extent...
(and could do it fully after some modifications - it's just tuning up its parameters)

Put "diagonal relase" to max and tweak with "dynamic gating". You will get similar results to what you said.

I could do full 8 way time gate with separate attack and relase values (now it has only it for delaying BUTTONDOWN events) and add more configurations of prefilter (or make it post - could be better?). The polling freqency could be higher too but Python isn't exactly fast so... I will not add more options to it. It's just a demonstration of the concept and needs really to be done with C to be usefull in actual aplications.

 

[rokdcasbah]

this is a great idea. also, going off of what shrubberyrobbery said, would it be possible to have a filter that acted based on every -pair- of direction hits, rather than looking at single ones?

so:

[N > E] replaces [N > NE > E]

N > S replaces [N > NE > S], [N > NW > S], [N > SW > S], and so on.

This way, it becomes impossible to hit a diagonal except from center, and combined with Radek's latency, it becomes impossible to hit diags at all.

​

Yes and my filter already can do that to an extent...
(and could do it fully after some modifications - it's just tuning up its parameters)

Put "diagonal relase" to max and tweak with "dynamic gating". You will get similar results to what you said.

I could do full 8 way time gate with separate attack and relase values (now it has only it for delaying BUTTONDOWN events) and add more configurations of prefilter (or make it post - could be better?). The polling freqency could be higher too but Python isn't exactly fast so... I will not add more options to it. It's just a demonstration of the concept and needs really to be done with C to be usefull in actual aplications.

​

yes, i had guessed that your filter already did something of the sort after i posted that...so now the question is...where are all the C hackers hiding?

 

[Paradox]

cool..too bad no devs seem interested in implimenting these new stick things..

​

You posted 30 minutes after Radek posted about his idea. Were you expecting all apps to implement this in that space of time :blink:. I think you will find that the vast majority of devs have spent time playing with different methods for reading the joystick and trying to find ways that fit best with their apps. Those that haven't have probably been concentrating on improving other areas of their apps that are more important to them.

Has anyone tried this test app yet? how well does it perform? I had a similar idea a few weeks ago and in theory something like this should work well, but I haven't had the time to create any tests.

​

theres also davec's configurations which have been out for ages which i dont think anyone has used those.

 

[ingrin]

Skeezix did with Atari ST emulator

 

[abigsmurf]

This is a good idea, it shouldn't affect gameplay too much either. Diagonals have been traditionally stiff or hard to hit in controllers so I usually have it press a bit before I need to use it anyway. It will make beatemups impossible though but for the majority of games where diagonals are only rarely used it'll improve the situation greatly

 

[Radek]

I'm crazy...

And the download link.

It was done after some my research and "technically" is superior to previous version. Yet it's hardly better in an actual use... Sophistication can you get only so far but anyway - use, experiment or whatever. I'm satisfied as I learned much in the process and later will do small and efficient version in the C (I hope) what will be based on second version of my idea.

I was mad enough for a while to even think about implementing such things like a predication...
But I realized that any such algorithm to work properly would have to be hand tuned for every user and every game. That's beyond capability of average user and best results could be only marginally better. So... I'm really tired of it especially that I have a much superior solution in the works...
(and could you show some results already if not that my dumb mistake so it will have to wait a day or two longer) :angry:

 

[DaveC]

Honestly I don't think this is practical. It may be ok sometimes but screw other things up. It doesn't keep you from hitting a diagonal it just delays it. So you will still get the unwanted diagonal it will just take a little longer to notice it because of the lag. And what happens when you WANT a diagonal and it doesn't register right away? Then people will complain of laggy diagonals.

The only solution is to fix the stick by rotating, or modding for best controls.

 

[Hanz™]

Honestly I don't think this is practical. It may be ok sometimes but screw other things up. It doesn't keep you from hitting a diagonal it just delays it. So you will still get the unwanted diagonal it will just take a little longer to notice it because of the lag. And what happens when you WANT a diagonal and it doesn't register right away? Then people will complain of laggy diagonals.

The only solution is to fix the stick by rotating, or modding for best controls.

​

No offence, but you are the guy who recommended case configurations, I hardly think you can complain about this not being practical!
Do you think that writing immensely optimized emulators that run at 133mhz @ fs0 is practical as well.
Ooooh you twist and turn!

 

[Radek]

Honestly I don't think this is practical. It may be ok sometimes but screw other things up. It doesn't keep you from hitting a diagonal it just delays it. So you will still get the unwanted diagonal it will just take a little longer to notice it because of the lag. And what happens when you WANT a diagonal and it doesn't register right away? Then people will complain of laggy diagonals.

Actually none of these apps are just "delaying" diagonals. They acts like a noise gate so shorter events (with time between buttondown and buttonup being lower than a thereshold) are completely filtered out.

First version is the most basic.

The second has strength for "dynamic gating" what will turn off filter if stick is iddle for some time so average lag can be shorter.
(and is imho overall the best)

The 3rd is an experimental version and I'm fully aware that such things can only get you so far.

People can complain about everything but does it mean I should forget about it all?
I had an idea and was interested in testing it. I see nothing bad in that I make results of my research public.

The only solution is to fix the stick by rotating, or modding for best controls.

​

Rotating will not fix much because the gp2x's stick problems are beyond the bias. There is no discrete mechanical movements in it (unlike the DPAD) so it will never will be accurate. Only full fix would be complete replacement of stock stick.

 

[DaveC]

No offence, but you are the guy who recommended case configurations, I hardly think you can complain about this not being practical!
Do you think that writing immensely optimized emulators that run at 133mhz @ fs0 is practical as well.
Ooooh you twist and turn!

​

Ok so since I recommended case configurations I must agree with everything else no matter what?

Optimized emulators don't make sense? Huh? Making slow emulators clocked to 266 MHz are practical? I don't get it :rolleyes:

You make absolutely no sense. It seems you just like to flame.