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

something like Regal. I did port a very simple OpenGL demo ( https://github.com/chadaustin/nehe-emscripten )
to Emscripten and Regal and got it to work with some help from Emscripten's community, so Regal is probably viable
after applying some elbow grease.
In practice, any game that runs on Android or iOS would have an OpenGL ES 2 rendering pipeline and thus
would not require any kind of OpenGL legacy emulation layer.
Integrating with OpenGL, Attempt #2: Simplifying the
AstroMenace Renderer
For the purposes of this demonstration, I opted for something easier than getting Regal to work reliably. I disabled
lighting and materials in the application and switched back to LEGACY_GL_EMULATION . To verify that my changes
to AstroMenace's source code weren't breaking the game itself, I spun up a native development environment
(specifically, an Ubuntu VM) so I could begin modifying and testing the original game code. After each change,
I verified that the game still compiled and ran. After removing support for shadow maps, MSAA, occlusion queries,
anisotropic filtering, texture compression, and various other fancier rendering capabilities, I finally had an
Emscripten-compiled game that actually rendered 3D. The 3D output was obviously glitchy, with corrupted vertex
buffers, largely due to the incomplete and buggy Emscripten legacy GL emulation layer. However, as I mentioned
before, if a game's rendering code is limited to the OpenGL ES 2 subset, porting it to Emscripten and WebGL will be
dramatically easier.
The Main Loop
Finally, it's worth discussing one significant change needed when most games are brought to Emscripten: the browser
is an event-based platform. JavaScript runs with a single execution thread in the context of a web page. That means
that, while JavaScript is running, the browser cannot update the page nor display anything to the screen. Many
browsers can't even process user input while JavaScript is running. This causes some problems when trying to integrate
traditional game loops with a web page. A traditional game's main loop is structured as shown in Listing 18-16.
Listing 18-16. Traditional Game Main Loop
while (running) {
process_input();
simulate_world();
render_graphics();
wait_for_next_frame();
}
On a web page, while such a loop is running, the browser cannot handle user input events or graphics updates.
Thus, the browser will assume your script is hung and ask the user to kill it. Instead of waiting for the next frame in a
blocking game loop, you must instead ask Emscripten to call your game when it's time for the next frame, as shown in
Listing 18-17.
Listing 18-17. Emscripten Game Main Loop
void main_loop();
int main() {
// initialization code
// ...
// at game startup, usually at the end of main()
emscripten_set_main_loop(main_loop, 60, false);
}