Anyone working on that?
I want to try to add support but is good to ask first to not waste work 
Also, any plans to separate accelerometer data from joystick lib?------------------------
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com
I haven’t got the means to develop on iOS at present. (I didn’t
actually fall off the planet, contrary to most appearances), but if
someone releases something appropriate for the Mac/iPad, I’d be more
interested in the API. I couldn’t even use the ones that are out
there right now with my iPhone because of the phone’s Survivor case,
boo!
Notably, the “start” button isn’t a button whose state you can read.
Pressing it fires off an event. We can cause this event to trigger a
make/break pair on Mac/iOS, I suppose.
JosephOn Sat, Dec 28, 2013 at 08:35:14PM +0000, RodrigoCard wrote:
Anyone working on that?
I want to try to add support but is good to ask first to not waste workAlso, any plans to separate accelerometer data from joystick lib?
Go for it!
I don’t have an iOS 7 supported joystick or gamepad but I’m very interested
in having support for it.
Also on the TODO list is a real sensor API, which should be pretty easy to
implement across iOS and Android, so if anybody wants to tackle that, go
ahead and post an API proposal.
Cheers,On Sat, Dec 28, 2013 at 12:35 PM, RodrigoCard wrote:
Anyone working on that?
I want to try to add support but is good to ask first to not waste work [image:
Smile]Also, any plans to separate accelerometer data from joystick lib?
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Anyone working on that?
I want to try to add support but is good to ask first to not waste work
It’s on my TODO list, but I’m not even close to starting on it. Let me
know if you get started, so we don’t overlap.
I don’t have any controllers that support the iOS7 API, yet, either. but
apparently there are at least two on the market now.
Also, any plans to separate accelerometer data from joystick lib?
In a perfect world, this works like this:
If -[GCController attachedToDevice] == YES, then we report this
controller as having rumble support and use the phone’s vibration for
it. The phone’s accelerometer can become extra axes, too, like a PS3
controller’s tilt sensors (but maybe it’s time to move accelerometers to
a new SDL API?) External bluetooth controllers exposed by iOS7 don’t
support the haptic API at all.
The start button is read differently than the rest of the buttons
(which is obnoxious), but they should all map to the same controller.
We hook this up as a valid SDL game controller, and accept that there
are a few buttons missing, since iOS is still a specialized platform. It
mostly works (no clickable analog sticks, etc). Maybe only export the
extended profile as a game controller, and leave the lesser profile as a
joystick only? I’m wondering if anyone will ship a non-extended device,
honestly.
We don’t bother hooking up the discovery API, since Apple wants your
game to build a UI around it, and you can use the System Preferences to
connect a bluetooth controller anyhow.
–ryan.On 12/28/2013 03:35 PM, RodrigoCard wrote:
Ryan C. Gordon wrote:
It’s on my TODO list, but I’m not even close to starting on it. Let me
know if you get started, so we don’t overlap.
if i start working on it, you will know.
Ryan C. Gordon wrote:
I don’t have any controllers that support the iOS7 API, yet, either. but
apparently there are at least two on the market now.
Yes, these two: http://www.theverge.com/2013/12/18/5220530/logitech-powershell-and-moga-ace-power-review
One of each profile, and there are no wireless controllers available, as far as I know.
I have a MOGA Ace Power.
Ryan C. Gordon wrote:
- If -[GCController attachedToDevice] == YES, then we report this
controller as having rumble support and use the phone’s vibration for
it. The phone’s accelerometer can become extra axes, too, like a PS3
controller’s tilt sensors (but maybe it’s time to move accelerometers to
a new SDL API?) External bluetooth controllers exposed by iOS7 don’t
support the haptic API at all.
Sam Lantinga wrote:
Also on the TODO list is a real sensor API, which should be pretty easy to implement across iOS and Android, so if anybody wants to tackle that, go ahead and post an API proposal.
I really think it should have a new API, accelerometers as joysticks never made sense in my opinion.
for now, that HINT that is used on Android should work.
About Phone vibration as Haptic, maybe it is a good idea, but haptic support would be useful without a controller too.
Ryan C. Gordon wrote:
- We hook this up as a valid SDL game controller, and accept that there
are a few buttons missing, since iOS is still a specialized platform. It
mostly works (no clickable analog sticks, etc). Maybe only export the
extended profile as a game controller, and leave the lesser profile as a
joystick only? I’m wondering if anyone will ship a non-extended device,
honestly.
the logitech one is a non-extended device. But, yeah, I would never get one of that.
a non-extended device would make sense in another form factor, with a case with slide-out gamepad like a Xperia Play, I think.
About Game Controller support, I agree.
But I was wondering, do you think SDL should have an API to get Button’s labels?
SDL already assumes a Xbox 360 layout, I think it shouldnt assume the Right Trigger is called RT in every controller.
What you think?
Ryan C. Gordon wrote:
- We don’t bother hooking up the discovery API, since Apple wants your
game to build a UI around it, and you can use the System Preferences to
connect a bluetooth controller anyhow.
Agreed, also, there are no bluetooth ios controllers available yet.------------------------
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com
hello everybody,
i have a question for a small problem.
There are demos for iOS delivered by the sdl mercurial. I want to use c++.
Building a demo without modification works, great!
How can I switch from C to C++. Multiple tries of me fails.
Does anybody know how to get this work?
Artem
(Doh, one of the two existing controllers is non-extended.)
–ryan.On 12/29/13, 1:15 PM, Ryan C. Gordon wrote:
I’m wondering if anyone will ship a non-extended device, honestly.
Even the non-extended protocol provides a DPad and A/B/X/Y/LB/RB,
along with an edge-trigger Start. I’d be MUCH happier if it were a
real button for Start and there were also a Select or Option button
we could map similarly to the XBox Back button (which basically
serves that function?) That’s give you a basic SNES-style controller
even in non-extended mode, which would make retro gamers very happy.
I also don’t know of any particularly intelligent way to determine if
some or all of those buttons are analog. It’s kind of like how SDL
handles XBox triggers: They might be analog, but you can’t guess
whether they are or not.
The suggestion that SDL should just assume they’re all digital and
leave it at that because digital is all most people want or care
about is somewhat irritating to my OCD. 
JosephOn Wed, Jan 01, 2014 at 12:25:30AM -0500, Ryan C. Gordon wrote:
On 12/29/13, 1:15 PM, Ryan C. Gordon wrote:
I’m wondering if anyone will ship a non-extended device, honestly.
(Doh, one of the two existing controllers is non-extended.)
–ryan.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Has there been any more development on this? If not, I’ll be taking a swing at it. I’m currently working on project for my software engineering class and iOS 7 joystick support would be nice for it. As it turns out there is an awesome jailbreak tweak (Controllers for All) that puts a PS4 controller driver on the device so it can be used with GameController.framework. I’ve read through the joystick and game controller code in the SDL repo, and its doesn’t look too difficult to implement and obey the existing convention. Just don’t want to do anything redundant…
Go for it! :)On Thu, Apr 17, 2014 at 9:56 AM, Teknoman117 <linux.robotdude at gmail.com>wrote:
Has there been any more development on this? If not, I’ll be taking a
swing at it. I’m currently working on project for my software engineering
class and iOS 7 joystick support would be nice for it. As it turns out
there is an awesome jailbreak tweak (Controllers for All) that puts a PS4
controller driver on the device so it can be used with
GameController.framework. I’ve read through the joystick and game
controller code in the SDL repo, and its doesn’t look too difficult to
implement and obey the existing convention. Just don’t want to do anything
redundant…
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
This is something I wanted to do but I am cannot, too busy. Got for it!
Just a question: how do you plan to suppot the buttons since ALL of them are analog?
Teknoman117 wrote:> Has there been any more development on this? If not, I’ll be taking a swing at it. I’m currently working on project for my software engineering class and iOS 7 joystick support would be nice for it. As it turns out there is an awesome jailbreak tweak (Controllers for All) that puts a PS4 controller driver on the device so it can be used with GameController.framework. I’ve read through the joystick and game controller code in the SDL repo, and its doesn’t look too difficult to implement and obey the existing convention. Just don’t want to do anything redundant…
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com
This is something I wanted to do but I am cannot, too busy. Got for it!
Just a question: how do you plan to suppot the buttons since ALL of them are
analog?
- Just read the “pressed” boolean and treat it like a digital button
anyway?
For all of those aware of ABI issues, please scrutinize this in case I
screwed up. But for analog buttons, I’m thinking there is enough
memory space in the SDL_event structure that we can add fields for
values and not break backwards compatibility.
The main SDL_event structure seems to have 56 bytes:
/* This is necessary for ABI compatibility between Visual C++ and GCC
Visual C++ will respect the push pack pragma and use 52 bytes for
this structure, and GCC will use the alignment of the largest datatype
within the union, which is 8 bytes.
So... we'll add padding to force the size to be 56 bytes for both.
*/
Uint8 padding[56];
I count 16 bytes for the SDL_ControllerButtonEvent. (I’m assuming this
already accounts for alignment padding, which in this case there isn’t
any.)
typedef struct SDL_ControllerButtonEvent
{
Uint32 type; /< ::SDL_CONTROLLERBUTTONDOWN or
::SDL_CONTROLLERBUTTONUP */
Uint32 timestamp;
SDL_JoystickID which; /< The joystick instance id */
Uint8 button; /< The controller button (SDL_GameControllerButton) */
Uint8 state; /< ::SDL_PRESSED or ::SDL_RELEASED */
Uint8 padding1;
Uint8 padding2;
} SDL_ControllerButtonEvent;
So we can add a double value to the end of this type. We should also
have enough space for another variable to denote if the button
actually supports analog button values or not.
typedef struct SDL_ControllerButtonEvent
{
Uint32 type; /< ::SDL_CONTROLLERBUTTONDOWN or
::SDL_CONTROLLERBUTTONUP */
Uint32 timestamp;
SDL_JoystickID which; /< The joystick instance id */
Uint8 button; /< The controller button (SDL_GameControllerButton) */
Uint8 state; /< ::SDL_PRESSED or ::SDL_RELEASED */
Uint8 padding1;
Uint8 padding2;
double analogState;
Uint8 supportsAnalog;
} SDL_ControllerButtonEvent;
So Uint8 state should return SDL_PRESSED or SDL_RELEASED as it does
now so existing SDL behavior will continue to work.
For those who want analog enhancements, they may use Uint8
supportsAnalog and double analogState.
Uint8 supportsAnalog will be 1 for buttons that are analog, and 0
otherwise. analogState which contains the normalized value between 0.0
and 1.0 where 1.0 is fully pressed and 0.0 is fully released.
The same may be applied to SDL_JoyButtonEvent.
- Let only the triggers be axes?
- treat them as both?
I’m not up to speed on triggers and axes, but it sounds like a real
problem I have today with my very old, but very awesome Gravis
Xterminator gamepad (Win95/98 era gamepad). There are several areas
that don’t work that really annoy me. The D-Pad on it provides axes,
but it looks like Steam Big Picture mode, it expects each direction to
be a button (and in fact doesn’t let me map the d-pad to anything).
Instead the HAT is the only thing I can map it to. But more relevant
to this talk, it has rear analog shoulder buttons which also register
as an axis. So in Steam Big Picture mode, I can only register the left
or the right side, but never both. If there is a way to fix both the
Apple controller problem and my legacy pad problem, I would love it.
As I said, I’m not up to speed on the problem, but I think I’m
gravitating towards “treat them as both”.
Since I hope to have experts scrutinizing this, I have two digressions…
First, why 56 bytes and not say a nice round power-of-two 64 bytes?
I’ve been dealing with custom events and I’ve had a few cases I really
would have liked a few more bytes. It seems like 64-bytes would
simplify the platform specific padding issues too.
Second, I noticed that SDL_GameController.h and SDL_RWops.h use
anonymous unions which are a C11 feature. This is giving me some
headaches with a compiler tool I’m using. Is there a way to change
this so it is C89/C90 compliant without breaking things?
(One more digression…my compiler tool is related to language bindings.
In a few cases, the ivars in the SDL structs use language keywords
which is a nuisance.)
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
RodrigoCard wrote:
This is something I wanted to do but I am cannot, too busy. Got for it!
Just a question: how do you plan to suppot the buttons since ALL of them are analog?
- Just read the “pressed” boolean and treat it like a digital button anyway?
- Let only the triggers be axes?
- treat them as both?
The game controller sdk on iOS supports both boolean modes and analog modes for buttons
So I’ll just map the relevant data into the SDL_ControllerButtonEvent structure. On the note of C11 issues with the code, the iOS compiler at this point is C11 compliant, and its Objective-C anyways, so anything C11 there won’t affect the rest of SDL.
Eric Wing wrote:
(…)
So we can add a double value to the end of this type. We should also
have enough space for another variable to denote if the button
actually supports analog button values or not.typedef struct SDL_ControllerButtonEvent
{
Uint32 type; /< ::SDL_CONTROLLERBUTTONDOWN or
::SDL_CONTROLLERBUTTONUP */
Uint32 timestamp;
SDL_JoystickID which; /< The joystick instance id */
Uint8 button; /< The controller button (SDL_GameControllerButton) */
Uint8 state; /< ::SDL_PRESSED or ::SDL_RELEASED */
Uint8 padding1;
Uint8 padding2;
double analogState;
Uint8 supportsAnalog;
} SDL_ControllerButtonEvent;So Uint8 state should return SDL_PRESSED or SDL_RELEASED as it does
now so existing SDL behavior will continue to work.
For those who want analog enhancements, they may use Uint8
supportsAnalog and double analogState.Uint8 supportsAnalog will be 1 for buttons that are analog, and 0
otherwise. analogState which contains the normalized value between 0.0
and 1.0 where 1.0 is fully pressed and 0.0 is fully released.The same may be applied to SDL_JoyButtonEvent.
(…)
pretty good solution, although there is no need to use a double value, most of the apis I saw (including the iOS Game Controller) uses floats already, so no need for extra precision.
Teknoman117 wrote:
RodrigoCard wrote:
This is something I wanted to do but I am cannot, too busy. Got for it!
Just a question: how do you plan to suppot the buttons since ALL of them are analog?
- Just read the “pressed” boolean and treat it like a digital button anyway?
- Let only the triggers be axes?
- treat them as both?
The game controller sdk on iOS supports both boolean modes and analog modes for buttons
So I’ll just map the relevant data into the SDL_ControllerButtonEvent structure. On the note of C11 issues with the code, the iOS compiler at this point is C11 compliant, and its Objective-C anyways, so anything C11 there won’t affect the rest of SDL.
Yeah I know that, I was reading the spec last week and wrote a simple controller testing app (should be available for free on the app store soon) and also was planning to include support for these controllers after that.
Just after I finished the app last week and submitted it a wild pokem… task appeared and took all the free time for the next weeks.
Just told you that just because reading the pressure values would be pretty useful for some games, at last for the triggers, which have more travel distance.
So mapping them (both triggers) to buttons and axes (as some controllers already do on some systems, including xbox controllers) is what I would do.
This, of course, if there is no API change as suggested by Eric Wing.
Just my 2 cents, I would love to see support for these controllers in any form, anyway. 
Cheers!> On 4/18/14, RodrigoCard <@Rodrigo_C_Rocha> wrote:
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com
pretty good solution, although there is no need to use a double value, most
of the apis I saw (including the iOS Game Controller) uses floats already,
so no need for extra precision.
I misremembered it. For some reason I thought Apple had picked doubles.
I realized that the “padding” variables are probably intended for our
use if we desire because these aren’t actually used for any logic. So
instead of adding a new variable for supportsAnalog, we should claim
padding1.
This shouldn’t break binary compatibility, though there might be some
minor compile time compatibility if anybody is using padding1 (which
they shouldn’t be). I think the only people who will be affected are
language bindings people who use automated tools (ironically, ths
affects me, and I’m probably the only one). But it’s an easy thing to
fix.
typedef struct SDL_ControllerButtonEvent
{
Uint32 type; /< ::SDL_CONTROLLERBUTTONDOWN or
::SDL_CONTROLLERBUTTONUP */
Uint32 timestamp;
SDL_JoystickID which; /< The joystick instance id /
Uint8 button; /< The controller button (SDL_GameControllerButton) */
Uint8 state; /< ::SDL_PRESSED or ::SDL_RELEASED /
Uint8 supportsAnalog; / Claimed! 0 for no, 1 for yes */
Uint8 padding2;
float analogState;
} SDL_ControllerButtonEvent;
One additional long term idea is that for all existing/non-analog
buttons, we go back and eventually set analogState to 1.0 for pressed
(and leave alone at 0.0 for released). This might be a nice
convenience for somebody writing analog intended code, but doesn’t
want to always have to check if supportsAnalog.
On the note of C11 issues with the code, the iOS compiler at this point is C11 compliant, and its Objective-C anyways, so anything C11 there won’t affect the rest of SDL.
This shouldn’t affect anything you are doing. This was a general point
I was hoping to get some attention on. The anonymous unions are in
public common header files. Not every compiler that touches them is
clang/gcc/C11 compliant unfortunately.
Thanks,
Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
I realized that the “padding” variables are probably intended for our
use if we desire because these aren’t actually used for any logic. So
instead of adding a new variable for supportsAnalog, we should claim
padding1.
I’m pretty sure they are there to round out the struct to 32-bit
alignment (there are two uint8 fields plus 2 uint8 padding fields).
Since there’s tons of space left in that event type vs the event union,
we can just add it to the end and not risk ABI breakage.
But I’m hesitant to add this at all: is there a value to showing the
standard buttons as anything than either pressed or released? I think
they probably decided this was better than making the triggers look like
an axis to the API?
–ryan.
In the SDL API, the triggers should be axes, to more cleanly map into the
SDL game controller API.On Tue, Apr 22, 2014 at 10:00 PM, Ryan C. Gordon wrote:
I realized that the “padding” variables are probably intended for our
use if we desire because these aren’t actually used for any logic. So
instead of adding a new variable for supportsAnalog, we should claim
padding1.I’m pretty sure they are there to round out the struct to 32-bit alignment
(there are two uint8 fields plus 2 uint8 padding fields).Since there’s tons of space left in that event type vs the event union, we
can just add it to the end and not risk ABI breakage.But I’m hesitant to add this at all: is there a value to showing the
standard buttons as anything than either pressed or released? I think they
probably decided this was better than making the triggers look like an axis
to the API?–ryan.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Message-ID: <535748D2.1020606 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedI realized that the “padding” variables are probably intended for our
use if we desire because these aren’t actually used for any logic. So
instead of adding a new variable for supportsAnalog, we should claim
padding1.I’m pretty sure they are there to round out the struct to 32-bit
alignment (there are two uint8 fields plus 2 uint8 padding fields).Since there’s tons of space left in that event type vs the event union,
we can just add it to the end and not risk ABI breakage.But I’m hesitant to add this at all: is there a value to showing the
standard buttons as anything than either pressed or released? I think
they probably decided this was better than making the triggers look like
an axis to the API?
This isn’t directly relevant to SDL, but when I eventually build a
full gui system, one of the core components will be involved in
converting all keypresses (including mouse & joystick buttons), and
axes (including both mice and joysticks) to arbitrary-length-number
representations, and throwing them through the event system as
absolutes or relatives, without drawing any distinction other than the
"logical axis" and source device. The purpose is fairly simple: to
allow widgets to request a set of capabilities, so that the “gui
driver” can dynamically provide whatever capabilities are requested
(i.e. providing a virtual-mouse for touch-only devices, a multi-touch
emulator interface for single-touch or non-touch devices, virtual
keyboards if there isn’t a physical one, using joysticks to invisibly
simulate mice & visa-versa, etc.).
Whether this should count as a vote in favor or against buttons & such
PREFERENTIALLY being represented with floats, I don’t know (honestly,
if the data’s available, then conversion is trivial, so I don’t really
care). What I do know is that if a button presents some sort of
analogue data, then SDL itself really should present that in some way,
even if the source is bizarre (e.g., if I converted a
pressure-sensitive synthesizer keyboard to act as a text keyboard, I’d
want a way to represent the pressure detection via standard event
fields, even if I had to custom-patch SDL to actually read the data:
this requires that such fields exist in the first place, which
although odd for keyboards, isn’t all that unreasonable for joypads &
similar). If SDL doesn’t present that data, then getting it in a
platform-agnostic manner will require another library for IO, thereby
raising the question of why SDL is being used, and rousing the specter
of the two libraries stepping on each other’s toes. This isn’t an
expansion of scope, but rather improving the coverage of the scope
that’s already being covered.> Date: Wed, 23 Apr 2014 01:00:02 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] iOS 7 Game Controllers support
Agreed, and further more: can someone with one of these controllers
write a quick test app and see if any of the non-trigger buttons report
anything other than 0.0 and 1.0? I’d be surprised if they do (hence my
thought that Apple simply didn’t want to call the triggers “axes” even
though they really are).
Thanks,
–ryan.On 4/23/14, 4:48 PM, Sam Lantinga wrote:
In the SDL API, the triggers should be axes, to more cleanly map into
the SDL game controller API.
Ryan C. Gordon wrote:> On 4/23/14, 4:48 PM, Sam Lantinga wrote:
In the SDL API, the triggers should be axes, to more cleanly map into
the SDL game controller API.Agreed, and further more: can someone with one of these controllers
write a quick test app and see if any of the non-trigger buttons report
anything other than 0.0 and 1.0? I’d be surprised if they do (hence my
thought that Apple simply didn’t want to call the triggers “axes” even
though they really are).Thanks,
–ryan.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Everything (really! even the Dpad, so they should be mapped to axes not a hat, right?) in these controllers are pressure sensitive.
Look:
Code:
#pragma pack(push, 1)
typedef struct {
// Standard information
uint16_t version; //0x0100
uint16_t size; //sizeof(GCExtendedGamepadSnapShotDataV100) or larger
// Extended gamepad data
// Axes in the range [-1.0, 1.0]
float_t dpadX;
float_t dpadY;
// Buttons in the range [0.0, 1.0]
float_t buttonA;
float_t buttonB;
float_t buttonX;
float_t buttonY;
float_t leftShoulder;
float_t rightShoulder;
// Axes in the range [-1.0, 1.0]
float_t leftThumbstickX;
float_t leftThumbstickY;
float_t rightThumbstickX;
float_t rightThumbstickY;
// Buttons in the range [0.0, 1.0]
float_t leftTrigger;
float_t rightTrigger;
} GCExtendedGamepadSnapShotDataV100;
#pragma pack(pop)
this is in the GCExtendedGamepadSnapshot.h (the non extended are all floats too)
And yes, I tested it myself with a MOGA Ace power, it really have pressure in all the buttons (!)
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com