Can't play sound

Hello,

I tried to play a file using the SDL Audio API. It’s a simple wav file
so I do not need to use SDL_mixer right now.

This is the code that try to play the file :

http://markand.malikania.fr/player.c

It works because the code loops at line 66 and exit when the conditional
is over, but there is no sound.

The file I try to play is obviously working.

Here is the main calling these functions :

http://markand.malikania.fr/audiogen.c

Cheers,–
David Demelier

It has become important in my engine to support the Xbox 360 Controller For Windows, the API for this focuses on a single function (XInputGetState) which is much simpler than the SDL_Joystick API, and
is stateless by nature (calling this function yields a timestamped state struct, or tells you the controller is unplugged, or an error code), which makes it easy to develop games supporting this
controller in particular on Windows.

SDL 1.3 does not currently support the Windows XInput API necessary to support this controller (using it via DirectInput exposes the triggers incorrectly, aside from also lacking rumble and headset
capabilities), so I have begun implementing my own support in my engine in the interim.

At this point I took a step back and realized that there are certain market-dominating controllers (360, PS3, Wii, etc) that users greatly enjoy using with their games and fully expect them to work on
all platforms without any kind of ingame configuration menu, the burden of supporting these specific gamepads in an app is actually less than dealing with the common case of axes+balls+buttons, but
supporting each controller on each platform with different mappings is a major burden.

My proposal consists of these somewhat unrelated parts:

  1. A simple function that fills in a user-supplied state struct with new information (bumps timestamp if anything has changed, updates axes/balls/buttons, controller status - unplugged/error/active),
    this function would be an alternative to the SDL_Joystick API with significantly less burden on both the app and the SDL implementation itself, this struct would be somewhat large but only portions of
    it are updated (according to the number of balls/axes/buttons on this controller), and accommodates hotplugging controllers if the app periodically polls for additional controllers.

  2. Specific controllers having guaranteed mappings on all platforms; if state.controllerType == SDL_CONTROLLER_TYPE_360 then you can be sure that .buttons[SDL_CONTROLLER_360_A] is the A button on a
    360 controller.

  3. it would be possible to expose virtual controller mappings through this API, like keyboard + mouse as a single cohesive device consisting of axes and buttons (treating keys by physical position,
    not by letter), so the user could pick keyboard+mouse or 360 controller or ps3 controller or wii controller in the menu, all would be enumerated appropriately and could be configured by the same
    mechanism, and it is an important observation that the keyboard+mouse choice may be absent on some platforms (like a mobile phone or tablet), thus indicating to the app that this would be a poor
    choice of control scheme and it should fall back to one of the other detected controllers (such as a touchscreen).

Expected result:
An SDL app can implement support for the 360 controller, and get expected results on most platforms, telling the user that their controller has been detected and configured automatically, and offering
the option of a custom configuration if desired by the user.

Generally the app would implement this by having a table of mappings to in-game controls for each known controller, and let the user make a custom mapping if desired (in .ini file format or a
graphical menu).

The majority of SDL apps that support controllers at all, would support all common controllers with a minimum of effort.

Comments?–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

What dependencies would such a library/function have on SDL? Could it
be implemented in a stand-alone library, or as a SDL add-on library?

Regards,
– Brian

As I envisioned it, no additional dependencies.

Conventional gamepads in general do not require unusual dependencies, Windows XInput needs to be detected optionally (as are many other Windows libraries).

Perhaps Wii controllers require more effort, but I know nothing about supporting them at the moment.On 05/18/2011 02:38 AM, Brian Barrett wrote:

What dependencies would such a library/function have on SDL? Could it
be implemented in a stand-alone library, or as a SDL add-on library?

Regards,
– Brian


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

At this point I took a step back and realized that there are certain
market-dominating controllers (360, PS3, Wii, etc) that users greatly
enjoy using with their games and fully expect them to work on all
platforms without any kind of ingame configuration menu, the burden of
supporting these specific gamepads in an app is actually less than
dealing with the common case of axes+balls+buttons, but supporting each
controller on each platform with different mappings is a major burden.

Fwiw, I’ve had publishers ask that Mac ports of their games notice the
presence of an Xbox360 controller and automatically configure the game
for it (show certain colored buttons in the tutorials, know that a given
axis maps to a given stick, etc).

I don’t think a big abstraction is worth the effort, though; I imagine
there is a small but measurable market for Xbox360 controllers on PCs,
but there isn’t for Sixaxis or Wiimote controllers. And it assumes
gamers and developers will care about the 360 controller in five years
(it’s not like the GameCube and Wii controllers are in any way
analogous, for example; we can’t predict the next gen devices).

On instinct, I’d say the right approach is for SDL to add XInput support
internally, and for an app is to use the existing SDL joystick API, and
look for the joystick name to match the string the 360 controller
reports…if it shows up, make your own decisions about what axis does
what without prompting the user.

Proper controller hotplugging is planned for SDL 1.3. It’s not great in
1.2, where you basically have to reboot the joystick subsystem to
redetect and hope for the best. This will be great for bulletproofing
your games, but I’m not sure it’s a high-demand feature in any case.

If you want the big abstraction, you should probably build a separate
library for it. And expect to maintain it as new devices become
important. But apps are still going to have to provide logic to deal
with these controllers (and generic, no-name controllers), so I’m not
sure that a new API adds much value.

–ryan.

Fwiw, I’ve had publishers ask that Mac ports of their games notice the presence of an Xbox360 controller and automatically configure the game for it (show certain colored buttons in the tutorials,
know that a given axis maps to a given stick, etc).

Granted, it’s pretty much the xbox360 controller I’m thinking of, and that may be the only one with “significance” in this role; it is specifically sold as a PC controller and has sold very well, with
user expectations that it “Just Works” with everything, the others have no official drivers, to say nothing of intended purpose.

On instinct, I’d say the right approach is for SDL to add XInput support internally, and for an app is to use the existing SDL joystick API, and look for the joystick name to match the string the 360
controller reports…if it shows up, make your own decisions about what axis does what without prompting the user.

I am in complete agreement except for one point - it would be nice to have documentation of what button/axis layout the xbox360 controller appears as on Windows, OSX, and Linux, so that an app can
rely on the SDL docs when typing in their respective default mappings on these three platforms.

Proper controller hotplugging is planned for SDL 1.3. It’s not great in 1.2, where you basically have to reboot the joystick subsystem to redetect and hope for the best. This will be great for
bulletproofing your games, but I’m not sure it’s a high-demand feature in any case.

Hotplugging is not even present in many of the games I’ve seen on PC with support for the xbox360 controller, often having to restart the game if one unplugs or plugs in a controller. So this may be
a case of "well everyone else does it wrong, too."On 05/18/2011 10:15 PM, Ryan C. Gordon wrote:


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Hello !

Fwiw, I’ve had publishers ask that Mac ports of their games notice
the presence of an Xbox360 controller and automatically configure the
game for it (show certain colored buttons in the tutorials,
know that a given axis maps to a given stick, etc).

Granted, it’s pretty much the xbox360 controller I’m thinking of, and
that may be the only one with “significance” in this role; it is
specifically sold as a PC controller and has sold very well, with
user
expectations that it “Just Works” with everything, the others have no
official drivers, to say nothing of intended purpose.

I agree the XBOX 360 controller is the defacto gamepad on the PC now.

In the earlier days people had connected their PS1 or PS2 pads to the
pc
with adapters, but in the last years, because of the success of the
xbox 360,
its gamepad is the new standard on the pc.

Also gamemakers have an easy time, okay we had that function on that
button on the xbox360
and we do the same on the pc now.

CU