[Kde-games-devel] Unavailable, Tagaro progress, sound APIs (again)
Stefan Majewsky
kdemailinglists at bethselamin.de
Fri Sep 10 09:53:52 CEST 2010
Am Donnerstag, 9. September 2010, 23:34:16 schrieb Parker Coates:
> I think a simple, Qt-style OpenAL library is probably the thing we
> need most technology-wise in KDEGames right now. While most of the
> goals of Tagaro seem to improve on solutions we already have, I think
> the lack of a good sound system is a major hole in our current
> offerings.
I did not check Phonon in detail yet, but I got OpenAL + libsndfile (which can
read WAV and Ogg/Vorbis) working in a test application. The libsndfile
dependency can be eliminated later, I first want something that works (esp.
because hacking with sound libs is quite difficult for unexperienced me: every
possible fault just results in no sound being played).
> Have you actually done an in depth review of GluonAudio? Is it really
> so bad that starting from scratch is preferable to a fork?
The GluonAudio API does not really abstract OpenAL, it's basically a C++
wrapper for OpenAL. As such, it uses OpenAL datatypes and, and it by and large
represents the OpenAL domain model.
However, no game developer will want to deal with selecting devices and
creating sound contexts. They want the default device, and be done.
After writing my test application, I wrote up an API sketch (see attachment),
which consists of two classes: an AudioScene singleton which has global
properties (it has to be a singleton because there is only one default sound
output), and a Sound class which loads and plays sound files. Loading and
playing a sound is just Tagaro::Sound(file).play()
I chose not to implement too much functionality. Games are not like sound
editing programs, they do not need most of the advanced API in OpenAL. The
only "exotic" OpenAL functionality I'm exposing is positional playback, which
I am very much interested in.
Of course, this API sketch is not finished (e.g. it misses a looping property
for background music). But instead of extending the API to exotic usecases
which need access to OpenAL internals (like buffers and sources), I would much
rather work on Qt integration from this point, like coupling positional
playback coordinates with QGV scene coordinates. OpenAL is by now completely
abstracted, and can be replaced by any other sound framework with low latency
and positional playback.
Greetings
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audioscene.h
Type: text/x-chdr
Size: 2418 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20100910/51d5ffa7/attachment-0002.h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sound.h
Type: text/x-chdr
Size: 5498 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20100910/51d5ffa7/attachment-0003.h
More information about the kde-games-devel
mailing list