0:08 Game Introduction: The developer introduces "KEE," a keyboard-based rhythm game where players tap keys in sync with on-screen cues.
0:40 Audio Engine Focus: The devlog focuses on the creation of a custom audio engine using OpenAL, replacing the previously used SDL mixer.
0:55 Reason for Switching to OpenAL: The SDL mixer required including multiple SDL sub-components that were unnecessary for the project. OpenAL was chosen for its simplicity and similarity to OpenGL, which the developer already used.
1:51 OpenAL Core Concepts: OpenAL uses three main objects:
Listener: Represents the game's perspective on audio, akin to ears. There's only one listener.
Sources: Emit the audio that the listener hears. Sources and listeners can be positioned in 3D space to affect volume and direction.
Buffers: Store the actual audio data that sources play.
2:41 Singleton Audio Engine: The audio engine was implemented as a singleton class to manage initialization and closing within the constructor and destructor.
2:59 WAV File Loading: The engine utilizes WAV files for audio data. The developer created a custom WAV loader instead of using a third-party solution, loading all WAV files from a single folder using C++'s directory iterator.
3:30 Sound Effect Playback: Sound effects are played by creating a source, attaching a buffer to it, and then playing the source.
3:38 Sound Effect Cleanup: When a sound effect is finished, its source and buffer need to be cleaned up. The developer monitors the source's state in a loop and cleans up when it stops.
4:01 Multithreading for Cleanup: High-level audio engines like SDL mixer often use separate threads to continuously monitor active sounds and handle cleanup. This frees up the main thread to focus on other tasks.
5:01 Multithreading Implementation: The developer implemented a similar approach, using a separate thread to monitor a vector of active sound effects and clean them up when they finish playing. The thread is limited to 200 checks per second to avoid excessive CPU usage.
5:53 Thread Safety: The developer addresses the importance of thread safety in multithreaded programs to prevent data corruption. Atomic instructions and mutexes were used for different types of data.
6:38 Music Playback: Music playback differs from sound effect playback. Music files are typically large and streaming them from disk is more efficient than loading the entire file into memory.
7:01 Streaming Music from Disk: The engine streams music, loading only the current part of the song and a little more, and then cleaning up the buffers that have already played.
7:29 User Control Over Music: The engine provides users with control over music playback (pause, play, stop).
7:52 Jumping to Specific Locations in Music: Jumping to a specific point in a song involves unqueuing current buffers, moving the pointer to the desired location, and then requeuing the buffers. This requires careful attention to sample alignment to avoid static.
8:28 Music Cleanup Thread: A separate thread also monitors and cleans up active music players.
8:44 Future Development: The next steps in the development include building a level editor, split into two devlogs:
Next Devlog: Adding Taps and Holds to Levels
Following Devlog: Custom Decoration System and Level Enhancements
9:27 Conclusion: The devlog concludes with a summary of the audio engine's functionality and a look towards the future of the rhythm game development.
I hope this helps! Let me know if you have any other requests.