HTML and CSS Reference
Building the Game
After grabbing the source code, my first attempt was to write an emscripten-build shell script that uses Emscripten's
emcc and em++ commands to compile the source into HTML. Listing 18-11 shows the initial build command.
Listing 18-11. Initial Emscripten Build Attempt
em++ -Wall -o AstroMenace.html $(find AstroMenaceSource -iname '*.cpp')
As you can see, em++ is used similarly to g++. -Wall enables all warnings, and the remainder of the command says
to compile all C++ source files into the AstroMenace.html program, which can then be loaded in a web browser.
The script in Listing 18-11 at least got me to the point where I could start using compile and link errors to drive
it's perfectly okay to reference symbols that aren't defined. Emscripten assumes that undefined functions refer to
useful technique. However, for a self-contained program, like a game written entirely in C++, you generally want an
undefined function to fail the build. Passing -s ERROR_ON_UNDEFINED_SYMBOLS=1 to emcc or em++ will fail the build
until all referenced symbols are defined.
Third-Party Dependencies and a Real Build System
The first round of undefined symbol errors, shown in Listing 18-12, were related to libogg and libvorbis, which
were easy enough to integrate. I invoked emcc to produce an LLVM IR file from the libogg and libvorbis .c files,
which was then added to the source list for AstroMenace.html. libogg and libvorbis can be downloaded from
Listing 18-12. Undefined libogg and libvorbis Symbols
Error: unresolved symbol: ov_read
Error: unresolved symbol: ov_open_callbacks
Error: unresolved symbol: ov_info
Error: unresolved symbol: ov_pcm_total
Error: unresolved symbol: ov_clear
Error: unresolved symbol: ov_comment
Error: unresolved symbol: ov_pcm_seek
Next came freealut, which integrated much like libogg and libvorbis. The freealut source code is checked into
Emscripten itself, so I just used that.
At this point I realized that using a shell script to compile AstroMenace was becoming 1) slow, as it caused a full
rebuild each time, and 2) annoying, as I had to specify long lists of source files, so I switched the build system over
to SCons, a Python-based build system. SCons is available at www.scons.org/ . Emscripten does not require SCons:
Make or any other build system is also suitable.
FreeType (an open source TrueType font renderer) was the hardest dependency because I had to be precise
about specifically which FreeType source files to include in the build system. If you include every .c file, you will
include multiple implementations of the same functions and see duplicate symbol definition errors. FreeType is also
included in the Emscripten tree.