Starting OpenAL Soft support

[kcat]

• Adds a rudimentary "VFS" system, which now requires an additional option in options/options.cfg. It should now have a DataPath= setting that points to an existing Arena game folder, e.g. DataPath=C:\Games\Arena. The VFS system will manage the root data path, can support multiple prioritized data paths, and (in the future) archives of different types through the same interface. Callers will get back a standard std::istream interface for accessing the raw resource data to load it as needed (e.g. reading the pixel data into an SDL_Surface, reading audio data into an audio buffer, etc). Note that if you're not regenerating the MSVC project from the CMake project, you may need to add the new files in the components folder as a separate static lib sub-project that gets linked by the main TESArena exe (this is so it can be more easily reused when other executables are introduced, to avoid compiling the same sources multiple times).
• Improved frame timing, by taking into account the full time delta in between the start of two frames (the previous method could lose time, making it run slower than real-time). It also limits the framerate to a lower bound of 15 FPS -- any lower, and the game simulation will slow down so it doesn't jump forward by ridiculous amounts.
• Currently there is no audio output. But it does properly set up and close the device through OpenAL, so it can start being used. To get OpenAL Soft for Windows, download http://kcat/strangesoft.net/openal-binaries/openal-soft-1.17.2-bin.zip, extract it, install the DLLs as instructed in the readme, then add the include path and lib to the project. For end-users, you simply need to provide an OpenAL32.dll with the exe and it will be used automatically without needing to be manually installed.
• Puts the AudioManager into a pImpl container. If you're not familiar with the pImpl paradigm, it's a method for exposing an interface while hiding the internals, by having a thin wrapper class that simply stores an opaque pointer (of a type which is defined elsewhere) and forwards calls to the real implementation through the pointer. pImpl, pointer to Implementation. It basically allows changing private implementation details without causing a recompilation of everything that uses the public interface (believe me, as a project grows, something like this will be needed to keep your sanity from compile times). A pure virtual base class is another method of doing the same thing, but it does incur virtual call overhead.
• Fixes the main menu Exit button to properly close down the game.

[afritz1]

Thanks for all the help you're doing!

Several of those things I hadn't thought of, like using an SDL event with the exit button. That's a good idea. And I thought the frame timing was correct, too, but I guess not! The lower bound there is a wise decision.

I have downloaded the OpenAL Soft components and I believe it's ready to be used.

So the AudioManagerImpl uses init() instead of the default AudioManagerImpl() constructor. Is that because the same object might be changing often in one lifetime? Edit: I read your notes again and it's making more sense now.

And the components folder has files for the virtual file system? Okay.

I don't know if I should keep the MusicNames and SoundNames. I figured it'd be okay to hard-code them because there aren't a huge number of them and it makes it easier to connect them with their filenames. This design makes it hard to add other music or sound files from a text file, though.

[kcat]

So the AudioManagerImpl uses init() instead of the default AudioManagerImpl() constructor. Is that because the same object might be changing often in one lifetime?

It was done that way so the AudioManager could be a flat object in GameState (and thus gets constructed at the beginning of the GameState constructor, before it can get the appropriate constructor parameters). And that was to avoid an extra layer of indirection... having to dereference the pointer to the AudioManager just to get a pointer to deference the AudioManagerImpl to do the call with. This way keeps the implementation pointer in the GameState, like it used to be before it was split into separate AudioManager and AudioManagerImpl classes.

I don't know if I should keep the MusicNames and SoundNames. I figured it'd be okay to hard-code them because there aren't a huge number of them and it makes it easier to connect them with their filenames. This design makes it hard to add other music or sound files from a text file, though.

I'd say it's good enough for now, and when modding becomes enough of a concern to warrant it, we can make the MusicNames and SoundNames variable (with appropriate string name mappings). So for instance, when a new sound is defined from a text file, it takes the next available integer ID and adds a map entry that turns the string into the integer ID (and the string lookup should be done as little as possible, storing integer IDs in whatever needs a sound or music identifier, since string lookups can get expensive). That's my current thinking at least, but we can revisit the idea when it becomes an issue.