The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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?

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.

Joseph


On Sat, Dec 28, 2013 at 08:35:14PM +0000, RodrigoCard wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:

On 12/28/2013 03:35 PM, RodrigoCard 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.

I don't have any controllers that support the iOS7 API, yet, either. but
apparently there are at least two on the market now.


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.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

if i start working on it, you will know.




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.





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.




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?




Agreed, also, there are no bluetooth ios controllers available yet.

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

On 12/29/13, 1:15 PM, Ryan C. Gordon wrote:

(Doh, one of the two existing controllers is non-extended.)

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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. :P

Joseph


On Wed, Jan 01, 2014 at 12:25:30AM -0500, Ryan C. Gordon wrote:
_______________________________________________
SDL mailing list

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 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?

On 4/18/14, RodrigoCard wrote:


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.



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.)


Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The game controller sdk on iOS supports both boolean modes and analog modes for buttons

https://developer.apple.com/library/ios/documentation/GameController/Reference/GCControllerButtonInput_Ref/Reference/Reference.html#//apple_ref/doc/uid/TP40013194

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.

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.



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!

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.



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/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:

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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 4/23/14, 4:48 PM, Sam Lantinga wrote:

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

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:



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 (!)

Also, you can read a property "isPressed" for all buttons (and Dpad) which returns true if there is something more than 15% or 25% of pressure, the buttons feel a bit mushy because of that (you can read the pressure values under 15% too, but it may be noisy).

According to a 9to5mac article back in January, all MFi controllers
on the market today use the same pressure-sensitive buttons from a
single supplier (I think it was Fujikura…) Controller developers had
NO lead time and basically did as much as possible following the
pre-approved formula. Which basically means they copied Apple's
prototypes as best they could to get a product on the shelf with as
little engineering time as they could.

So yes, the controls are actually analog on every MFi controller out
there today.

Unfortunately, because the current crop of controllers are all copies
of the prototypes with rushed engineering and testing, they all cost
too much and none feel like a quality first-party controller for iOS.
That'd take much longer to develop, test, and approve. Especially if
you needed to get the cost down at the same time.

I've got little desire for one of these first sloppy-feeling models
especially for the price. When newer models appear with more solid
feel and aimed more at the iPad, AppleTV, and the Mac… I'll pick one
up. I'm still not happy about the not-really-a-button pause, and the
analog DPad just cannot be a good idea, but any game plays well on
the controls it was designed for.

And Sony did an excellent job with the PS2 analog buttons, which were
mostly used as digital by games, so it can be done well…

Joseph


On Thu, Apr 24, 2014 at 09:28:35PM -0400, Ryan C. Gordon wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org