Project Bolero Devlog 19

A board from ‘The Mask Of Atlantis’

Work Since Last Devlog

  • In general:
    • I started a secondary blog (oh no) for tracking smaller status updates and accomplishments throughout the week.
    • I finished reading Game Programming Patterns. Worth reading, lots to think about. While LÖVE handles most of the low-level details, it still leaves the overall project structure up to the developer, and Hibernator certainly had a lot of subsystems intruding into other subsystems, especially near the end of development.
  • Wiki:
    • Uploaded some ZZT maps, which had been finished for a while, but never cleaned up and added:
  • Bolero 2:
    • As of Friday, no engine work done 🙁



That music tracker project ate up a bunch of time and energy, but it was good to get a better understanding of how software mixing works. I sketched out some pseudocode for changing the Bolero sound manager to use virtual channels, priority tags, and prevention of doubled-up sounds (as in, two or more of the same sound played at the same time, causing an unwanted volume spike or flanger effect). Bolero 1 just loads all in-game sound effects as Sources and plays them, such that only one instance of a sound can be played at a time. That was OK for Hibernator, but I need to do this the right way for future games. Perusing the LÖVE documentation wiki, I see that they added a bunch of neat audio mixing features as of release 11.

I ran MilkyTracker’s optimizer on a bunch of work-in-progress XM modules that I have lying around. To back up a bit: I was getting tired of making new instruments, so I started building a template XM file with a bunch of predefined instruments ready to go. This includes the usual chiptune waveforms and such, and also a mix of sounds that I’ve recorded and modified, sounds that were synthesized directly in MilkyTracker and/or Audacity, and sounds pulled from CC0 sample packs (see below for links.)

Unfortunately, the template XM started getting larger than 10 megabytes. In 2019, of course, that’s hardly anything, but by using it as a base, it means that every track I start, no matter how unfinished, ends up taking up 10 megabytes of disk space. Between that and deleting old mixdowns, my modules folder is down from 1 gigabyte to about 350 megabytes.

Backing up further: I’m considering the use of raw XM modules for music in Bolero 2. For Hibernator, I wrote the background music in MilkyTracker, exported to .wav, normalized the volume, and then converted to .ogg. The file sizes were reasonable for just two tracks, but I know that with each additional track, the disk storage for audio will keep going up at a fairly consistent rate.

ZIP does a reasonable job at compressing the sample data in a single XM file, though it doesn’t seem to compress duplicate samples across multiple files. Even so, a reasonably-crafted XM module, even with its uncompressed samples, is typically much smaller than an Ogg Vorbis mixdown. Here are the file sizes for the XM and Ogg Vorbis versions of Hibernator’s music:

Track      XM Size   OGG size
Gameplay    1.5 MB     2.9 MB
Ending     71.7 KB   213.4 KB

(Note: The music in Hibernator was all mono, so these Ogg Vorbis mixdowns were saved as mono as well, and are smaller than what they would be in stereo.)

Some additional care is needed, as LÖVE uses libmodplug for tracker music playback, and its output is a little different from MilkyTracker’s. I believe some kind of sample interpolation is forced on as well. I don’t believe it’s possible to control the playback state of the XM file, as LÖVE treats these formats as just another sound source. Maybe it would be possible to modify the XM files from within LÖVE before playing them as Sound Sources… I’ll stop here because I’m getting way ahead of myself.

Below are the CC0 sample libraries I have been looking at:

Plans For Next Post

  • Get Bolero 2 running again! (Good gravy!)
  • Rewrite Bolero’s sound manager to be channel-based instead of just playing from single sources.