Multiplatform Input and Sound API's
Author
Ok, simple question. I am learning OpenGL and plan to use it to make games. But as far as I know, OpenGL doesn't have any input/sound functions. Can someone suggest to me a good, powerful, multi-platform API for input/sound. Thanks.
For sound you can't really beat FMOD, provided you're not working on a commercial game.
If you're looking for input and sound in one library, SDL is the only one that comes to mind (although you'll still need to use additional libaries if you want full support for streaming music from mp3/ogg/etc).
If you're looking for input and sound in one library, SDL is the only one that comes to mind (although you'll still need to use additional libaries if you want full support for streaming music from mp3/ogg/etc).
Author
I make commercial games. If SDL has everything in one, I'll probably get it. It uses C++ probably. I'll check it out. Also, if anyone has anything for using actual C++ for sound and input, that would be even more helpful since I'd have full rights and can port it to a system with only OpenGL. I don't even know if I need that, but just in case. Thanks for the help.
SDL (and it's optional support libraries like SDL_mixer and SDL_net) is written in C, so no C++ API or anything like that. Not too hard to interface with a C++ app though, IMO.
What does SDL use internally on the Win32 platform to implement input? Another input option that I was seriously considering for a while was OIS, however it uses DirectInput for it's Win32 implementation.
Author
Ok, one other thing. I downloaded OpenAL and SDL, but I can't figure out how to install them on Windows XP with Visual Studios Express Edition 2005. Any tutorials on how to use those API's and install them, with OpenGL, preferably videos, would be very helpful. Thank you for your responses!
Quote:Original post by Nairou
What does SDL use internally on the Win32 platform to implement input? Another input option that I was seriously considering for a while was OIS, however it uses DirectInput for it's Win32 implementation.
Why is that a problem? At some point it's got to use OS specific API calls.
This describes my reasons for avoiding DirectInput. I've already created a DirectInput wrapper in the past, and am in the process of rewriting it from scratch.
I agree that all input libraries will have to end up making OS API calls for input, but I'd prefer it did so using windows messages (i.e. WM_INPUT) and had a library API that allowed for both high-precision relative movement and key state as well as screen position and text entry. It is very difficult to accomplish both using DirectInput, but fairly simple if it uses messages.
I agree that all input libraries will have to end up making OS API calls for input, but I'd prefer it did so using windows messages (i.e. WM_INPUT) and had a library API that allowed for both high-precision relative movement and key state as well as screen position and text entry. It is very difficult to accomplish both using DirectInput, but fairly simple if it uses messages.
Quote:Original post by Nairou
This describes my reasons for avoiding DirectInput. I've already created a DirectInput wrapper in the past, and am in the process of rewriting it from scratch.
I agree that all input libraries will have to end up making OS API calls for input, but I'd prefer it did so using windows messages (i.e. WM_INPUT) and had a library API that allowed for both high-precision relative movement and key state as well as screen position and text entry. It is very difficult to accomplish both using DirectInput, but fairly simple if it uses messages.
Ah I see. So I guess that means DirectInput is basically deprecated? Considering there's even a Microsoft article saying there's not much point in using it, except for joystick support.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
