Jiba a écrit :
It would be "strange" to make pygame become a dependency of Soya only to
use its sound part.
Sure.
Another thing is that pysdl_mixer emulates 3D
sound. Is it a feature of pygame?
Not really (the pygame_sound4soya.py module is not really 3D sound).
OpenAL is to me the best choice to play sounds with Soya. I think that
Windows user should focus on the way to make PyOpenAL really
cross-platform, instead of using third-party sound libraries : a
complete rewrite of PyOpenAL with Pyrex could be the solution. Any
volunteer?
I'm also thinking to a new sound API, which would integrate OpenAL directly in
Soya. It would allow to link directly to OpenAL (which ease OpenAL access since
we don't need all the bunch of OpenAL function) and also to link directly to
libOgg / libVorbis (PyOgg and PyVorbis are known to be slow).
This new API would consider sound just as any 3D object (inheriting from
CoordSyst) ; as a consequence, a sound being played would be saveable in a
file, and could then be reloaded.
However, this is probably not a short-term project ; any comments are welcome.
Jiba
I totally agree with you : all dependencies have to be integrated in
Soya as deeply as possible, to offer end-user only one developpement
library : a game engine named Soya. Soya users should not have to worry
about whether it is OpenAl or pysdl_mixer that provides sound support.
Their need is a 3D object that can emit/receive 3D sound.
I read a post, a couple of weeks ago(may be it was you, Jiba), dealing
with the way ODE was integrated in Soya. The subjet was something like :
why don't we use ODE python binding (pyODE)? Anyway, Soya developpement
allows 2 differents way to use Sound/Physics/Multimedia libraires:
1/ make a Python binding from C code. Use this binding through a python
script in Soya : pysdl_mixer, pyOpenAl, pygame
2/ access C functions in Python via Pyrex : that's the way OpenGL, SDL,
Cal3D and ODE are integrated in Soya
The first solution leads to a kind of Lego made of Python-binding bricks
glued with a few Python scripts.
The second leads to a monolithic maelstom of C-Code (obtained from
Pyrex), with a possible access from Python.
We could say the first solution is more 'Pythonic' while the second is
closer to a Python binding of a C Game Engine (like Venom or pyOgre).
The history of Soya certainly lead to the choice of the second solution.
We could go further in this direction, and totally integrate OpenAL in
Soya. Definitely. I do not know deeply OpenAL (although i hardly worked
- without sucess - to modify pyOpenAl so that it's Win32 compliant), but
i have the feeling that OpenAL is not really cross-platform (I think
especially to EAX extensions, Direct 3D Win32 etc. for Win32), and that
is could be the main difficulty in future developpement.
Cheers,
Thomas
_______________________________________________
Soya-user mailing list
Soya-user@gna.org
https://mail.gna.org/listinfo/soya-user
