I have been trying to figure out how to incorporate the designer API into our game. As our system uses its own file loading system, I tried loading the .fsb files into memory using registerMemoryFSB() and passing FMOD_EVENT_ERROR_ON_DISKACCESS to getEvent(). This seems to work with the sample media files included. However, when I try to use a file that our sound guy created for me as a test, the getEvent call returns FMOD_ERR_MEMORY_CANTPOINT.
I’m not sure why I am getting this or where I should look to find the cause, as the sound seems to work fine in the FMOD event player. My test application does not call update(), but I don’t see how that could be causing this problem. What might be causing this to happen?
- simubenc asked 10 years ago
After getting more strange errors such as getEvent returning FMOD_ERR_FORMAT, it appears that registerMemoryFSB is doing the equivalent of FMOD_OPENMEMORY_POINT instead of FMOD_OPENMEMORY, although the documentation does not make this clear. I am freeing the memory block after I pass it into registerMemoryFSB which could explain why I get this result.
Is there a way to load a .fsb into memory using the equivalent of "loadfrommemory" or FMOD_OPENMEMORY? The way our game’s file access works is by passing a pointer to a copy of the file data which needs to be released after reading from it. I also want the sound designer to be able to use compressed sample data for the sound banks if desired, which seems to be what triggered the earlier error.
Yes, I can just keep the data in the program’s memory instead of copying it into FMOD’s memory, that is not a problem. I was just stating that I had not realized that I needed to do that from reading the documentation for registerMemoryFSB, it could be a little more explicit about that.
The first issue however is a problem; if registerMemoryFSB() does not work for sound banks that are not uncompressed PCM, that will limit the sound designer as well as increasing the memory consumption quite a bit, given that the entire FSB is loaded into memory. From a user perspective, this seems like a bug, especially since the error does not get triggered until a getEvent() call later on.
Please login first to submit.