Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Joysticks - Controller ID?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
15 replies to this topic

#1 irbaboon   Members   -  Reputation: 1152

Like
0Likes
Like

Posted 25 June 2013 - 06:43 PM

Hello! This is a bit long thread about a little issue I've encountered.

 

Yesterday I started looking at joysticks, and how to use them in my games. I found this to be fairly easy. I made an input system so I could register new controllers fairly easy. However, a problem has come up!

 

In the settings in my game, you get a list of all controllers connected to your computer. So you basically just choose one, and you can play with that controller.

 

Right now, I have configured an XBOX360 controller and an Nintendo 64 controller. After adding the N64, I realised the problem.

I needed to know which controller was which. So I added an "id" property to my joystick class. The game would then set an "id" to each controller, so it would know which action to do. 

 

The code to add an input looks like this, pseudocodeishly:

int ACTION_PAUSE = joystick->add_input();
joystick->add_trigger(ACTION_PAUSE, new button_press(XBOX360_BUTTON_START, CONTROLLER_XBOX360, input_state::pressed));
joystick->add_trigger(ACTION_PAUSE, new button_press(N64_BUTTON_START, CONTROLLER_N64, input_state::pressed));
joystick->add_trigger(ACTION_PAUSE, new key_press(key_return, input_state::pressed));

So it's all fine, until I realise I have to actually idenfity the controller.

What I thought first I could do was

joystick->open(controller_index, CONTROLLER_XBOX360);

Then I realised... I have no idea which controller is which.

 

I know I can call SDL_JoystickName for the name of the controller, but the Nintendo 64 controller, which I can use through an adapter, names the controller for "USB Controller". I have two of those, as there are two ports in the adapter. So what if I get, let's say, a GC adapter, and use a GC controller. Then I get possibly another "USB Controller" name. So I can't just use that name to identify the controller.

Also, I noticed that an XBOX360 controller of a friend of mine was a special one with a unique name. So I can't even see which is which of the same type.

 

So I'm wondering if there is a way to figure it out?

I thought of making a function that checks how many buttons, axes, hats and balls the controller has - but what if it's a special-made N64 controller? I saw one online that had special buttons on it. Regardless of that, it's a stupid idea anyway, lol.

 

So yeah, any thoughts?

 

Thanks in advance.



Sponsor:

#2 HappyCoder   Members   -  Reputation: 3119

Like
1Likes
Like

Posted 26 June 2013 - 10:59 AM

Well, I would probably have the game do the best it can to map input based on the number of buttons and the name of the device name but then allow the user to customize the input. You could try to have a good layout for the most common input devices but you will never be able to have the perfect layout for all input devices because new devices hit the market all the time.

#3 irbaboon   Members   -  Reputation: 1152

Like
0Likes
Like

Posted 26 June 2013 - 02:27 PM

Yeah, I know.

I guess I can try to make a function that tries its best to recognise a controller by its name and amount of buttons.

 

However, it would be so much better if there is some sort of signature in the controller...

 

I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.

Is there a logical explanation for this? The B button has ID 2, and then the left shoulder button comes next at ID 6.



#4 swiftcoder   Senior Moderators   -  Reputation: 14270

Like
1Likes
Like

Posted 26 June 2013 - 08:52 PM


I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.
Is there a logical explanation for this? The B button has ID 2, and then the left shoulder button comes next at ID 6.

Is the D-pad mapped to the 4 missing buttons?


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#5 irbaboon   Members   -  Reputation: 1152

Like
0Likes
Like

Posted 26 June 2013 - 09:11 PM

 


I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.
Is there a logical explanation for this? The B button has ID 2, and then the left shoulder button comes next at ID 6.

Is the D-pad mapped to the 4 missing buttons?

 

There are 6 missing buttons in total.

The D-pad is button 12, 13, 14 and 15. It's also a hat which has the dpad sum.

 

Here's the list of the IDs I have figured out:

// Buttons
static const int N64_BUTTON_A          = 1;
static const int N64_BUTTON_B          = 2;
static const int N64_BUTTON_LEFT       = 6;
static const int N64_BUTTON_RIGHT      = 7;
static const int N64_BUTTON_Z          = 8;
static const int N64_BUTTON_START      = 9;
static const int N64_BUTTON_DPAD_UP    = 12;
static const int N64_BUTTON_DPAD_RIGHT = 13;
static const int N64_BUTTON_DPAD_DOWN  = 14;
static const int N64_BUTTON_DPAD_LEFT  = 15;
// Axes
static const int N64_AXIS_X            = 0;
static const int N64_AXIS_Y            = 1;
static const int N64_AXIS_C_VERTICAL   = 2;
static const int N64_AXIS_C_HORIZONTAL = 3;
// Hats
static const int N64_HAT_DPAD          = 0;

Edited by diventurer, 26 June 2013 - 09:12 PM.


#6 Servant of the Lord   Crossbones+   -  Reputation: 25962

Like
0Likes
Like

Posted 26 June 2013 - 09:16 PM

Did they leave extra space for the attachments (rumblepack and such) that fit in the bottom of the controller?

The memory card I had for mine had a "Page up" and "page down" button for the four pages/memory-blocks of the card. I also had another card that had a four-position slider.


Edited by Servant of the Lord, 26 June 2013 - 09:17 PM.

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal | [Fly with me on Twitter


#7 swiftcoder   Senior Moderators   -  Reputation: 14270

Like
0Likes
Like

Posted 26 June 2013 - 09:22 PM


I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.

You must have a non-standard controller. The stock n64 controller has:

 

- a start button

- an A button

- a B button

- a central trigger

- 4 directional buttons

- 2 shoulder buttons

- a 4-way D-pad

 

For a total of 14 buttons.

 

Additionally, some controllers have Turbo and Slow buttons, which brings you up to 16.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#8 irbaboon   Members   -  Reputation: 1152

Like
0Likes
Like

Posted 26 June 2013 - 09:30 PM

 


I have another question by the way. Why does SDL say there are 16 buttons on the n64 controller when there's only 10.

You must have a non-standard controller. The stock n64 controller has:

 

- a start button

- an A button

- a B button

- a central trigger

- 4 directional buttons

- 2 shoulder buttons

- a 4-way D-pad

 

For a total of 14 buttons.

 

Additionally, some controllers have Turbo and Slow buttons, which brings you up to 16.

 

I have a normal N64 controller.

 

What's a "central trigger"? I don't have anything like that...

Also, the 4 C buttons doesn't work as buttons for me, I can only use the axes.

 

I guess it'd make sense what you explain though. Are you 100% certain the C buttons are buttons?

 

 

Did they leave extra space for the attachments (rumblepack and such) that fit in the bottom of the controller?

The memory card I had for mine had a "Page up" and "page down" button for the four pages/memory-blocks of the card. I also had another card that had a four-position slider.

I suppose what you and swiftcoder says about that might be correct. As I explain above, it still doesn't quite make sense for my controller though...


Edited by diventurer, 26 June 2013 - 09:31 PM.


#9 Servant of the Lord   Crossbones+   -  Reputation: 25962

Like
1Likes
Like

Posted 26 June 2013 - 10:11 PM

Or maybe this controller explains it? If the C-pad are axes instead of buttons, I count 16 there. Though that's not actually plugged into an N64, so maybe not. This implies that the C-pad are actually buttons, and that there are two unused spaces (that is, two spaces that the author of the article left blank, so maybe they are used but he just didn't know about it).

 

 


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal | [Fly with me on Twitter


#10 irbaboon   Members   -  Reputation: 1152

Like
0Likes
Like

Posted 26 June 2013 - 10:48 PM

I suppose the LodgeNet controller could explain it. Maybe Nintendo made support for 16 buttons on the original controller to make the LodgeNet controller easier to make. I don't know, is it a modified Nintendo 64 or just a TV that can play N64 games... I got a bit confused.

 

Anyway, the link you sent me doesn't really say the C-pad buttons are 'buttons', or am I missing something?

Even if they were, it's still not a better explanation than the LodgeNet controller, as that has 16 buttons in total.



#11 kburkhart84   Members   -  Reputation: 2106

Like
2Likes
Like

Posted 26 June 2013 - 11:16 PM

A suggestion I have is maybe somewhat farfetched, but may be easier to do than forcing the user to choose a specific controller.

 

If you can code it out, you can have the game player choose the buttons/axes directly.  I think for this you should not have the player choose a specific joystick.  Instead, have them click a button for each input "action(say jump, shoot, left, etc...) and then hit the key/button that they want to apply to that action.  Then, you go through checking all the inputs waiting for something to move.  Once the player hits a button(or hits a keyboard key), you set that button/key to that action, and when in the code for polling that action, you check that specific key.  This way, the player never has to mess with what joystick to use.  Also, they could easily in theory combine inputs from different devices, which could come in handy.  I've heard of some joystick devices that actually work as different devices, like driving wheels that come with separate pedals.  Windows would likely have these as separate devices, and if you limit your player to a single device at a time, they won't be able to use these devices very well.

 

As far as your input code, you would have to somehow identify each joystick/device.  This could easily be transparent to the game player though.  I assume that whatever code you are using returns some sort of handle to the devices.  There is no reason you can't use that kind of thing to identify the joysticks.  If you have access to the "names" of the joysticks, you could use those to identify the devices, but if not, a simple joystick 1 and joystick 2 could suffice, especially if the player is the one hitting the keys to choose inputs.  Also,if you get a good backend working, it is the kind of thing you can use in future projects, as input is something that once done right doesn't have to be changed much.

 

I have created a sort of system for input for GameMaker.  I won't give the GML code for it here, as you are not using GameMaker and it won't really work for you.  The way I do it is pretty simple code wise.  I have a separate program I made.  You use it to create a "default" input configuration.  You input how many actions your game is going to need.  Actions are things like "jump," "run," "left," "right," "open," etc...  Then a GUI appears for you to choose what input would be the default.  In general, for defaults, you should only use the default devices that a computer has, like the keyboard or mouse, since not all game players have other devices.  Then, you export a file that would be your "default" configuration.  In your game, you would normally load the current configuration, and then if it has not been created yet, load the default, and then resave it as the current configuration.

 

My code stores the inputs in a grid data structure.  It contains the device, the key(or joystick button), the current state of the input, and as extras, a couple values, for example if the key is "freshly pressed" or "freshly released" which only remain true for a single frame, and lastly a "time held" value, which is usually good for "charging" weapons, controlling jump height based on how long a button is held, etc....  Each frame, code goes through the whole grid and updates the values, polling the devices.  Then, the game code itself only calls the update function.  When you need to check if it is time for the player to shoot, you call code that checks action #1, assuming that #1 is the one you have set to "shoot."  You could also check instead for the "freshly pressed" value instead, in order to force the player to first release the key before shooting again, which would replace your "canShoot" variables.

 

This type of system is very versatile, and it can be upgraded to support any device you can read in code.  If you keep configurations in files, you can easily keep more than one.  Also, in my case, I have code that turns the grid into a string, so that you could save to your own file format.  This would be useful, for example, if instead of having a single "current" configuration, you could instead use that string to save the configuration along with player profiles, or something along that line.  You'd also keep around the default configuration file, or in my case the external "default configuration creator" can also copy the string to your clipboard, which you can paste into your code, so you don't have to keep an external file for it.

 

Anyway, I guess I've rambled on long enough.  Hopefully I have given you some ideas that you can use to create a robust input system for your games.





#12 irbaboon   Members   -  Reputation: 1152

Like
1Likes
Like

Posted 26 June 2013 - 11:32 PM

I am going to support configuring new controllers, but I still want to have preset controllers.

So that the user does not have to configure the controllers themselves. A better user experience basically.

 

I got an idea though, I can just have the XBOX360, Nintendo 64 and other presets in there, and when the user selects a controller, they have to specify what controller it is.

If it's a GameCube controller for example, they have to add a preset themselves, but if it's an XBOX360 controller, they can just select the 'XBOX360 preset'.

 

This could work out pretty well.

 

Anyway, thanks for your input on it, kburkhart84.
I'm not sure if you implied   what I just said   in your message, but I suppose this works best either way.


#13 kburkhart84   Members   -  Reputation: 2106

Like
0Likes
Like

Posted 26 June 2013 - 11:47 PM

If you want to have presets for certain joysticks, then that is fine.  The catch is is detecting for sure that the controller is that type of device, and so configuring controls.  If it is a single player game, and you use a system like mine, you could simply create defaults that use the device, instead of just using the controls.  My system makes no limitations on input configurations in that manner, and you can have as many files(or strings) for defaults as you want.  The input configuration program also receives all inputs for devices, as it uses the same code as the run-time part.  So even for my system, there is nothing that says you can't create default controls using devices other than keyboards if you wanted to.





#14 irbaboon   Members   -  Reputation: 1152

Like
0Likes
Like

Posted 27 June 2013 - 12:01 AM

Yeah, that's what I'm doing.

Right now you can add as many configurations as you want. The only problem is to set the presets automatically by detecting the controller.

What I'll do now is just make the user select what controller he has, and the game will then either select a preset or prompt user for a new.



#15 Anthony Serrano   Members   -  Reputation: 1812

Like
1Likes
Like

Posted 27 June 2013 - 01:18 AM

Yes, the C-buttons are in fact buttons. They don't appear that way to your code because your adapter is remapping the controller data so it more closely matches the standard gamepad layout, and is thus more readily compatible with existing PC games - which it might as well, as controllers for older consoles use transfer protocols that are completely incompatible with USB, so the controller data has to be translated anyway.

So it maps A and B to buttons 2 and 3 (typically the bottom and right face buttons), L and R to the left and right triggers, Z and Start to the mid-pad face buttons (back and start on the 360 layout), and the direction pad are mapped to the standard ids for the directional buttons.

It maps the analog stick to the axes normally used for the left stick, and the C buttons to the right stick - it also likely scales the analog sitck axes, because the N64 analog stick doesn't actually use the full range of values (the controller represents each axis as a signed byte, but they are mechanically constrained to the range of -81 to 81).

#16 irbaboon   Members   -  Reputation: 1152

Like
0Likes
Like

Posted 27 June 2013 - 01:39 AM

Yes, the C-buttons are in fact buttons. They don't appear that way to your code because your adapter is remapping the controller data so it more closely matches the standard gamepad layout, and is thus more readily compatible with existing PC games - which it might as well, as controllers for older consoles use transfer protocols that are completely incompatible with USB, so the controller data has to be translated anyway.

So it maps A and B to buttons 2 and 3 (typically the bottom and right face buttons), L and R to the left and right triggers, Z and Start to the mid-pad face buttons (back and start on the 360 layout), and the direction pad are mapped to the standard ids for the directional buttons.

It maps the analog stick to the axes normally used for the left stick, and the C buttons to the right stick - it also likely scales the analog sitck axes, because the N64 analog stick doesn't actually use the full range of values (the controller represents each axis as a signed byte, but they are mechanically constrained to the range of -81 to 81).

Thanks for your comment!

 

That explained some stuff.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS