HTML5 Games in C++ with Emscripten - HTML5 Game Development Insights - page 285

Loading Game Content
Loading AstroMenace.html caused the browser to show the JavaScript error in Listing 18-13.
Listing 18-13. First Load Error in Browser
abort() at Error
at stackTrace (AstroMenace.html:993:15)
at abort (AstroMenace.html:510736:25)
at __Z10FileDetectPKc [FileDetect(char*)] (AstroMenace.html:61135:121)
at __Z8vw_fopenPKc [vw_fopen(char*)] (AstroMenace.html:61172:12)
at __ZN12cXMLDocument4LoadEPKc [cXMLDocument::Load(char*)] AstroMenace.html:62962:13)
at __Z16LoadXMLSetupFileb [LoadXMLSetupFile(bool)] (AstroMenace.html:275626:13)
at Object._main (AstroMenace.html:87596:15)
at Object.callMain (AstroMenace.html:510655:30)
at doRun (AstroMenace.html:510695:25)
at AstroMenace.html:510705:19
As you can see, the stack trace is fairly readable, making it possible to figure out the approximate location of the
error. After stepping through the code in the Chrome developer tools JavaScript debugger, I noticed that a variable
representing a function pointer from the SDL_RWops struct was completely bogus.
Further exploration uncovered that Emscripten's current SDL_RWFromFile implementation does not match
the header: it returns an opaque integer ID when the SDL API expects that the result of SDL_RWFromFile is a struct
containing function pointers. Thus, attempting to dereference the pointer returned by SDL_RWFromFile returned data
from bogus memory, so the function pointer was invalid, tripping an invalid virtual call assertion.
To work around this problem, I removed the SDL filesystem support from Emscripten's SDL and replaced it with
SDL_rwops.c from the SDL 1.2 source code itself. Note that, should you take an approach like this, you will need to
satisfy the terms of SDL's LGPL license in some way. Under the LGPL, the end user must be able to substitute their
own implementation of any LGPL code, such as SDL, and since Emscripten does not have stable support for dynamic
linking, you may struggle to satisfy the LGPL. In this case, because I'm porting an open source game anyway, there are
no problems.
There are plans to replace Emscripten's SDL 1.2 and 1.3 implementations with SDL 2.0, which is licensed under
the permissive zlib license. SDL 2.0 would resolve all of these problems.
Finally I reached a point where the compiled AstroMenace.html produced errors about a missing game data
pack, as shown in Listing 18-14.
Listing 18-14. Missing Game Assets
Can't find the file /home/emscripten/.astromenace/amconfig.xml AstroMenace.html:61
XML file not found: /home/emscripten/.astromenace/amconfig.xml AstroMenace.html:61
Can't open XML file for write /home/emscripten/.astromenace/amconfig.xml AstroMenace.html:61
*** Can't find VFS file /bin/gamedata.vfs AstroMenace.html:61 ***
*** gamedata.vfs file not found or corrupted. AstroMenace.html:61 ***
gamedata.vfs is a compiled “packfile” of art, generated from source art assets by the game itself when run with
a special flag. Since the game isn't running in Emscripten, I needed a pre-built gamedata.vfs . I could have built and
compiled the game on a native platform to produce gamedata.vfs , but I found it easier to download a precompiled
binary from the AstroMenace web site and use its gamedata.vfs file.
Linking a data file into an Emscripten program is accomplished with emcc's --preload-file option. Specifically,
I checked gamedata.vfs into AstroMenace/bin and added the build option --preload-file bin@/bin so the
generated code has access to /bin/gamedata.vfs .