Problem with type extension (TChannel)
BlitzMax Forums/BlitzMax Programming/Problem with type extension (TChannel)
| ||
| Hi. i have extended the TChannel class/type as follows: Type TMixChannel Extends TChannel '#Region:Public Members Field RefHandle:String ' Reference String Field IsFadeing:Int ' True if the channel playback is fading up/down Field Volume:Float ' Channel Volume Field TargetVolume:Float ' Target Volume for fading up/down '#EndRegion '#Region:Constructor Function Create:TMixChannel(paRefHandle:String = Null, paIsFadeing:Int = False, paVolume:Float = 1, paTargetVolume:Float = 0) Local Out:TMixChannel = New TMixChannel Out.RefHandle = paRefHandle Out.IsFadeing = paIsFadeing Out.Volume = paVolume Out.TargetVolume = paTargetVolume Out.SetVolume(paVolume) Return Out EndFunction '#EndRegion End Type now when i create an instance of it and play a sound on it like this:
Local MXCh1:TMixChannel = TMixChannel.Create("chan1")
Local Sound1:TSound = LoadSound("Soundfile.ogg")
Sound1.Play(MXCh1)
the sound plays as expected but MXCh1.Playing() allways returns 0 even tho the sound is being played. Any Ideas ? Thanks. |
| ||
| You would have to create a channel wrapper type if you wanted to extend the behavior of channels. As it stands, the types in brl.audio (TSound, TChannel, TAudioDriver) are all extended by the sound drivers (brl.openalaudio, brl.directsoundaudio, etc.) so as to provide a simplified interface to the programmer. Simply put, the reason what you're doing does not work is because you are extending a non-implemented version of TChannel (i.e. the Playing method does nothing, as with all other methods - take a look at brl.audio's source). You could extend the type TOpenALChannel if you were solely using that driver, and it should behave as intended, provided you don't override any of the methods without calling them in turn (but you would have to manage the allocation, which fortunately is simple for the OpenAL driver). As mentioned above, a wrapper type for any given channel would be ideal, though somewhat annoying to implement. Also, note that channels are allocated very specifically, and I actually would not recommend extending a specific driver's implementation types. It might be best to even provide a wrapper audio driver to implement any features such as your 'mix channel', as you would have control of the allocation of channels and sounds (which should be delegated to the real audio driver, through the wrapper-driver's types). |
| ||
| I see. Thanks for explainative post. I'll try to come up with something else. propably like a wrapper as you suggested. edit: while i am at it, does the channel allocation refer to the actual channels provided by the audio hardware or virtual channels ? |
| ||
| edit: while i am at it, does the channel allocation refer to the actual channels provided by the audio hardware or virtual channels ? Virtual. The drivers use a library which in turn uses the audio hardware. I don't think any driver provides access that low-level. |
| ||
| Allright. Thanks. =) |
   |