It seems to better convey the idea of implementing the storage_backend,
without being too similar (one has _storage prefix, the other has t as suffix).
I changed the way to export offsets values to make them portable to
msvc. In theory, it could work as it doesn't rely on inline assembly
anymore. The MSVC project file has been updated with something that
could more or less give the desired output, BUT I CANNOT TEST IT.
According to NASM documentation (see 9.1.1 External Symbol Names)
http://www.nasm.us/doc/nasmdoc9.html
Most 32-bit C compilers share the convention used by 16-bit compilers,
that the names of all global symbols (functions or data) they define are
formed by prefixing an underscore to the name as it appears in the C
program. However, not all of them do: the ELF specification states that
C symbols do not have a leading underscore on their assembly-language
names.
The AI controller has been reworked to be made independent of the audio
plugin. All it expects is 2 callbacks (one for setting sample format,
and the other to push samples).
A retro-compatibility module implements these 2 new callbacks using the
existing audio plugin in a best effort manner as pure zilmar spec
is not fully compatible with the new callbacks. However, by exploiting
implementation details of both core and audio plugin, we can get
a "good enough" implementation of these callbacks.
Audio DMA fifo has been also reworked and its associated data has
changed. A compromise has been made in order to not change the
savestate format.
This should allow for some flexibility in the choice of the controller
input and rumble output.
For now, we keep the old behavior and use the input plugin, but other
input source and rumble sink could be considered.
We hardcode te connection in the core, but ultimately,
the choice of an external controller/rumble should be the responsibilty
of the frontend.
This should allow for some flexibility in the choice of a time source.
For now, we keep the old behavior and use the C localtime, but other
time source could be considered.
Furthermore, we hardcode the connection in the core, but ultimately,
the choice of an external time source should be the responsibility of
the frontend.
