I’m almost sure I’m right, but that "almost" part keeps bugging me.
So, do I need something special to manage events?
I figure that when obtaining an event with one of the getEvent methods, you need to start it, stop it and forget it. Calling "stop" on an event will safely release it. If an event is oneshot, it will self-release when done. I don’t need to delete or release events in any special way. Right?
As for groups, they are always active if the project is active. There is no way to release or delete a group if its project is loaded. All you can do is load and uload the event data for a group. Right?
Thanks in advance
And another question: How to obtain a systemid for an event? Is it ProjectIndex + EventInProjectID (with only one project, event projectids and systemids would be the same)
- iboB asked 10 years ago
Yeah, def. Parsing FTW :). As for header vs report, it just depends how what sort of info you need and in what format.
On the authoring side, we wanted sound designers to hook up events using the string paths they see in Designer (like "Vehicles/FastCar/Engine" where Vehicles is the project name). In the header file that would turn that into something like EVENT_FASTCAR_ENGINE, but in the programmer report you can see the normal path. The programmer report is also a bit easier for a human to read through should that ever be necessary for debugging and the like.
On the runtime side, we wanted a solution that would give us the speed of accessing events by id and the memory win of EVENT_NAMELESS mode. We already store things like event paths in a string table, so the missing piece was a file that would give us a mapping between these strings and the event ids (also reverbs, params, etc). The programmer report fit the bill perfectly.
Another question on that topic.
Are Group::free/loadEventData calls ref-counting?
Specific questions in the comments:
sys->getGroup("g", false, &g);
sys->getGroup("g", false, &g2);
//I checked that g and g2 are the same (as expected)
g2->loadEventData(); //what happens here? it’s loaded already
g->freeEventData(); //what happens here? is g2’s data freed too?
In short, no the are not. In your example, the second load does nothing and the first free unloads that group. That’s because there is only one group "g" and it’s not reference counted. Also, it’s possible to have all of group g loaded without ever having called g->loadEventData by doing something like playing all of the events in g.
In our wrapper around FMOD, I do reference count group loading and unloading, and only call freeEventData when the ref count drops to 0. However, even this API has a "force unload" mode which ignores the ref count.
to the events/groups:
the sound-data for events are loaded if you create the first one that is not info-only. Additionally if you stop a sound event you can forget about it, but the sound-data int he background will still stay in memory until calling freeEventData
usually this is managed by groups to avoid memory fragmentation. Eventdata (sound-data) of groups can be loaded at once for a complete sound group. after this playing events with the sound data loaded does not need any file-access. If you don’t need the data anymore, use freeEventData of the soundgroup to unload the data.
as to your other question with obtaining a systemid:
they are encoded in the .h file the sound designer can create on building the project. Additionally you can get them by getting an info-only event and get the systemId from it’s info (by calling getInfo on the event).
i hope that helped
- manni answered 10 years ago
A small correction. The generated header file and the programmer report only have project ids, not system ids. System ids are only created at runtime and it depends on the order in which you load your projects.
If you are interested in using IDs rather than string names for looking up sounds, I highly recommend you parse the programmer reports at runtime rather than include the header. It requires a bit more infrastructure, but it means that you don’t have to recompile the game every time you do a sound build, which is hugely valuable.
You should also know that you can always get at a project by using its string name, even if you are running in EVENT_NAMELESS mode. This makes the lack of reliable system ids workable.
Please login first to submit.