Gamepad support (need testers with controllers)

gsynuh

Hi everyone, here's a video capture of the experimental gamepad support.
http://www.youtube.com/watch?v=uMx-QJfxGV8

(I know, doesn't look like a game, nothing significant is happening, no hero jumping over ennemies, sorry I didn't want to migrate my experiments to something else yet)

Before explaining, I'll ask for your help.
To include this in the next CE release I will need testers.
'Multi-player' is supported and I was able to plug in two different devices and have my GamepagManager manage them both, applying custom mapping to each one by reading the GameInputDevice name and assuming that if it reads "Xbox 360" it would load up the according map - or else load a default map I can decide. (its unclear if this would work nicely yet. only assumptions.

Anyway please sign up if you'd like to help.

read on if you need more info, or stop there.

This test was made using an xbox controller under windows so I've had no problem figuring things out, the only map I have is like custom made for myself so of course I cannot say if it will work for everyone or not.

I've used this document :
https://docs.google.com/spreadsheet/ccc?key=0AkkprH0hOE5cdGpmeDVTVFQ5M0syOGdXZ0xjVDJkSnc&usp=sharing#gid=1

I can't however test on MAC , linux or ouya.
nor do I have access to these other types of controllers for testing,
So I can implement the mappings mentioned on this spreadsheet - but can only assume that it would work without any proof.

If anyone is willing to help with testing then, please raise your controllers!

creating custom maps or understanding them will be very easy anyway (I tried to make this easy for everyone).

I'm reading Capabilities.version to initialize a map according to the platform Air is running in as that spreadsheet led me to think the windows/xbox360controller map would simply work differently on linux or map anyway.

As the gamepad manager sees a new device is added, it reads all controls, loads up either a default map you specify or fetch it from the CE package - I would very much like the developers to have all possible maps already done for them so that all this gets sorted out automatically.

each button or stick, becomes a custom InputController.
each newly added controller gets the next available input channel - you could set up two Hero, have each listen to a different channel and control them separately, keyboard or gamepad or virtual joystick or anything else you want, the input system after all, was created for just that in mind.

As any InputController, actions that are going to be triggered can be changed at any time for your player to be able to remap however he likes as long as you provide him with a menu to do so.

So here's how a 'map' looks like :

package citrus.input.controllers.gamepad.maps
{
	import citrus.input.controllers.gamepad.controls.StickControl;
	import citrus.input.controllers.gamepad.Gamepad;

	public class Xbox360GamepadMap extends GamePadMap
	{
		public function Xbox360GamepadMap():void
		{

		}

		override public function setupWIN():void
		{
			var joy:StickControl;

			joy = _gamepad.registerStick(GamePadMap.STICK_LEFT,"AXIS_1", "AXIS_0");
			joy.invertY = true; // AXIS_1 is inverted
			joy.threshold = 0.2;

			joy = _gamepad.registerStick(GamePadMap.STICK_RIGHT,"AXIS_3", "AXIS_2");
			joy.invertY = true; // AXIS_3 is inverted
			joy.threshold = 0.2;

			_gamepad.registerButton(GamePadMap.L1,"BUTTON_8");
			_gamepad.registerButton(GamePadMap.R1, "BUTTON_9");

			_gamepad.registerButton(GamePadMap.L2, "BUTTON_10");
			_gamepad.registerButton(GamePadMap.R2, "BUTTON_11");

			_gamepad.registerButton(GamePadMap.L3, "BUTTON_14");
			_gamepad.registerButton(GamePadMap.R3, "BUTTON_15");

			_gamepad.registerButton(GamePadMap.SELECT, "BUTTON_12");
			_gamepad.registerButton(GamePadMap.START, "BUTTON_13");

			_gamepad.registerButton(GamePadMap.DPAD_UP,"BUTTON_16","up");
			_gamepad.registerButton(GamePadMap.DPAD_DOWN,"BUTTON_17","down");
			_gamepad.registerButton(GamePadMap.DPAD_RIGHT,"BUTTON_19","right");
			_gamepad.registerButton(GamePadMap.DPAD_LEFT,"BUTTON_18","left");

			_gamepad.registerButton(GamePadMap.BUTTON_TOP, "BUTTON_7");
			_gamepad.registerButton(GamePadMap.BUTTON_RIGHT, "BUTTON_5");
			_gamepad.registerButton(GamePadMap.BUTTON_BOTTOM, "BUTTON_4");
			_gamepad.registerButton(GamePadMap.BUTTON_LEFT, "BUTTON_6");
		}

	}

}

setupWIN is called on a GamepadMap along with the GamePad object, when Capabilities.version 's 3 first chars are WIN of course. - I can add , the same way I do here, the mapping for MAC, LNX, AND by creating setupMAC, setupLNX and so on - I will just need you to test that out.

In my Main.as, before starting my state... I do the following to set up my custom actions for my "game":

var gamePadManager:GamePadManager = new GamePadManager(2, FreeboxGamepadMap); //2 players max, FreeboxGamepadMap will be the default map if nothing else found. this is the map of my other cheap controllers.

			gamePadManager.onControllerAdded.add(function(gamepad:Gamepad):void
				{
					gamepad.setStickActions(GamePadMap.STICK_LEFT, "up", "right", "down", "left");
					gamepad.setStickActions(GamePadMap.STICK_RIGHT, "zoomIncam", "rotateCam+", "zoomOutcam", "rotateCam-");

					gamepad.setButtonAction(GamePadMap.L1, "rotateCam-");
					gamepad.setButtonAction(GamePadMap.R1, "rotateCam+");

					gamepad.setButtonAction(GamePadMap.L2, "zoomOutcam");
					gamepad.setButtonAction(GamePadMap.R2, "zoomIncam");

					gamepad.setButtonAction(GamePadMap.L3, "addPoint");

					gamepad.setButtonAction(GamePadMap.BUTTON_BOTTOM, "addPoint");
					gamepad.setButtonAction(GamePadMap.BUTTON_RIGHT, "removePoint");

					gamepad.setButtonAction(GamePadMap.START, "start");
					gamepad.setButtonAction(GamePadMap.SELECT, "select");

					gamepad.debug = true;

				});

I so easily setup action for button or sticks.
This is done through a signal as there are some time before devices are actually attached (a second or so).

In the video, its mostly about navigation by moving the camera's target, rotating the camera or zooming in/out.
There's also that addPoint/removePoint because the state is a Qtree implementation test.

The gamepad overlay you see on screen has not been edited over. IT IS IN GAME - and I will probably give that system to you as well for debugging or visualizing stuff.

here's the "gamepad debug view hardcore code"; note that the graphic + all the buttons lighting up are in a .swc I'd be glad to share.

//in update
			var gamePad:Gamepad = GamePadManager.getInstance().getGamePadAt(0); //trying to get game pad of channel 0 (not available until properly added)
			if (!gamePad)
			{
				gamepadlayout.alpha = 0;
				return;
			}
			gamepadlayout.alpha = 0.7;
			gamepadlayout.L1.alpha = gamePad.getButton(GamePadMap.L1).value;
			gamepadlayout.R1.alpha = gamePad.getButton(GamePadMap.R1).value;
			gamepadlayout.L2.alpha = gamePad.getButton(GamePadMap.L2).value;
			gamepadlayout.R2.alpha = gamePad.getButton(GamePadMap.R2).value;
			gamepadlayout.L3.alpha = gamePad.getButton(GamePadMap.L3).value;
			gamepadlayout.R3.alpha = gamePad.getButton(GamePadMap.R3).value;
			gamepadlayout.SELECT.alpha = gamePad.getButton(GamePadMap.SELECT).value;
			gamepadlayout.START.alpha = gamePad.getButton(GamePadMap.START).value;
			gamepadlayout.BUTTON_TOP.alpha = gamePad.getButton(GamePadMap.BUTTON_TOP).value;
			gamepadlayout.BUTTON_BOTTOM.alpha = gamePad.getButton(GamePadMap.BUTTON_BOTTOM).value;
			gamepadlayout.BUTTON_LEFT.alpha = gamePad.getButton(GamePadMap.BUTTON_LEFT).value;
			gamepadlayout.BUTTON_RIGHT.alpha = gamePad.getButton(GamePadMap.BUTTON_RIGHT).value;
			gamepadlayout.DPAD_UP.alpha = gamePad.getButton(GamePadMap.DPAD_UP).value;
			gamepadlayout.DPAD_DOWN.alpha = gamePad.getButton(GamePadMap.DPAD_DOWN).value;
			gamepadlayout.DPAD_LEFT.alpha = gamePad.getButton(GamePadMap.DPAD_LEFT).value;
			gamepadlayout.DPAD_RIGHT.alpha = gamePad.getButton(GamePadMap.DPAD_RIGHT).value;

			gamepadlayout.LEFT_STICK_POINTER.alpha = gamePad.getStick(GamePadMap.STICK_LEFT).length;
			gamepadlayout.LEFT_STICK_POINTER.rotation = gamePad.getStick(GamePadMap.STICK_LEFT).angle * 180 / Math.PI + 90;
			gamepadlayout.RIGHT_STICK_POINTER.alpha = gamePad.getStick(GamePadMap.STICK_RIGHT).length;
			gamepadlayout.RIGHT_STICK_POINTER.rotation = gamePad.getStick(GamePadMap.STICK_RIGHT).angle * 180 / Math.PI + 90;

So what you can see from that is the simplicity to get values from controllers using their names - and the sticks provide us with angle and length (they also trigger actions when they are up/down/left/right with analog values of course.

Anyway I hope that's exciting , a bit.

I'll just need people to confirm things are working with other gamepads and platforms I'm not able to test on for the community to have a tool as complete as possible.

I'll provide a full test state source code with the gamepad overlay for debugging, no worries!

Edit 1:
using the latest source code, you can already try :

//Main.as
import citrus.input.controllers.gamepad.GamePadManager;
import citrus.input.controllers.gamepad.Gamepad;
import citrus.input.controllers.gamepad.maps.GamePadMap;

var gamePadManager:GamePadManager = new GamePadManager(2, null);	

gamePadManager.onControllerAdded.add(function(gamepad:Gamepad):void
{
gamepad.setStickActions(GamePadMap.STICK_LEFT, "up", "right", "down", "left");
gamepad.setButtonAction(GamePadMap.BUTTON_BOTTOM, "jump");
});

and the first added controller should be able to control your hero.

henke37

Quite sad that the already defined controller API still isn't usable. Bad job Adobe, bad job.

nobleRobot

I've done something very similar to tie existing CE input support to Adobe's GameInput API for my OUYA game. I do the same thing where I map each controller's inputs to the strings found in the same Google doc you cited.

I also use GameInputDevice.name to sort device type, although it feels a little clunky and unreliable. The name takes the form of a long and specific string ("Sony PLAYSTATION(R)3 Controller," for example), and I'm nervous that future versions of certain devices will have slightly modified strings. That said, there's seemingly no other way to determine what kind of device is attached.

My solution works well for me (seemlessly recognizes PS3, Xbox, and Ouya controllers on OUYA, as well as XInput on PC), but I'm sure it's not as robust a solution as this will be.

I'd be happy to test it for OUYA (with PS3, Xbox360, and OUYA controllers).

zeh

Quite sad that the already defined controller API still isn't usable. Bad job Adobe, bad job.

I disagree.

From my understanding, the GameInput API is a thin proxy between what the OS is telling applications. The OS tells Flash something called "button 5" or whatever is being pressed, and that's what we get through the GameInput API. And, unfortunately, the same device has different mappings from OS to OS. It's an arbitrary id. Flash never knows what "button 5" is, contextually.

When implementing the API, I believe Adobe had to choose between two routes:

A. Trying to understand what was being pressed, based on templated information, and then dispatching that instead (e.g. "the big action button"); or
B. Making the GameInput API simply forward whatever button/trigger/axis it saw being activated ("here, take 'button 5' and do something with it")

Solution A may sound great and super automatic, but it would require Adobe maintaining a list of devices that are "supported" by the API, and a lot of testing on their part (and people bitching when something isn't quite right). Solution B force developers to take the proper controller abstraction into their hands, but at the same time gives them as much control of the interface as they can want, allowing them to come up with an open solution of their own.

The spreadsheet can get out of hand, and it's still just a start, but I'd take that any time rather than trying to use one additional "gate" library that might not support everything I want it to.

Most developers (James D. Palmer, myself) came up with a similar solution to what CE is using. Given time, I'm sure it'll be the better route for everyone (I think it is already, but IMMV).

(Adobe has actually came up with one additional SWC that tries to simplify the control ids, but knowing Adobe's history and given how much attention they're giving to Flash support currently, I'd ignore it completely)

henke37

I am well aware of that issue. My complaint is far greater than the api being designed to work with any kind of controller.

I am complaining about the API flat out not being supported on any kind of AIR device type except "TV".

gsynuh

Hey henke37,

Since 3.8 (I think) It's available on 'desktop' that's why I decided to develop the system to work with CE.

If a contributor (Nick Pinkham) hadn't sent a working InputController to plug into the CE input system for the ouya gamepad, I wouldn't have realized it was finally available myself 😛

zeh

henke37: I'm not sure I understand. It works on Android 4+, OUYA, Windows and Macs with AIR 3.7+ and on Flash Player (in-browser) with FP 11.8+.

henke37

Strange, this is the first I hear about this. You'd think there would be an announcement for something as big as this.

hermesdavidms

yeah i can confirm that the game input api works on desktop since 3.7 i think

i have tested an old logitech dual action controller and a wired xbox 360 gamepad(using tattie bogie driver) on osx and windows, and yeah the mappings are different from windows mappings, but they stay like that, a controller will always have the same mapping, so if you use one mapping for windows and one for osx, i think you are good to go, that applies for highly popular controllers like the xbox or ps3 ones, but for generic ones you have to implement control customisation in your game.. just experiment

gsynuh

Hi everyone, I'll be focusing on a test state soon, I'm not destroying my gamepad instances properly, the code is probably the messiest code I've ever seen (no I've done worst) so I'll focus on that first.

I've been incredibly worried about that weird overhead that just freezes my test states for a couple of milliseconds (very noticeable even on the smallest of projects in my case) and if you encounter the same problem here's what I found (not hard to find actually) :
http://forums.adobe.com/message/5752379

edit: and I realized zeh was there 🙂

Unfortunately I'm still using 3.8, I guess I'll have to wait for 3.9 with the right fix.

So this reply/update is mostly for your information (and if you see huge spikes in your scout CC profiles its probably not my fault yet 🙂

zeh

@gsynyh: Yes, I bet they'll have a (proper) fix soon so by the time you're done it's possible it'll not be a problem anymore. So for now I'd simply ignore it. It's also such a massive overhead (200%+ of the time budget even with no other code or rendering being executed) that there's simply nothing to be done to try and avert it.

Smurfatron

I have an OUYA with two controllers and OSX, happy to help any way I can!

Aymeric

@Gsynuh AIR 3.9 is already released 😉

nobleRobot

Yeah. I started my current project this summer using AIR 3.6, and it's already at 3.9. The beta period for 3.9 seemed especially short. The AIR/Flash team moves fast.

I also have that Timer issue with my project when debugging on PC (although not on OUYA or vanilla Android), and it's still there even with 3.9.

Gsynuh, have you made your code available for testers yet? Your posts seem to imply that it's available somewhere, although I might be reading it wrong. Thanks!

Aymeric

You will find everything here: https://github.com/alamboley/Citrus-Engine/tree/master/src/citrus/input 😉

gsynuh

Hey nobleRobot,
Yes the classes are there, but don't consider it to be official , its not even close to alpha as I don't destroy my gamepad instances properly for example (throws errors) and I'm not sure about the structure and how I should let people have their own map/config... still it works as long as you don't disconnect your gamepad brutally for the moment. there might be other bugs, and the code might look horrible - I had trouble knowing if I should choose dictionnaries of vectors at some point and the system went through 3 very different versions (sorry if there is some nonsense left again).

if you have multiple game pads, the first one will be on channel 0, the second on channel 1 (careful if your os decides to attach them not in the order that you'd expect). I'm still planning on giving a nice example/demo with comments and even how to customize maps and so on, just so that the system is clear for testers.

GamePadManager is what you want to use (see the edit in my first post), do not instanciate GamePad yourself.

even if I don't expect much CE games to have multiple gamepads yet - I wanted to prepare for it anyway.

you still can get the GamePad instances from the GamePadManager by input channel or by index and then get the buttons or stick objects.

its still unclear to me what the best approach is.

GamePadManager,GamePad,buttons and sticks are all InputControllers , only the last two trigger actions. I just made the first two InputControllers to have them update along with the input and use the features input controllers had, though it makes no sense to have them extend it... like it makes no sense to have a Sprite handle simple logic and not be in the display list I guess.

So take it as a draft. I've got one report that the xbox controller works with it, so fine, now I have to focus on everything else and a cool demo so people get interested 😃

zeh

Just FYI - I've updated the spreadsheet with the PS4 controller inputs, since the PS4 controller works out-of-the-box as a gamepad in Windows 7.

It's basically reported as "Wireless Controller" (even though it's wired using a micro USB cable) with 24 inputs. The SHARE, OPTIONS, and PS buttons are mapped to GameInput controls, as is the trackpad (click only, no positional tracking). Working well!

gsynuh

Hey zeh, thank you very much for the update !

I see the latest 3.9 hasn't fixed that event issue though 😐

Jacowaco

This is GREAT! O_O

It worked perfectly with just copying those few lines of code. I can move the player with my USB joystick and it works great.

I tried to use 2 joystick but i haven't been able to make it work. I assigned one player to the input channel 0 and the other to 1, it works great with the keyboard but not with the Joysticks, one joystick moves both players and the other doesn't move any.

The methods getGamePadAt and getGamePadByChannel always give me null with any number.

gsynuh

Hi Jacowaco !

I can use 2 controllers, but not if they are of the same type. no matter what I tried, if I plug in my two generic USB controllers (either before the app starts or when its running), as the second one gets added the first one stops working and the second one triggers actions for the first one as well as his own (you can see that by tracing actions with trace(_input.getActions())

I checked device's ids I got from the event.CHANGE and did compare them to the gamepad object wrapping the controls, it doesn't make sense at all to me...

I suspected windows and my controllers first, but with any other software like joy2key or the xbox360 gamepad emulator, the two controllers are correctly differentiated.

So I'm either missing something big or Air doesn't like this.

When both are different (generic + xbox cause I didn't have 2 xbox controllers to try with) both are differentiated correctly, as before two gamepad objects are created, but the last added one doesn't control the first one, both work fine using its own channel.

This made me think I didn't have such a problem after all - I do not create the gamepad objects based on names, there cannot be a confusion there, I just use the name to apply a possible map and that's it (cause the only thing two controllers can have in common is their name... or they can be merged at some level by Air but I saw nothing in my code simply allowing that to happen)

thanks for the warning on getGamePadAt/ByChannel , I'll have a look at it. It worked for me as I'm using it for the demo (video) but there might be things I'm not considering in those, still have to look at the destruction as well (unplugging the gamepads). For the moment, focusing on my 3.1.8 to do list, the gamepads are part of it don't worry.