GP2X Gp2x And Interface And Other Standards

[DaveC]

Since the new GP2X is new and there will be alot of projects started maybe there should be a pinned topic about some common items that could be added into future apps.

Some features such as button combos to pull up game menus, how to do a re-set while in a game, directory structure where executables and data files are stored, joystick configuration options etc could be there. Coders could use this topic to know what standards are common setups etc.

Of course it can't and wouldn't be enforced. Coders will set things up how they want, but if they don't have an objection with using the "standards" they will be there as a guide if they want them.

For starters I have this diagram of different joystick options. This could be used by coders as a guide of how to configure the odd GP2X joystick to work the best in different situations. A bad config could make some games nearly unplayable

Case 1 would be good for any native games but also games that used analog or trakballs like Centipede, Missile command, or for emulating mouse movement like in ST/Amiga

Case 2 would be the ideal and recommended one for use in emulators and any game requiring traditional 8-way control. Typical 4-switch, 8-way controllers always were easier to hit the horiz/vertical than diagonals. This is because it is harder to keep 2 switches closed simultaneously than one. This would include, Atari-2600 type joystick, Nintendo cross pads, PSX pads, MD, SNES etc.

Case 3 would be useful for those isometric oriented games like Desert strike, Zaxxon etc that are mostly diagonal but still use some vertical/horizontal.

Case 4 would be useful if you wan't to get pissed that your character stopped moving and you got killed. You just have to ask yourself, do you feel lucky? Hit the dead zone at the wrong time and well...you're dead. This is for those that think games are too easy and want an extra challenge

Case 5 Horiz/vert 4-way. Useful for 4-way games such as Pac-man Thick purple lines separate directions for visualization. Anything from sw8 to sw1+sw2 would be "UP" and so on. Must be slightly rotated to make all zones even in size. I picked the rotation this way as it folows the arc your thumb would make while playing.

Case 6 Diag 4-way. Useful for 4-way diagonal only games such as Q*Bert. Thick purple lines separate directions for visualization. Must be slightly rotated to make all zones even in size.

Developers should think about these different configs, and include in the menu option screen a choice between a couple. MAME for example would be able to use case 1, 2, 3, 5, 6. Megadrive and most other emus would probably only need case 2. Atari-ST would use case 1 for mouse and then switch to case 2 using joystick mode.

 

[Undefined Error]

Your copious effort to document all the possible permutations of the control stick still amazes me, Dave.

That said, I completely agree that setting some standards would be a good idea. It would help, of course, to know what standards the existing software from GPH uses, or if GPH is encouraging any particular standards themselves. (The last thing we need is competing standards. I can just see it now: "Well, Mega Gut Busters uses the GPH standard, so you reset by pressing all the buttons at once, while Legend of Guernica uses the gp32x.de Messageboard Standard, so you reset with both shoulder buttons and clicking the stick in.")

Still, it couldn't be a bad thing to have some suggested rules as to how certain things are done. The big companies (Ninty, Sony, etc.) actually enforce these things in quality-control, I understand. (Stuff like A+B+Start+Select restarting GBA games or using "X" for selecting things in PS2 games, which always drives me insane because I'm used to the NES/SNES rule of using "A" for selecting things, which is in "O"'s position on the PSX controller... but I digress.)

Continuity between games is really a good thing for developers, as it helps players become familiarized with their interface more quickly. Of course, I agree no one's creativity should be stifled. If you have some badass new way to bring up the menu, or if the "standard" reset sequence conflicts with your control scheme, the standard should give way to the game's needs. For example, consider that in most games, the "Start" button pauses the game and/or brings up the menu. Yet how many RPGs on consoles with four face buttons use the button at the top of the diamond to bring up the menu? I don't know who, probably on the SNES, started this trend, but nearly all RPGs these days seem to follow this convention. And for what it's worth, I think it makes sense in RPGs, though not in all game types. The traditional console RPG doesn't typically need to use a lot of buttons for different commands as control is largely menu-driven by just the buttons signifying "select this" and "cancel back," so it places the main menu within easy reach, eliminating the need to move a hand to reach the start button. More action-oriented games, however, may need to map many commands to quickly accessible buttons and aren't able to spare one for an easy-to-reach menu button. Too, action-oriented games may want to limit overuse of the pause feature and thus putting it on a button that requires you to move your hands from the ready position discourages this.

Anyway, point is - yeah, I think setting some community standards would be a good idea, though we should also be conscious of the decisions that may have already been made by GPH regarding these things. (Say, maybe we should ask Anna about this?)

(EDIT: I hit a funny key combo and inadvertantly posted way too early.)

 

[DaveC]

Actually I didn't document all permutations of the stick, there are more just those are probably the most useful.

Any standards would have to be well thought out too. We could all give ideas and discuss. Hopefully all of the bad ideas would "boil off" and leave the good ones. After that a standard could be made and posted. As you say we can't stifel creativity, if a dev wants to give the big middle finger to the standards fine that is OK. If his idea happens to work better maybe that could be adopted even. It would just be a guide. Many devs wouldn't care what button does what, for them they could just go with the standard since they don't care one way or another.

On the GP32 there are kind of these standards already. For example hitting both shoulder buttons usually pauses the game/emu and goes to a menu, "A" is usually select a menu item, "B" is usually back/cancel. The right shoulder button usually pages down in a ROMlist Left pages up etc.

It would make stuff more intuitive. Imagine on a PC if right and left click would always be different depending on the app, it would drive you nuts.

 

[deadlychicken22]

or using "X" for selecting things in PS2 games, which always drives me insane because I'm used to the NES/SNES rule of using "A" for selecting things, which is in "O"'s position on the PSX controller... but I digress.)

Well, i don't think anyone enforces the "x" for selecting rule, I just think that developers have decided to make it the unofficial standard. IIRC, xenosaga uses "o" for the selecting botton and "x" for back. When I first played it I kept going back because I was so used to pressing "x".

BTW, xenosaga episode 1 is a great game (haven't tried out 2 yet....)

Back on topic, I think it would be great to have a standard, just don't try to enforce it. If someone wants to make theres different, great, but if you don't care you should follow the standard so that people aren't too confused about what button to press.

 

[Digital Awakening]

I'll be using A for OK and B for Cancel on GP2X. When it comes to anything else I'll rather spend some time with it and then decide rather then decide first and find out something better later.

 

[skeezix]

/me is shocked at the effort to produce the diagram

All I'd like to knjow is what the 'standard' will be for OK and Cancel; It sort of annoys me that with Sony, the Japanese and American standards are opposite (O and X being OK depending where you look at); likewise with SNES controllers and such.

Being lazy, we shoudl agree.

I bring up an odd example though, with my CaSTaway on the GP32; with two buttons, I used the left one for left-mouse-click, and the other for right-mouse-click for instance; but they're labelled A on the right, B on the left if memory serves, so I used 'A' to mean 'insert into drive A:' since it made sense. But it leads to confusion, with people assuming 'left' is first, when they were labelled backwards.

I'll have to go look at the GP2x pics more closely now

jeff

 

[Digital Awakening]

On GP2X A is left and B is right, that's why I want them as OK/Cancel. Would also do great as LMB/RMB is you are emulating a mouse. X is down and Y is up.

And my standards for games would be:
A: Fire
X: Jump/Throttle
B: Special
Y: Change weapon etc.

That's how I got my keyboard set up for SNES but horisontally fliped as I'm using WASD for my left hand.

Link to shot: http://www.gbax.com/x2whitesidebig.jpg

 

[MiniMoose]

I'll be using A for OK and B for Cancel on GP2X. When it comes to anything else I'll rather spend some time with it and then decide rather then decide first and find out something better later.

​

I vote for this "standard" as well.

 

[MiniMoose]

And my standards for games would be:
A: Fire
X: Jump/Throttle
B: Special
Y: Change weapon etc.

​

This is exactly the layout that I will use on all my games.

 

[skeezix]

Aside: There are both black/charcoal pics, and white pics (more like the gp32); I'm wondering.. what will it ship as? I'd much prefer it to be the charcoal body, rather than white. White screams 'kiddie toy', while blackish implies 'can show it around the office'

jeff

 

[icurafu]

And my standards for games would be:
A: Fire
X: Jump/Throttle
B: Special
Y: Change weapon etc.

​

This is exactly the layout that I will use on all my games.

​

I'd support this stadard if it was published in the wiki, however the most important controller standard should be to allow the user to define them.

 

[Digital Awakening]

Aside: There are both black/charcoal pics, and white pics (more like the gp32); I'm wondering.. what will it ship as? I'd much prefer it to be the charcoal body, rather than white. White screams 'kiddie toy', while blackish implies 'can show it around the office'

jeff

​

Although I prefer the wite one myself the first couple of batches will be black.

I'd support this stadard if it was published in the wiki, however the most important controller standard should be to allow the user to define them.

​

Yeah, all games should have full user defineable controlls. I hate it when games don't allow the player to change the controlls or have a few crappy settings to chose from.

 

[Undefined Error]

I'd support this stadard if it was published in the wiki, however the most important controller standard should be to allow the user to define them.

​

Yeah, all games should have full user defineable controlls. I hate it when games don't allow the player to change the controlls or have a few crappy settings to chose from.

​

Amen to that! It's not even that hard to implement, if done right... I wish I knew what made some developers not offer this feature, as it is the ultimate recourse of a gamer against a control scheme they don't agree with. (Referring to my preference of "O" for "OK" on the PS2, I can't tell you how many of my games are reconfigured to pander to this quirk.) Granted, it can be tedious and annoying to reconfigure every game you come across to meet your desires, but the payoff is worth it IMHO, and for those who disagree - they need not touch the reconfiguring screen. I'd rather have the option to spend time reconfiguring than be forced not to because I'm not allowed.

(EDIT: Hmmmmmm, the BBCode didn't parse right the first time... just spat out as plain text...)

 

[Digital Awakening]

Yeah, it's simple to make a key config where you select an action and then press the button you want to bind. I don't like it when I have to scroll through a list of buttons for each action.

 

[judge0]

Sounds like we will have a few other standards to sort out as well.
Things like file extensions, ie what to use to indicate support libraries, data files, save games etc.

Also a good idea would be to store the main executable (the *.gpe) in one location with all support/data/saves in a sub-directory/folder under it. So a naming convention to avoid conflict with other apps/games would be in order.

This supposes we maintain the linux OS, but what happens to all this if we also use straight machine code for better performance/systems resources, as mentioned by a few devs in other threads? That will require a different set of standards.

 

[icurafu]

Yeah, it's simple to make a key config where you select an action and then press the button you want to bind. I don't like it when I have to scroll through a list of buttons for each action.

​

How about we put together a generic config app. So it can be added to games so that it laods at startup and allows the user to choose configuration that maybe outside of the game. Such as:

Display:
Output to at what res and color-bit, to LCD or TV-out. Use Software or openGL software.

Sound:
On/off/miles software 3d.

Controls:
Definition

Clock:
What speed to clock the bus/cores at. Method used for keyboard mouse emulation.

 

[DaveC]

Aside: There are both black/charcoal pics, and white pics (more like the gp32); I'm wondering.. what will it ship as? I'd much prefer it to be the charcoal body, rather than white. White screams 'kiddie toy', while blackish implies 'can show it around the office'

jeff

​

Tsk Tsk Skeez' ole pal. You haven't been following the Gp2X very well have ya'

They are all coming in black. You should be happy about that

 

[Digital Awakening]

Sounds like we will have a few other standards to sort out as well.
Things like file extensions, ie what to use to indicate support libraries, data files, save games etc.

Also a good idea would be to store the main executable (the *.gpe) in one location with all support/data/saves in a sub-directory/folder under it. So a naming convention to avoid conflict with other apps/games would be in order.

This supposes we maintain the linux OS, but what happens to all this if we also use straight machine code for better performance/systems resources, as mentioned by a few devs in other threads? That will require a different set of standards.

​

Um, the file system works similar to a regular PC as far as I understand it. How devs organise their files is up to them if you ask me. Same with names. Why would everyone call their save files the same? 1 save system may not even work for every type of game.

Yeah, it's simple to make a key config where you select an action and then press the button you want to bind. I don't like it when I have to scroll through a list of buttons for each action.

​

How about we put together a generic config app. So it can be added to games so that it laods at startup and allows the user to choose configuration that maybe outside of the game. Such as:

Display:
Output to at what res and color-bit, to LCD or TV-out. Use Software or openGL software.

Sound:
On/off/miles software 3d.

Controls:
Definition

Clock:
What speed to clock the bus/cores at. Method used for keyboard mouse emulation.

​

If you wanna put something that uggly and scary in your games then I can't stopp you. But I know that you are an emulator fan so it's no surprice that you would like something like that. It's the first sign that the software might be crappy.

 

[MiniMoose]

This supposes we maintain the linux OS, but what happens to all this if we also use straight machine code for better performance/systems resources, as mentioned by a few devs in other threads? That will require a different set of standards.

​

Not really. Whether you use the Linux kernel or not, the SD card will still be FAT32 and will still have the same directory structure. I propose that we just settle on using the game name (and possibly the version) as the name of a root folder for the game and all associated data. That solves the name collision problem and also allows games to be aware of other games the user plays for potential cross-title content (e.g. "Would you like to use your controller config from <other game name here>?")

I encourage everybody to publish their data file formats and save game formats so that we can all learn from each other. Maybe we should build a simple database library for storing and retrieving chunks of data from data files.

 

[icurafu]

Sounds like we will have a few other standards to sort out as well.
Things like file extensions, ie what to use to indicate support libraries, data files, save games etc.

Also a good idea would be to store the main executable (the *.gpe) in one location with all support/data/saves in a sub-directory/folder under it. So a naming convention to avoid conflict with other apps/games would be in order.

This supposes we maintain the linux OS, but what happens to all this if we also use straight machine code for better performance/systems resources, as mentioned by a few devs in other threads? That will require a different set of standards.

​

Um, the file system works similar to a regular PC as far as I understand it. How devs organise their files is up to them if you ask me. Same with names. Why would everyone call their save files the same? 1 save system may not even work for every type of game.

Yeah, it's simple to make a key config where you select an action and then press the button you want to bind. I don't like it when I have to scroll through a list of buttons for each action.

​

How about we put together a generic config app. So it can be added to games so that it laods at startup and allows the user to choose configuration that maybe outside of the game. Such as:

Display:
Output to at what res and color-bit, to LCD or TV-out. Use Software or openGL software.

Sound:
On/off/miles software 3d.

Controls:
Definition

Clock:
What speed to clock the bus/cores at. Method used for keyboard mouse emulation.

​

If you wanna put something that uggly and scary in your games then I can't stopp you. But I know that you are an emulator fan so it's no surprice that you would like something like that. It's the first sign that the software might be crappy.

​

Scary? It's actaully quite common for ports. If you want to remove the scary bits, you can always comment out the fields.

If noone intends to do something like that, then there would be no point creating it.