The copying of the data source is now done generically through the new
data source copying system rather than being restricted to just the
resource manager.
This is used for making a copy of a data source.
Data sources are not required to support copying, in which case this
callback can be set to NULL, or it can return MA_NOT_IMPLEMENTED.
This commit just sets up the infrastructure. As of this commit, no data
sources actually implement this, however future commits will be
introducing support in stages.
This should return the size of the implementations struct. For example,
`ma_decoder` would return `sizeof(ma_decoder)`.
This is in preparation for future work to support copying data sources.
This removes the onInitFile and onInitFileW callbacks from
ma_decoding_backend_vtable. This means decoding backends can no longer
implement a specialized initialization routine for loading from a file.
What this does is enforces all file IO to go through the same code path,
that being the `ma_decoder` and `ma_vfs` infrastructure. It also
simplifies the backend vtable.
The ability to initialize from memory (the onInitMemory callback) is
still available and there are not plans to remove this.
This makes the following APIs public:
ma_allocation_callbacks_init_default()
ma_allocation_callbacks_init_copy()
This is required to allow things like custom data sources and backends
to be able to track allocation callbacks if necessary.
This removes the allocation callbacks parameter. These are now managed
internally. This is in preparation for some future changes to data
source management.
These have been renamed to the following:
ma_data_source_init > ma_data_source_base_init
ma_data_source_uninit > ma_data_source_base_uninit
The new naming scheme makes it clearer that you're initializing the
base data source structure.
For some reason, 64-bit pointer arguments are casted to Numbers
in Emscripten's type handling (which causes conversion errors when
passing them back to native code)
David Reid
Echo J
Yuri Khrustalev
amaldika