Incorrect Joystick Input

[codeninja]

While playing DrMD and TileMatch, two of my favorites on GP2x, I noticed that sometimes joystick input was wrong. I'm not sure whether it's the fault of the hardware, the firmware, or DrMD or TileMatch themselves.

It feels like the input is based on acceleration so that even if you switch direction after holding down one direction for a while, it won't switch direction instantly, there seem to be inertia, which doesn't make sense. Also, for example, hold upward for a while and press right, it takes it as down input, although I'm squarely pressing right.

Anyone else notice that?

 

[Squidge]

Have you tried the test menu?

 

[RiX0R]

Yeah I think I have that too (the reverse direction thing). Although I've always taken it as a problem with not throwing far enough when coming from the opposite side.

Don't think I've had the right = down thing though.

 

[grahf]

mine had trouble doing rights, but after a while it got much better.

 

[codeninja]

mine had trouble doing rights, but after a while it got much better.

​

Mine is not having trouble recognizing right, but problem comes when I do continueous move to right from up or down. I'll try the test menu that I didn't know existed, when I'm done recharging my batteries. Well, where is AC adapter that GPH's supposed to release? <_<

 

[Empyre]

You'll probably find you are pressing the centre button as you move from one direction to the other and thats screwing it up.

 

[DaveC]

While playing DrMD and TileMatch, two of my favorites on GP2x, I noticed that sometimes joystick input was wrong.  I'm not sure whether it's the fault of the hardware, the firmware, or DrMD or TileMatch themselves.

..., for example, hold upward for a while and press right, it takes it as down input, although I'm squarely pressing right.

Anyone else notice that?

​

The problem you are having with directions is the bias of this stick. Well in fact there really is none, all directions including diagonals have the same chance of being hit. All older digital controls had orthagonal (up, down, left, right) bias. With this stick if you are slightly off you will hit a diagonal.

It can be tweaked in software by enlarging the target area by assigning more combinations to the orthagonal directions. I showed this on that chart I made as "case 2". We just need to convince devs to try different methods like this to give better controls.

 

[abigsmurf]

one of the problems seems to be down to the coding of the controls.

if you do a very slow circle you'll notice you can hit the up/down and up/down+left/right at the same time. However from what I can tell most programs will treat as read like that as the diagonal.

This leaves a pretty small space for the four main directions and a large space for the diagonals. It becomes problematic when holding a direction for a long time as you get the occasional blip where you're pressing two directions

Controls need to be prioritised to that if a direction + diagonal are registered at the same time, the direction is what is read, not the diagonal.

This'll greatly improve the accuracy of the stick

 

[DaveC]

one of the problems seems to be down to the coding of the controls.

if you do a very slow circle you'll notice you can hit the up/down and up/down+left/right at the same time. However from what I can tell most programs will treat as read like that as the diagonal.

This leaves a pretty small space for the four main directions and a large space for the diagonals. It becomes problematic when holding a direction for a long time as you get the occasional blip where you're pressing two directions

Controls need to be prioritised to that if a direction + diagonal are registered at the same time, the direction is what is read, not the diagonal.

This'll greatly improve the accuracy of the stick

​

Yes

That is what I have been trying to get devs to put into their emus, etc. for a long time. I haven't had much luck with that yet though. At least I am not the only one that thinks it should be done this way to eliminate the accidental diagonals.

It is the "case 2" option in my chart here. Notice how that gives orthagonal directions a larger target. This is how all other 4-switch 8 direction pads and sticks worked.

 

[foft]

I did case2 in the atari800 emulator. Found it was most realistic since angles were hard on the old sticks.

I'll add full configuration in 0.9 (if anyone ever bothers getting 0.8;-)).

Mark

 

[telengard]

one of the problems seems to be down to the coding of the controls.

if you do a very slow circle you'll notice you can hit the up/down and up/down+left/right at the same time. However from what I can tell most programs will treat as read like that as the diagonal.

This leaves a pretty small space for the four main directions and a large space for the diagonals. It becomes problematic when holding a direction for a long time as you get the occasional blip where you're pressing two directions

Controls need to be prioritised to that if a direction + diagonal are registered at the same time, the direction is what is read, not the diagonal.

This'll greatly improve the accuracy of the stick

Yes

That is what I have been trying to get devs to put into their emus, etc. for a long time. I haven't had much luck with that yet though. At least I am not the only one that thinks it should be done this way to eliminate the accidental diagonals.

It is the "case 2" option in my chart here. Notice how that gives orthagonal directions a larger target. This is how all other 4-switch 8 direction pads and sticks worked.

​

Is it possible to code this up in a small library so that devs don't each have to implement it themselves?

<can't wait to get my unit so I can start coding>

~telengard

 

[codeninja]

GPH should have made the joystick 4way only DPad. It's no analog stick to begin with, so this joystick is screwing both 2D and 3D games.

 

[Eolair]

No use crying over spillt milk is there?
We have make the best of what we have. For emus I think it would be a good idea to have different config options for the joystick. You could then choose the config option that best fit the game you were going to play.

 

[DaveC]

I did case2 in the atari800 emulator. Found it was most realistic since angles were hard on the old sticks.

I'll add full configuration in 0.9 (if anyone ever bothers getting 0.8;-)).

Mark

​

Yes it seems to work good. And you are right angles were harder on old sticks, and all d-pads as well. That is why I think the case 2 is good for emulating old 8-way sticks/pads.

I played the emu and it seems to work well this way.

I could see using other cases for some specific games though.
Case 1 would be good for emulating analog Sticks like Atari-5200 games like Missile command and Centipede. Not all 5200 games would use it though, Pac-Man for example.
Case 5 would work well for Pac-Man and Frogger.
Case 6 would work well for Q*bert.
Case 2 for everything else.

By the way your emu rocks! I am glad you ported it Keep up the fine job.

 

[RiX0R]

GPH should have made the joystick 4way only DPad. It's no analog stick to begin with, so this joystick is screwing both 2D and 3D games.

​

No I like the stick (except for the cap <_<). And the fact that we have 16 directions just opens the door to the perfect control for each type of game. After all, more = better, right?

 

[DaveC]

GPH should have made the joystick 4way only DPad.  It's no analog stick to begin with, so this joystick is screwing both 2D and 3D games.

​

No I like the stick (except for the cap <_<). And the fact that we have 16 directions just opens the door to the perfect control for each type of game. After all, more = better, right?

​

It also opens the door for dodgy controls too It has to be programmed for the right way or a game/emu can be ruined.

It also prevents us from replacing the stick if we don't like it. For example we now can't replace the stick with a d-pad because d-pads are 8 way not 16. There would be no way to add the other 4 switches if using like say a Nintendo cross pad to replace the stick. That 16 way stick locks us into that design.

But like was said, no use crying now, it is what it is, now we just have to make the best/mod what is there.

 

[codeninja]

GPH should have made the joystick 4way only DPad. It's no analog stick to begin with, so this joystick is screwing both 2D and 3D games.

​

No I like the stick (except for the cap <_<). And the fact that we have 16 directions just opens the door to the perfect control for each type of game. After all, more = better, right?

​

Thiis 16 direction idea is one of those that makes great sense on paper, but impractical/useless in real life much like analog buttons on PS2. No existing 2D games that I know are designed with 16 direction input in mind, and it's too little number of directions for true 3d game input and way too many directions for 2D game input. Basically, it's the worst of the both worlds. For 2D games especially for emulator games, 4 direction is the way to go, and getting 8 direction of out the 4 hardware direction is way easier and more reliable. Nintendo's D pad and Sony's fake D pad (D pad hidden under plastic separator) are living proofs. Try to play Puzzle League for Gamecube with analog stick, and tell me more = better.

No, more is not always better. More bugs are not better than less bugs. More headaches are not better than less headaches. More crime is not better.

 

[codeninja]

Have you tried the test menu?

​

Would someone tell me where I can find this test menu?

 

[BBTroll]

Settings -> T-Mode

 

[BradN]

Another control option would be a slightly rotated 8 way, example:

virtual : physical
up : up <or> up and up-right
up-right : up-right <or> up-right and right

etc... might take a little getting used to for maximum effectiveness, but it makes all of the zone sizes the same, and the "pure" directions (up, up-right, right, etc) are still recognized correctly. It's just a way to deal with the ambiguous left/right/up/down + diagonal inputs without totally favoring the diagonals over the 'base' directions or vice versa.

I think the best option is making the inputs completely configurable to the user (unless the program is written to take full advantage of the 16 combinations )