Callbacks fully ported :
FMOD_CHANNEL_CALLBACK, FMOD_MEMORY_***CALLBACK
Callbacks ported but with restrictions :
FMOD_FILE_***CALLBACK, FMOD_SOUND_***CALLBACK, FMOD_DSP_***CALLBACK
Callback that can't be implemented (impossible to use them at the stage of Fmod) :
FMOD_CODEC_***CALLBACK, FMOD_OUTPUT_***CALLBACK
FmodEx examples ported that use callbacks : DspGain, RipNetStream, UserCreatedSound,
Remark :
If you tries to use callbacks, a lots of messages will be printed :
CALLBACK MANAGER : ...
If you want to disable them, call :
CallbackManager.DEBUG_MODE = false;
You can use these callbacks (open, close, read & seek) like you want.
The only restriction on them is that you can only use one FMOD_FILE_***CALLBACK for all your System object. This means that if you attach callbacks to a system like that :
system1.attachFileSystem(myopen1, myclose1, myread1, myseek1)
Then you attach others callbacks to another system :
system2.attachFileSystem(myopen2, myclose2, myread2, myseek2)
These two systems will use myopen2, myclose2, myread2, myseek2 ie last
callback passed to attachFileSystem.
This is not really a restriction because it acts like this since FMOD Ex 4.02.04 :
" - Fixed attachFileSystem being global instead of per system object
as it should have been."
From
FMOD Ex API 4.02.04 released topic.
FMOD_FILE_***CALLBACK
This is not recommended to use FMOD_MEMORY_FREECALLBACK
because there is no way to be sure that the memory is well freed.
When you attach these callbacks to a FMOD_CREATESOUNDEXINFO object (using setter), you need to call just after System::playSound by passing this FMOD_CREATESOUNDEXINFO object as parameter.
Then, you can attached others (or same) callbacks to another FMOD_CREATESOUNDEXINFO object by the same way like this.
Same restriction than for FMOD_SOUND_***CALLBACK.
Call System::createDSP just after attaching your callbacks to an
FMOD_DSP_DESCRIPTION object.
Last modified on 27/01/2006 | |
Copyright © 2004-2010 Jérôme JOUVIE - All rights reserved. | http://jerome.jouvie.free.fr/ |