Awesome

InputCandy by Lost Astronaut

InputCandy focuses on providing input testing and customization for users of PC and gamepad-friendly platforms (consoles).

It's that classic "control setup" panel system you are accustomed to seeing in video games small and large, but for GameMaker.

It also is an object-oriented input API, with action matching, and a bunch of device detection features for keyboard, mouse and any SDL controller.

For GMS 2.3.1+

Always get the latest version from https://github.com/LAGameStudio/InputCandy See a bug? Submit an issue here, or better yet, a Pull Request.

Games Using InputCandy

Using InputCandy but not yet on this list? Submit your game via the Issues tab.

Games that have used or benefitted from or contributed to InputCandy:

• Circus Interstellar by EttinSoft @ https://steamcommunity.com/app/984030
• Popcorn Rocket by Battle Geek Plus, LLC ( https://www.battlegeekplus.com/ ) @ https://www.popcornrocket.com/
• 8-Bit Bakery by Shiphaven Games @ https://shiphavengames.com/
• Uncle Flip's Sky Frizz @ https://liminalist-contraptions.itch.io/

Asking Questions

If you need to ask the primary author a question, do so on the Lost Astronaut discord in the #inputcandy channel: https://discord.gg/PN6gS3CAEe

I have posted some additional code there to help people integrate InputCandy with their game. There are many ways to do it, so I've left it over there because you can come up with your own implementation or tie it into your own game in whatever way you choose.

If you have found an issue, simply create one here

Supporting InputCandy

If you download, use, or just simply like this library, please star the above Repo, it helps. :) If you use this library in your game, please add the provided Lost Astronaut and Image Candy logos to your startup screen if you wish to give back a little credit to the creators of InputCandy.

Likewise, we'd love to showcase any game you make with InputCandy here on this page, or in a file included with future versions of InputCandy, so please open an "Issue" and announce your game when it's available for others to play, and we'll include it.

Understanding the Situation

InputCandy is good for the following things:

1. Provides a quick way of supporting most controllers (mouse, keyboard, and broadly implemented gamepad support) for your game menus. Use InputCandySimple, or the MenuControls example for cross-platform VCS, PC and Linux support (below)
2. Provides a way for PC games to permit full Keyboard and Mouse customization. Use ICUI.
3. Provides a diagnostic feature useful on multiple platforms to troubleshoot what values are actually coming from a controller when you physically move it. Use rm_InputCandy_diagnostics
4. For local multiplayer ("couch" coop etc), InputCandy provides a way for users to select which player uses which controller.
5. Adapting to changing configurations
6. Remembering previous configurations
7. Provide a controller and mouse-friendly UI for customizing controls (ICUI)
8. Provide a way for users to see what their controllers are doing, and to test control schemes (ICUI's Test on Simulator)

However, in first writing and later using InputCandy, SDL and GameMaker, I can tell you the following nuggets of wisdom:

1. There is no reliable way to detect most controllers, including the most common ones like XBOX and PS4. This is because no one uses the GUID properly and third-party companies fake their GUID information or the GUID information returned to GameMaker is unreliable and differs per platform. The "Gamepad Description" is also not reliable.
2. Because there is no reliable way to detect most controllers, use of the SDLDB should be done so only in specific situations and is generally not recommended. It certainly cannot be automagically applied to detected gamepads without user confirmation and one of those "Reverting in 15 seconds..." screens like you see in the Windows desktop when you change resolutions.
3. Because there is no reliable way to detect most controllers, you may have to resort to checking "number of buttons, hats and axis" in specific cases which can result in false positives.
4. See Issue #2

Example Implementation

In my game, Apolune: Through the Wormhole, InputCandy user-customization of controls is used as a fallback, and before I implemented anything to do with InputCandy, I identified requirements:

1. The game targets PCs running Windows OR Linux, OR the VCS Console.
2. It would support a maximum of 8 players in local multiplayer.
3. The year of development is 2023, so it should support sane, contemporary controller default profiles without players having to use InputCandy at all. Those default profiles were determined by the target platforms. For Steam, the default would be supporting an XBOX controller, since this works well with the SteamDeck, is the most commonly used contemporary PC gamepad, and is most readily supported by GameMaker's default gamepad values. For Linux, I am aware that the axis values are centered on 0.5,0.5 not 0.0,0.0 as it is on Windows. The values range (on Linux) from 0 to 1, while on Windows they go from -1 to 1. Finally, I was targeting the Atari VCS Console, which has two possible native controllers, the VCS Classic and the VCS Modern.
4. I still wanted the option for players to be able to fully customize other USB controllers if they so choose.
5. It would allow connect and disconnect (hot swapping) of controllers. Allow meaning it will not crash.

Where InputCandy shines is not in the ability to detect controller manufacturers, but rather to detect if they are connected, and to assign them to players and remember that setting. It also works well when adjusting if a player has disconnected a controller during gameplay.

In point 2 above, I'm talking about profiles. What I mean is, specific implementations selectable by the player. While Issue #4 suggests InputCandy provide a formal way of handling this, as it stands in <1.0.0 versions, it is left up to you, the game developer, to handle this because it is really specific to what you are trying to accomplish, ie. what platforms and expectations you have of your user audience.

For example, I chose to support the XBOX Series X/S controller. It is wise to also support the PS4 Dual Shock controller. In 2023, these are the most likely controllers for the PC, not because the game is going to come out on those consoles. Additionally, I targeted 1 other platform, the Atari VCS Console, so I have support built in for the VCS Modern and the VCS Classic.

In my game controller menus, before it even reaches InputCandy, each of the 8 players has a default profile appropriate to the build platform. For Steam builds, it chooses XBOX, and for the VCS it chooses the VCS. Users then have the option of changing the profile to VCS (if they are using it on the VCS or on the PC with VCS hardware), XBOX (if they are using XBOX controllers on the VCS or on the PC), and PS4 (if they are using the PS4 controller), or CUSTOM, which is the InputCandy actions. Note that on the PC, CUSTOM is the default setting for Player 1 when no gamepads are selected, because they must not have a gamepad and need to use InputCandy to handle the keyboard actions.

InputCandy's "assign device to player" ICUI panel is used to allow for specific assignments. Each player has his/her own profile choice (VCS, XBOX, PS4 or CUSTOM). I then wrote a series of functions wrapped around various actions. When these functions are called, for example, CheckFireButtonForPlayer(player_number), it checks my game's settings to see which of the profiles has been chosen for the player. These settings are stored and handled separately from InputCandy's settings.

If CUSTOM is chosen, IC_Match is called, if XBOX, VCS or PS4 is chosen, it calls specific GML functions that will handle those activities. For Apolune: Through the Wormhole, the game is a top-down shooter, so it has the following:

• Primary (true if fire button held)
• Secondary (true if fire button 2 is held)
• Tertiary (true if fire button 3 is held)
• AimLeft (usually a left shoulder, aims the turret on the ship)
• AimRight (usually a right shoulder, aims the turret on the ship)
• Move (a combination of sticks, hats, and d-pads, depending on which gamepad or joystick)
• Menu (the "open menu" button, or the "pause" button, usually a burger, can also be "Select")
• Back (a general "cancel" button, or "back" on some gamepads)

For each of these functions, I check against the player's game settings. Here's an example for the CheckMenu function:

function CheckMenuButtonForPlayer(pn) {
	var hand=GetPlayerControllerProfile(pn);
	if ( hand == false ) return false; // This means no device is selected.  In the future, this may check keyboard only if it is the keyboard-using-player.
	var dv=hand.slot_id;
	if ( hand.slot_id != none ) {
		if ( isPlayerUsingVCSControls(pn) ) { // "VCS"
			if ( isPlayerUsingVCSClassic(pn) ) {
				return gamepad_button_check_released(dv,gp_face4);
			} else { // VCS Modern
				return gamepad_button_check_released(dv,gp_shoulderrb);
			}
		} else if ( isPlayerUsingXBOXControls(pn) ) { // "XBOX"
			return gamepad_button_check_released(dv,gp_start);
		} else if ( isPlayerUsingPS4Controls(pn) ) { // "PS4"
			return gamepad_button_check_released(dv,gp_start);
		} else if ( isPlayerUsingInputCandy(pn) ) { // "CUSTOM"
			return IC_Match(pn,global.game_actions.menu.index); // Calls InputCandy to test for action
		}
	} else if ( pn-1 == __INPUTCANDY.player_using_keyboard_mouse ) { 
		return IC_Match(pn,global.game_actions.menu.index);
 // This calls InputCandy to test for action.  In the future, this may check keyboard only if it is the keyboard-using-player.
	}
}

The way I went about figuring out how to program the above is by testing each controller on each platform using InputCandy's rm_InputCandy_diagnostics, and then writing a special case for each scenario that needed one.

Finally, I want to mention special considerations for the "Move" action. The "Move" action is complicated because I let the user use the d-pad OR the stick. It returns the following values in a struct:

	var result={
		combined: { x:0, y:0 },
		move2: { x:0, y:0 },
		move: { x:0, y:0 },
		angle: AXIS_NO_VALUE,
		angle2: AXIS_NO_VALUE,
		left: false,
		up: false,
		right: false,
		down: false,
		leftUp: false,
		leftDown: false,
		rightUp: false,
		rightDown: false,
		left2: false,
		up2: false,
		right2: false,
		down2: false,
		leftUp2: false,
		leftDown2: false,
		rightUp2: false,
		rightDown2: false,
		raw: false,
		raw2: false
	};

In the above struct, the player ship object has to interpret these controls to update ship parameters (speed, direction, etc). The combined value takes the "greater magnitude" of move2 and move vectors. Usually, the player will only be pressing one or the other, but they may be pressing both. It also returns the explicit values for both the move and move2 (d-pad and stick). For the VCS Classic, Move2 is never set so those all appear as false always and shouldn't affect anything else. The raw and raw2 values are the structs returned by global.IC.MatchDirectional(), aka the struct seen in global.ICI.New_ICMoving

MenuControls

You need a generic, broadly usable, keyboard-friendly, and game-controller-friendly way of navigating menus before the player is asked a single configuration question. This is the code I use in Apolune: Through the Wormhole to do this. It is used on all cutscenes, help panels, game menus, and the main menu. It has the ability to guess which player is doing the "accept" action. It also tries to indicate if a VCS controller is present. The MenuControls struct will return "release" signals for "left", "right", "up", "down", "back", "accept", and "cancel" - and you can also access globally the previous state via global.Menucontrols_old_results if you absolutely need to.

This code is built on top of InputCandySimple. It supports VCS, PC games and can be adapted to other consoles. This code is an example of the code used in Apolune: Through the Wormhole, and allows users to navigate game menus when the game first starts up. Using this they can navigate to a menu option that leads to the customization panels available in ICUI.

1. Create an object o_MenuControls.
2. In o_MenuControls:Create, call Init_MenuControls()
3. In o_MenuControls:BeginStep, call MenuControls_top_of_frame()
4. In o_MenuControls:PostDraw, call MenuControls_end_of_frame()
5. Include o_MenuControls in any room that will serve as your game menu, and optionally during any cut-scene movie or help screen.
6. In any object that controls your menus, cut-scenes or help panel, access in a Step by calling var controls=MenuControls();
7. Create a script called "MenuControls" and paste in the following:

#macro MenuControls_defaultresults  { left: false, right: false, up: false, down: false, accept: false, cancel: false, back: false, initiator: none, key_or_mouse: false, VCS: { moderns: [], classics: [], modern: false, classic: false } }
function MenuControls() {
	return global.MenuControls_final_results;
}

function Init_MenuControls() {
	global.ic_simple_controls=InputCandySimple();
	global.MenuControls_old_results=MenuControls_defaultresults;
	global.MenuControls_results=MenuControls_defaultresults;
	global.MenuControls_final_results=MenuControls_defaultresults;
	global.MenuControls_selection_changed=false;
	global.MenuControls_last_selected_by_controls=true;
	global.MenuControls_frame_delay=0;
	global.MenuControls_initiator=none;
	global.MenuControls_mousepos = { mx: mouse_x, my: mouse_y };
}

function MenuControls_top_of_frame() {
	global.MenuControls_initiator=none;
	if ( global.MenuControls_frame_delay > 0 ) {
		global.MenuControls_frame_delay -= 1;
	}
	var controls=global.ic_simple_controls;
	var devices=controls.devices();
	var results=MenuControls_defaultresults;
	var newmousepos= { mx: mouse_x, my: mouse_y };
	if ( global.MenuControls_mousepos.mx != newmousepos.mx
	  or global.MenuControls_mousepos.my != newmousepos.my ) {
		  global.MenuControls_last_selected_by_controls = false;
	}
	global.MenuControls_mousepos=newmousepos;
	for ( var i=0; i<devices.count; i++ ) {
		var dv=i;
		var pn=i+1;
		var VCS_modern=( devices.gamepad_names[dv] == "Atari Game Controller" 
			|| devices.gamepad_names[dv] == "Atari Controller"
			|| devices.gamepad_names[dv] == "Atari VCS Modern Controller"
			|| devices.gamepad_guids[dv] == "03000000503200000210000000000000"
			|| devices.gamepad_guids[dv] == "03000000503200000210000011010000"
			|| devices.gamepad_guids[dv] == "05000000503200000210000000000000"
			|| devices.gamepad_guids[dv] == "05000000503200000210000045010000"
			|| devices.gamepad_guids[dv] == "05000000503200000210000046010000"
			|| devices.gamepad_guids[dv] == "05000000503200000210000047010000"
			||  ( os_type == os_linux && ( gamepad_button_count(dv) == 11 && gamepad_hat_count(dv) == 1 && gamepad_axis_count(dv) == 6 ) )
			);		
		var VCS_classic=( devices.gamepad_names[dv] == "Classic Controller"
			|| devices.gamepad_names[dv] == "Atari Classic Controller"
			|| devices.gamepad_guids[dv] == "03000000503200000110000000000000"
			|| devices.gamepad_guids[dv] == "03000000503200000110000011010000"
			|| devices.gamepad_guids[dv] == "05000000503200000110000000000000"
			|| devices.gamepad_guids[dv] == "05000000503200000110000044010000"
			|| devices.gamepad_guids[dv] == "05000000503200000110000046010000"
			|| ( gamepad_button_count(dv) == 5 && gamepad_hat_count(dv) == 1 && gamepad_axis_count(dv) == 1 ) );
		if ( VCS_classic ) {
			results.accept |= gamepad_button_check(dv,gp_face1); if ( results.accept and results.initiator == none ) results.initiator=pn;
			results.cancel |= gamepad_button_check(dv,gp_face2);
			results.back |= gamepad_button_check(dv,gp_face3);
			if ( gamepad_hat_value(dv,0)&1 ) {
				results.up |= true;
			}
			if ( gamepad_hat_value(dv,0)&2 ) {
				results.right |= true;
			}
			if ( gamepad_hat_value(dv,0)&4 ) {
				results.down |= true;
			}
			if ( gamepad_hat_value(dv,0)&8 ) {
				results.left |= true;
			}
		} else if ( VCS_modern ) {
			results.accept |= controls.A(pn);  if ( results.accept and results.initiator == none ) results.initiator=pn;
			results.cancel |= controls.B(pn);
			results.back   |= gamepad_button_check(dv,gp_select) or gamepad_button_check(dv,gp_start);
			if ( gamepad_hat_value(dv,0)&1 || (os_type == os_linux && (gamepad_axis_value(dv,1) < 0.4 || gamepad_axis_value(dv,4) < 0.4)) || (os_type == os_windows && (gamepad_axis_value(dv,1) < -0.5 || gamepad_axis_value(dv,4) > 0.5)) ) {
				results.up |= true;
			}
			if ( gamepad_hat_value(dv,0)&2 || (os_type == os_linux && (gamepad_axis_value(dv,0) > 0.6 || gamepad_axis_value(dv,3) > 0.6)) || (os_type == os_windows && (gamepad_axis_value(dv,0) > 0.5 || gamepad_axis_value(dv,3) > 0.5)) ) {
				results.right |= true;
			}
			if ( gamepad_hat_value(dv,0)&8 || (os_type == os_linux && (gamepad_axis_value(dv,0) < 0.4 || gamepad_axis_value(dv,3) < 0.4)) || (os_type == os_windows && (gamepad_axis_value(dv,0) < -0.5 || gamepad_axis_value(dv,3) < -0.5)) ) {
				results.left |= true;
			}
			if ( gamepad_hat_value(dv,0)&4 || (os_type == os_linux && (gamepad_axis_value(dv,1) > 0.6 || gamepad_axis_value(dv,4) > 0.6)) || (os_type == os_windows && (gamepad_axis_value(dv,1) > 0.5 || gamepad_axis_value(dv,4) < -0.5)) ) {
				results.down |= true;
			}
		} else {
			results.left   |= controls.left(pn);
			results.right  |= controls.right(pn);
			results.up     |= controls.up(pn);
			results.down   |= controls.down(pn);
			results.accept |= controls.A(pn); if ( results.accept and results.initiator == none ) results.initiator=pn;
			results.cancel |= controls.B(pn);
			results.back   |= gamepad_button_check(dv,gp_select) or keyboard_check(vk_escape);
		}
		results.VCS.moderns[i]=VCS_modern;
		results.VCS.classics[i]=VCS_classic;
		results.VCS.modern |= VCS_modern;
		results.VCS.classic |= VCS_classic;
	}
	var key_or_mouse_accept = keyboard_check(vk_enter) or keyboard_check(vk_control) or mouse_check_button(mb_left);
	results.accept |= key_or_mouse_accept; if ( key_or_mouse_accept ) results.initiator=1;
	results.cancel |= mouse_check_button(mb_right);
	results.back |= mouse_check_button(mb_middle);
	global.MenuControls_results=results;
	var old_results=global.MenuControls_old_results;
	var final_results=MenuControls_defaultresults;
	final_results.left   = !results.left   and old_results.left;
	final_results.right  = !results.right  and old_results.right;
	final_results.up     = !results.up     and old_results.up;
	final_results.down   = !results.down   and old_results.down;
	final_results.accept = !results.accept and old_results.accept;
	final_results.cancel = !results.cancel and old_results.cancel;
	final_results.back   = !results.back   and old_results.back;
	final_results.VCS    = results.VCS;
	final_results.key_or_mouse = key_or_mouse_accept;
	if ( final_results.accept ) global.MenuControls_initiator = old_results.initiator;
	global.MenuControls_final_results=final_results;	
}

function MenuControls_end_of_frame() {
	global.MenuControls_old_results=global.MenuControls_results;
	global.MenuControls_selection_changed=false;
	global.ANIMTIME += global.dt;
}

Using InputCandy

You can use InputCandy in pieces or as a whole.

It currently does not handle multitouch, screen reorientation, platform-specific scenarios beyond gamepads.

InputCandy makes it easier to use input in GameMaker and does all of the "settings" and "selection" for you, so you can easily import these features into other projects. It was first written by LostAstronaut.com for use with their games.

It's important to note that this is for detecting momentary actions, not for detecting textual input ("typing"). It treats mice, keyboard and gamepad input as "button states"

InputCandy has two modes:

• NES-style simple mode, which works on a variety of devices and requires no setup but has a limited number of inputs, and works with certain assumptions

To access Simple mode, see the script InputCandySimple included in the package. It's one function, so you don't have to import all the other stuff.

• Advanced, verbose player-configured mode which allows for a lot of freedom but requires setup by the player

A Notes file contains Advanced mode information. You want to use this if you want wider support for the gamepad, and the ability to allow players to set their own control schemes.

What is InputCandy Advanced Good For?

InputCandy "Advanced" is split into several components:

• InputCandy, the main ball of wax that handles the major features of designer-provided Actions, player-provided Settings, trackable Players (did they start yet? which controller are they using?), Devices (gamepads, keyboard, mouse), Signals (from devices) and a few other useful things.
• ICUI, the InputCandy User Interface, a style-able complete UI solution for selecting, configuring and simulating game control apparatus
• SDLDB, a library for reading, parsing, and providing access to SDL GameController DB files (a recent one is included, or you may update it)

InputCandy comes with:

• A simple version (with simple diagnostics) for quick use
• A diagnostics screen that inspects game inputs
• A single room with multiple panels that shows off ICUI
• A test game
• A "Gamepad Keyboard" similar to the old Nintendo games for high-score entry

InputCandy is good for:

• Multiplayer hot-seat games that use controllers
• Console games
• PC games with USB SDL-compatible PC game controllers and mouse/keyboard games
• Simplifying your work with control schemas
• Allowing players to rebind controls
• Allowing players to take advantage of the SDL Game Controller DB

If you are going to use SDLDB, and you are testing with devices that don't map or have no DB entry, developers on the GameMaker Discord emphatically encourages you to submit a Pull Request to the SDL Gamecontroller Database at https://github.com/gabomdq/SDL_GameControllerDB

Note that the use of the SDLDB is turned off by default as it may have undesired consequences and is not really necessary if the player is going to be permitted to remap input by use of device testing/capture or input selection.

Input Device Control Concept Diagram

The following diagram illustrates the basic relationships of major concepts found in GameMaker, SDL, and InputCandy. It is not a complete architecture diagram but is simple enough, yet complex enough, to illustrate how everything is connected in InputCandy.

The bottom of this chart (above), the nodes labeled Actions, Settings, Players, are the exposed surface of InputCandy that you, as a game developer, can choose to limit yourself to when implementing InputCandy as your control layer. You create Actions, in turn, you attempt to match them, and you choose when to go about the activation and deactivation of Players. If you use the packaged ICUI helpers, then players create Settings (and bindings) as needed and can access the SDLDB if you load that component.

By matching "actions", players can influence the behavior of the game, which is "fun" for the player. A very dry way to explain user experience, but this is the gist of it.

Feature List

• Organizes devices, states, and signals into structures in memory for quick access
• Assigns devices by player
• Normalizes buttons, keys and mouse clicks as "signals"
• Provides an "Action" dictionary method to decouple controller signals from game actions
• Provides diagnostic tools (rm_InputCandy_diagnostic_test)
• Timed impulses for handling vibration effects
• Provides a controller setup room that can be styled for your game (rm_InputCandy_settings)
• Provides a player selection room that can be repurposed for your game (rm_InputCandy_player_selection)
  • Allows players to assign who uses what controller
  • Allows players to reprogram the controls from a default suggested setup
  • Allow players to save and load controller schemes easily
  • Allows players to access SDL controller database remappers. Can also "grab from web" latest DB
• Simple network control information transmission (TODO)

Support Table

The following table illustrates the support level for each device type by the InputCandy framework.

In the above table, I'm trying to illustrate that, if you are making a single-player game for a touch device, this probably isn't the library for you. If you want to support multiple controllers and user-defined control bindings, and you want to also support the keyboard and mouse, this library is probably for you. It's tailored to support physical controllers, mouse+keyboard, on the PC and consoles. It's not really for mobile, but it might help with physical controllers supported by mobile devices and tablets.

As an alternative, there are many on GitHub. You may like https://github.com/JujuAdams/input/ which purports to be "Comprehensive cross-platform input for GameMaker Studio 2.3.0" and seems to support mobile and web more extensively.

InputCandy's default settings panels for your games can be accessed directly or by calling the base panel. This allows you to divide up the UI as you desire. The UI also smartly turns off features when they have no value. You'll never see a menu with one option, for example.

The default panels that are all interconnected are as follows:

• Picking a player-device association that shows the "best guess" image of your joystick or gamepad
• Player-device menu (basic device info includes access to other sub-panels and options like choose your SDL DB string)
• "Binding and re-binding the input" panel, which includes load/save bindings options
• Gamepad simulator (TODO)

Hardware Testing Notes

Advanced features of the library have been tested on a windows PC with the following devices attached:

- Retrolink N64 Style Classic Controller for PC ($3.99)
- X-Box 360 Wired USB Red Controller ($12.95) 
	- Stick-press did not register on right stick
	- Stick-press on left stick only worked when stick was slightly up-left
	- Supported vibration
	- Cannot detect X button  
- Modern XBOX Controller (X or S series) ($49.95)
	- Generally maps correctly to most GameMaker defaults
 		- Left trigger registers as "Buttons[10]" and has a range of 0.0 - 0.30 (fully pulled)
   		- Underneath micro buttons do not register (cannot read value)
 	- Left/right switch control on LED illuminated did not register (cannot read value)
	- Cannot detect X button
    - PS4 Dual Shock (in progress)
- Tomee USB Controller for PC/PS3 (PS3-style controller) ($19.99)
	- Both stick-presses registered properly
	- Triggers registered as shoulders and shoulders registered as triggers
- LUXMO SNES Wired USB Controller for PC ($7.99)
- ATARI VCS Classic Controller (not in a special mode)
- ATARI VCS Modern Controller (not in a special mode)
- Mouse, Keyboard

Note that initial testing did not use any SDL remapping.

I personally recommend the Tomee USB Controller (PS3-style) for anyone looking to get a nice controller, though other brands of the same style (PS3) may be just as good and you can get them in 2.4Ghz and other forms of wireless (Bluetooth and others). This stick offered the most options and was easy to use, had good tactile feedback and some versions of the PS3 for PC support rumble vibration. The one I had didn't.

Buttons labeled by InputCandy (and GameMaker) don't always match, for example: "A" (gp_face1) may not be labeled as such on any controller. The Retrolink N64-style controller makes A one of the yellow arrow buttons. SNES-style controller may label its button "X" to "A"

At some point we'll test on Xbox. Right now it is mainly tested on PCs. Volunteer to test for us! File an Issue after you do so.

Project Roadmap

Remaining Progress Toward 1.0.0

This table lists the remaining action items to be included in the 1.0.0 release.

Beyond 1.0.0

See the Notes > Note1.txt that is included in the project for more information on how to use this library.