0
0

Since a Sound seems to knows the System from which it has been created, it would be usefull a have the “play” primitive binded to a Sound.

Such an approach would permit to be System unaware.

This will permit that, for a single-System application, you do not have to get access to a global/static System * pointer.

And for a multi-System app, this topology makes creation sound play quite crystal clear.

a System creates Sound(s)
a Sound is played through a Channel (not needed to know the System at this level to play)

this is only valid, if FModEx Sound internal structure has an explicit System* member.

  • You must to post comments
0
0

(wasn’t working on my fmodex app during last weeks)

Yes i agree, but by design a correct application will stop all its channels, then release sounds, then release the system.

From my point of view, making a sound playable through a channel without having to use System::PlaySound() so by having a Sound::Play() (since the Sound know to which System it is binded) will simplify Application implemention, since on App code side you don’t have to get the FMOD::System instance globaly reachable.

It wouldn’t break the correctness of Application shutdown (stop channels->release sounds->release system)


because, i suppose that; by design a Sound can only be played through the System that created it, and since that it know its parent Sound, we could skip the System::Play( … FMOD::System * … ) step…

  • You must to post comments
0
0

[quote="brett":1u1uewpe]but you have to be system aware, for things like System::release.[/quote:1u1uewpe]

Please consider adding a new process, called FMOD_Destroy, which does whatever FMOD needs to do (e.g., stop playback, destroy channels, release system) to exit gracefully in an application. Currently, the parent application needs to step through each high-level operation to properly destroy FMOD–otherwise the application crashes.

“FMOD_Destroy” and be done with it! <<< How cool would that be? Pretty cool, especially during development and in error-handling routines.

  • SD
  • You must to post comments
0
0

Because I can read?

From the VB playstream example:

[code:3n13ecps]If Sound Then
result = FMOD_Sound_Release(Sound)
ERRCHECK (result)
End If

If System Then
result = FMOD_System_Close(System)
ERRCHECK (result)

result = FMOD_System_Release(System)
ERRCHECK (result)
End If[/code:3n13ecps]

Check out EVERY other example; you will find some variant of this ‘shutdown’ code. There was a time in the not-so-distance past that FMOD operations [b:3n13ecps]did[/b:3n13ecps] have to close in a particular way, otherwise the application crashed.

Maybe System::release is all you need (I just tried to crash a compiled example app). But, silly me for (a) missing the announcement concerning shutdown logic, (b) not trying to crash my apps sooner, and (c) assuming that all this ‘shutdown’ code had a friggin point.

You sometimes throw hissy fits because people don’t read the docs or inspect the examples carefully; but it is often because people [b:3n13ecps]are[/b:3n13ecps] paying attention to these things that they are misled. You just shat on some newbie about checking the docs for the GetWaveData parameters, and the particular parameter that he needed help with doesn’t even appear in the doc entry.

According to the VB examples, higher-level operations are ALWAYS closed/released before System::release. What’s the point? Is the author of this code assuming something that is no longer accurate? Is it completely unnecessary, but still “recommended” by the FMOD development team?

A short answer will suffice.

  • SD
  • You must to post comments
0
0

stdev >> you are totally out of the subject: from an object point of view your application MUST stop channels, then release sounds used by channel, then stop the audio subsystem.

that’s not good or bad, the logicial dependency between these objets theorically constrain to do this in this order, since from the app point-of-view, if the subsystem destroys objets, you won’t be aware that your pointers (hidden in the VB case) will point to crap.

having FMOD cleaning everything is a nice & normal thing, but if by yourself you don’t manage your own objects correctly, your application may collapse or leak its blood everywhere around.

OpenGl or Direct3D cleans their ressources at shutdown (FMOD too as brett said), but from your own code if you do things in disorder (say release textures/shaders after releasing D3DDevice) you may show yourself in pretty bad shape.

(and personnally i consider that something in VB is weak by design, and given examples are simple tutorials (i like simple & direct tutorials), not real world implemtations like in game engines that tries to structure everything right)


Now, to return to the original thread, i was only arguing that since FMOD::Sound knowns its originating System, having the PlaySound() binded to Sound and not System may very slightly ease coding because you would not have to get the FMOD::System instance reachable.
Because at this time, for example, from within the scope of a method play() from a class sayed “MySoundEffect”, you have to get the System from FMOD::Sound, or make it globally reachable.

It would only be just a pleasant shortcut from a coding/structuration point of view (since you only use one sound card in a game, you have FMOD::System singleton, but not having to refer to this singleton at each homemade play() might make things smoother from code-pov)

  • You must to post comments
0
0

Besides not having to know the system object explicitly at play-code, it also seems more logical to me from an object oriented point of view to have play a member of Sound.

Is there actually a reason for playSound to be a member of system?
It would even seem to imply that one Sound can be played back on more than one system (I think I tried this some time ago, and it didn’t work though)

  • You must to post comments
0
0

Hi,
I think it’s better to keep the playSound method in System, for the case you would want to play the same sound on 2 different FMOD::System objects.
If you move playSound to FMOD::Sound, you will have to load a Sample/Stream twice to be able to play it simultaneously on two soundcards.
Don’t know if I’m exact.

  • You must to post comments
0
0

[quote="bjone":3hsecc8f]stdev >> you are totally out of the subject: from an object point of view your application MUST stop channels, then release sounds used by channel, then stop the audio subsystem.[/quote:3hsecc8f]

My original comment/request had some connection with the topic of this thread; it was not necessary for me to begin a new thread.

What the heck are you rambling on about? I wasn’t talking about orphaned pointers; I was thinking about a function of convenience–that’s it! Brett already answered this point: the function ALREADY EXISTS.

If Fmod_System::Release DOES destroy the higher-level operations, there is ZERO reason to do it twice. Skilled programmers avoid redundancy: in code and in execution.

Regards,

  • SD
  • You must to post comments
0
0

the Sound knows its parent System no ?

FMOD::Sound::getSystemObject() permits to get the originating FMOD::System.

i suppose that the FMOD::Sound class have a private FMOD::System * to do this no ?

Or, what we could do, is having the playSound() at FMOD::System level, and a play() at FMOD::Sound too, that will do a shortcut like this:

private_System->playSound( this, …… );

…….

Some remark that would be perhaps more important and require a new topic:

what would be cool, and globally clever, is to have a FMOD::SoundCollection class that maintains collection of Sound instances that could be shared across multiples System (sound cards). In this case the play() method is clearly ONLY at System level (i would agree its impossible then to have a Sound::play() )

what would be pretty nice too, since i suppose that for example in the case of win32, since i suppose that Sounds are backed up in system memory, is to have some Prepare( FMODE_MODE ) that handles FMOD_2D / FMOD_3D / FMOD_HARDWARE / FMOD_SOFTWARE use case.

it is somewhat frustating to have to create multiple Sound(s) of the same Sound file to use it in 2D/3D SOFTWARE/HARDWARE.

if we take Direct3D, textures created in pool D3DPOOL_MANAGED are backup in system memory.
For DirectSound 3D, is it the case ? have we a backup in system memory, so that FMOD could switch on the fly from hardware/software 2D/3D mixing ?

to be more precise, hardware/software switch is far less usefull than 2D/3D switching.
so if there is penalty, i have thought of a Sound::Prepare( FMOD_2D / FMOD_3D / FMOD_2D|FMOD_3D) feature to precache (from a DS3D pov) the Sound before playSound().
and so perhaps add a FMOD_MODE parameter to specify if the sound is to play in the 2D path or in the 3D one.

  • You must to post comments
0
0

[quote="stdev":2oq977fv][quote="bjone":2oq977fv]stdev >> you are totally out of the subject: from an object point of view your application MUST stop channels, then release sounds used by channel, then stop the audio subsystem.[/quote:2oq977fv]

My original comment/request had some connection with the topic of this thread; it was not necessary for me to begin a new thread.

What the heck are you rambling on about? I wasn’t talking about orphaned pointers; I was thinking about a function of convenience–that’s it! Brett already answered this point: the function ALREADY EXISTS.

If Fmod_System::Release DOES destroy the higher-level operations, there is ZERO reason to do it twice. Skilled programmers avoid redundancy: in code and in execution.

Regards,

  • SD[/quote:2oq977fv]

If you release/destroy a ressource, the owning subsystem dosen’t have to do it a second time because the ressource doesn’t exist anymore for everybody (the app, the subsystem, the os).

in a game engine, let’s say you ve got entites that are linked to a models (opengl/d3d bunch of ressources), a collection of sounds playing to play, etc, etc… when it gets deleted everything is deleted in cascade and ressources are freed if not shared.
skilled programmers avoir redundancy, they use approaches that cleanly manages everything for them, so whatever the path you go, minimal to nothing got leaked and thus cleaned by the process shutdown or by the subsystem shutdown (fmod/d3d/ogl).

  • You must to post comments
0
0

Ok it is directly in a dedicaty memory pool.

But for being 2D/3D independant is it feasible ?

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.