GP2X Gp2x Joystick Actual Facts

[DaveC]

One further way would be to remember which of the "primary" 8 directions you have selected, and if you select one of the 8 "in between" directions next to that, you use the primary you used to have selected. This basically means you have a bias for the primary direction you currently have selected, this should make control more stable.

​

That would basically be doing the same as "case 2" In that case the in-between directions are treated as one of the primary 8.

 

[Squidge]

What I'll probably do is that if there's more than one direction selected, I'll just take the first, going from LSB to MSB.

Eg. in binary, If I get this 0000 0110 (both top left and left selected), then I would only take the first one, which would be top left.

If someone wants more than that, they can take the source code and rework it themselves ;-p

 

[DaveC]

What I'll probably do is that if there's more than one direction selected, I'll just take the first, going from LSB to MSB.

Eg. in binary, If I get this 0000 0110 (both top left and left selected), then I would only take the first one, which would be top left.

If someone wants more than that, they can take the source code and rework it themselves ;-p

​

I can see that this stick config is going to result in some really screwed up controls. In your method if you really wanted left but weren't exact it would instead move diagonal? That will be frustrating as hell to control. It will be like a lousy zodiac analog.

GPH and their stupid ideas. Why couldn't they just stick with the normal way of doing stuff. The GP32 will control much better. This thing will be crap if the controls are done like that.

 

[noir.pl]

GPH and their stupid ideas. Why couldn't they just stick with the normal way of doing stuff. The GP32 will control much better. This thing will be crap if the controls are done like that.

Relax... By having source code we are limited by only 2 factors: hardware and time

Oh, and I think that we shouldn't distract Squidge while he is working on UAE

 

[DaveC]

GPH and their stupid ideas.  Why couldn't they just stick with the normal way of doing stuff.  The GP32 will control much better.  This thing will be crap if the controls are done like that.

Relax... By having source code we are limited by only 2 factors: hardware and time

Oh, and I think that we shouldn't distract Squidge while he is working on UAE

​

Yeah but we will often get games and emus that are hard to control because the programmer of that app may not bother to find the best solution for the controls. We will come across software that is good but the controls ruin it making it frustrating and hard to control. The zodiac is a perfect example. There were some emus that were ok but because of the bad analog control they were rendered almost unplayable. The same will happen here when a programmer just throws something together without picking the best controls. Woogal already stated that in his GP2X Duke port it controlled like crap and was almost unplayable due to the over sensitive default config. He had to make a conscious effort to try some other things to make it better. That is the point here we must think about it and not just pick something at random.

 

[Undefined Error]

Yeah but we will often get games and emus that are hard to control because the programmer of that app may not bother to find the best solution for the controls. We will come across software that is good but the controls ruin it making it frustrating and hard to control. The zodiac is a perfect example. There were some emus that were ok but because of the bad analog control they were rendered almost unplayable. The same will happen here when a programmer just throws something together without picking the best controls. Woogal already stated that in his GP2X Duke port it controlled like crap and was almost unplayable due to the over sensitive default config. He had to make a conscious effort to try some other things to make it better. That is the point here we must think about it and not just pick something at random.

​

Balancing controls is a part of making a good game, regardless of the hardware it is running on. If a developer is too lazy to test and develop a good control scheme, it will show, whether the hardware returns two bits, one bit, or five bits when the stick is pushed. As you have shown yourself with your diagrams, each game will have different needs that will work best with different control interpretation setups, and choosing the right one for a game is simply another part of making a good game. This is not a unique situation to the GP2X; consider all the games that did not allow diagonals on the NES even though the pad COULD read them or the games that needed to favor horizontal movement over vertical. (Paperboy is, for some reason, coming to mind.) Games are critiqued and criticized for their controls all the time, even professional ones. Sure, some hardwares are easier to deal with than others, but no hardware is impossible to deal with and no hardware removes the burden of creating good controls from the developer completely. FWIW, I think this design makes for a nice compromise between the tendency of analog controls to become mushy in games requiring precision and the limited number of directions of digital controls.

I guess what I'm saying is - Yes, developers will need to be aware of this, but it's not something unique to the GP2X. No matter what the hardware, developers would need to be aware of it. As you have said, Woogal had to make a conscious effort with his Duke port; his initial instinct was that using all 16 directions would be best, but he tested this, found out his instinct was wrong, and limited it to 8 directions in order to make the gameplay tighter. That's good game design.

 

[DaveC]

What I'll probably do is that if there's more than one direction selected, I'll just take the first, going from LSB to MSB.

Eg. in binary, If I get this 0000 0110 (both top left and left selected), then I would only take the first one, which would be top left.

If someone wants more than that, they can take the source code and rework it themselves ;-p

​

That would be like this:

I think this would cause alot of accidental diagonals, for example when pushing up you would get alot of accidental right diagonal movement. Plus it is rotated slightly making it counterintuitive.

Howcome you don't like the case2 config? That would give a much closer approximation to a regular 8-way. Maybe you could try a few to see which works better.

 

[DaveC]

I guess what I'm saying is - Yes, developers will need to be aware of this, but it's not something unique to the GP2X.  No matter what the hardware, developers would need to be aware of it.  As you have said, Woogal had to make a conscious effort with his Duke port; his initial instinct was that using all 16 directions would be best, but he tested this, found out his instinct was wrong, and limited it to 8 directions in order to make the gameplay tighter.  That's good game design.

​

The thing is on the GP32 you really didn't have to worry about this because it was an 8-way pad, and for emulators at least, most of the times you were emulating an 8-way pad/stick. It was kind of a no-brainer. Now you have all of these different ways of doing it. Already you have two different devs and thay are doing it completely different. I don't think any of those two solutions are very good either. One of them has dead zones resulting in potentially the game not responding at all in certain situations and the other will not respond as expected alot of times giving undesired directions. This will be an ongoing problem on the GP2X as the stick may never work the same way depending on the app. This will cause alot of control problems. As I said a plain old 8-way would have been much better.

 

[Axe_Murderer]

Once again, I'm inclined to agree with DaveC. I would probably have been more comfortable in the knowledge that the GP2X had a similar controller to the GP32. But I suppose that there is no point in griping about it now, we'll just have to work with what we've got. To that end, what do people think of the following idea:

IMHO, although the seemingly innocuous additional functionality of a 16-way controller may sound like a good idea on the surface, I think that it could have the potential to become a significant issue unless some kind of standardised implementation is agreed upon before the various and much respected devs go off in different directions.

The reason why I say this is that I expect that many people including myself would likely find it confusing having to switch between different systems when moving from one application to another. Instead, might users benefit from the ability to be able to maintain continuity in how their controller works by being able to specify their own chosen configuration external to the applications that could then pick up this same configuration?

For example, even if it was something as simple as a little text file that mapped the sixteen directions to what they wanted, could this file not then be picked up and used by the various applications? In this way, users could easily choose and define whatever configurations that they wanted to use.

Does anybody think that this or something like it might be a workable idea?

 

[pea]

Hi all,

Just my 2c.

The way I would emulate 8 way was to have two different settings - responsive and normal. All options are based on remembering the last main direction (switch) pressed.

The easiest is NORMAL:
Double switch presses are ignored (sw1+sw2 is ignored) and the NEW direction is only registered when one switch is down completely.
example: If sw1 is pressed, and then sw1+sw2 is pressed, this is still read as sw1, until it rolls around to sw2 only.
NOTE: This is similar to daveC's '8 way with dead zones' though it doesn't have deadzones because 2 switches read as the last switch, not as a dead zone.

RESPONSIVE:
Double switch presses are registered as a new button press - the switch which was NOT previously pressed is the new direction.
example: If sw1 is pressed, and then sw1+sw2 is pressed, this is then read as a change in direction to sw2 for a quick, responsive feel.
NOTE: This does not have a horizontal or a vertical bias - it is dynamic depending on the last direction registered.

EDIT: I would call these 'normal 8-way with dynamic bias' and 'responsive 8-way with dynamic bias'

 

[Undefined Error]

For example, even if it was something as simple as a little text file that mapped the sixteen directions to what they wanted, could this file not then be picked up and used by the various applications? In this way, users could easily choose and define whatever configurations that they wanted to use.

Does anybody think that this or something like it might be a workable idea?

​

Hmmmm... interesting proposition. While I could see how some games would not be well-suited to benefit from this, I could also see how some games could. Actually, it reminds me of one of the features of the Xbox 360, where you can set certain common, global configurations, like whether you want Automatic or Manual transmission in racing games or whether you prefer a Normal or Inverted look stick in FPSes. Granted, here as there, the burden lies on the program to actually pay attention to those options, but I think the idea of common configuration options being shareable between programs could be very cutting-edge for programs that are flexible enough about control schemes to support this.

 

[Axe_Murderer]

For example, even if it was something as simple as a little text file that mapped the sixteen directions to what they wanted, could this file not then be picked up and used by the various applications?  In this way, users could easily choose and define whatever configurations that they wanted to use.

Does anybody think that this or something like it might be a workable idea?

​

Hmmmm... interesting proposition. While I could see how some games would not be well-suited to benefit from this, I could also see how some games could. Actually, it reminds me of one of the features of the Xbox 360, where you can set certain common, global configurations, like whether you want Automatic or Manual transmission in racing games or whether you prefer a Normal or Inverted look stick in FPSes. Granted, here as there, the burden lies on the program to actually pay attention to those options, but I think the idea of common configuration options being shareable between programs could be very cutting-edge for programs that are flexible enough about control schemes to support this.

​

I suppose that it wouldn't necessarily have to be a case of one situation or the other. If the devs of the most commonly used emulators, applications and games for the GP2X were able to agree upon a very straightforward and easy to implement global configuration file, then perhaps it could be used as a minimum baseline of functionality to make users' lives a little bit easier for those of us that might otherwise have difficulty dealing with lots of different configurations.

Then, if various devs saw fit to implement additional hard-coded specialised configurations that they felt their app should also have access to and which wouldn't be possible to describe in the simplistic global configuration file, then that could be seen as an excellent bonus.

Of course, what really matters is what the devs themselves think of this kind of idea and whether they think it's worth the effort.

 

[Drag]

Ok, I just moved my thumb in a full circle on my GP32 FLU's joystick, and the result is actually quite different than you'd think.

In DaveC's diagram, the second configuration, "8 way vert/horiz bias", represents what my gp32's joystick does. Now, each gp32 MIGHT be different, but this is what my gp32's joystick does. It's not modded at all, and I can achieve all 8 directions on my joystick.

I think in the end, it just depends on what the gp2x's joystick feels like, especially since it doesn't click.

 

[pea]

Of course it behaves that way, it only has 4 switches, silly!

EDIT: Just to explain, if you are pushing right (sw3), and then you slightly push up, it still registers right (this is the 'horizontal bias') because there is no additional switch (sw2+sw3 in DaveC's diagram). It does not infact register up/right until the top switch (sw1) also comes on, which corresponds with DaveC's diagram as being exactly on sw2 (the switch the gp32 doesn't have).

 

[Drag]

Well, I'm just saying, if everyone wants a joystick that behaves like the gp32's, that's the way to go.

However, Pea's solution might be fine if everyone wants the directions to be totally equally distributed.

Edit: typo

 

[pea]

Ah, I see - yes you are right. If you want to emulate the GP32, thats the way to go. Sorry, I was a little confused by what you were meaning.

 

[DaveC]

Ah, I see - yes you are right. If you want to emulate the GP32, thats the way to go. Sorry, I was a little confused by what you were meaning.

​

That was the configuration (case 2) that I was recommending to use as a standard for all 8-way stuff.

Not only does that reflect and emulate the GP32 stick but basically all 4-switch 8-way pads and sticks have a horizontal/vertical bias. Think about it for a minute and go through all of the sticks/pads that you have used. Think of a Nintendo cross pad, a Sony PSX pad, an Atari 2600 joystick, many arcade sticks. All of them have a "case 2" horiz/vertical bias, it is always easier to hit up,dn,lt,rt than a diagonal.

 

[-SPM-Mad]

I am stupid, forget it.

 

[reallynotnick]

Sorry if I am too lazy to read through the hold thread, but DaveC was right in the fact that the GP2X can register 2 different directions. If you go in to T-mode (thats what it is called right) you can clearly see 2 spots being lit up. It is a little hard to do but possible.

If you guys already knew this, then just ignore this post and move on with your lives.