compiling_for_web.rst 9.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186
  1. .. _doc_compiling_for_web:
  2. Compiling for the Web
  3. =====================
  4. .. highlight:: shell
  5. Requirements
  6. ------------
  7. To compile export templates for the Web, the following is required:
  8. - `Emscripten SDK <http://emscripten.org/>`__ (Install in a path without
  9. spaces, i.e. not on "Program Files")
  10. - `Python 2.7+ <https://www.python.org/>`__ (3.0 is
  11. untested as of now)
  12. - `SCons <http://www.scons.org>`__ build system
  13. Building export templates
  14. -------------------------
  15. Start a terminal and set the environment variable ``EMSCRIPTEN_ROOT`` to the
  16. installation directory of Emscripten::
  17. export EMSCRIPTEN_ROOT=~/emsdk/emscripten/master
  18. If you are on Windows, start a regular prompt or the Emscripten Command Prompt.
  19. Do **not** use the Developer Command Prompt nor any of the ones that come with
  20. Visual Studio. You can set the environment variable in the system settings or
  21. in the prompt itself::
  22. set EMSCRIPTEN_ROOT=C:\emsdk\emscripten\master
  23. Now go to the root directory of the engine source code and instruct SCons to
  24. compile for JavaScript. Specify ``target`` as either ``release`` for a release
  25. build or ``release_debug`` for a debug build::
  26. scons platform=javascript tools=no target=release
  27. scons platform=javascript tools=no target=release_debug
  28. The engine will now be compiled to JavaScript by Emscripten. If all goes well,
  29. the resulting file will be placed in the ``bin`` subdirectory. Its name is
  30. ``godot.javascript.opt.zip`` for release or ``godot.javascript.opt.debug.zip``
  31. for debug.
  32. To install the templates, place them into the ``templates`` directory in your
  33. Godot user directory. Rename the zip archive to ``javascript_release.zip`` for
  34. the release template::
  35. cp bin/godot.javascript.opt.zip ~/.godot/templates/javascript_release.zip
  36. And ``javascript_debug.zip`` for the debug template::
  37. cp bin/godot.javascript.opt.debug.zip ~/.godot/templates/javascript_debug.zip
  38. If you are writing custom modules or using custom C++ code, you may want to
  39. configure your zip files as custom export templates. This can be done in the
  40. export GUI, using the "Custom Package" option.
  41. There's no need to copy the templates in this case — you can simply reference
  42. the resulting files in your Godot source folder, so the next time you build,
  43. the custom templates will already be referenced.
  44. Compiling to WebAssembly
  45. -------------------------
  46. The current default for exporting to the web is to compile to *asm.js*, a
  47. highly optimizable subset of JavaScript.
  48. It is also possible to compile to the experimental *WebAssembly* format, which
  49. should eventually offer better performance and loading times. Its specification
  50. is still in flux and compile tools may sporadically fail to build Godot.
  51. Running a game per WebAssembly requires nightly browser builds with special
  52. flags set. As such, WebAssembly builds are currently not suitable for
  53. publishing.
  54. Compiling to WebAssembly requires using the `incoming branch of Emscripten <http://kripken.github.io/emscripten-site/docs/building_from_source/building_emscripten_from_source_using_the_sdk.html#building-emscripten-from-the-main-repositories>`_.
  55. WebAssembly can be compiled in two ways: The default way is to first
  56. compile to asm.js similarly to the default method, then translate to
  57. WebAssembly using a tool called ``asm2wasm``. Emscripten automatically takes
  58. care of both processes, we simply run SCons.
  59. The other method uses LLVM's WebAssembly backend, which should eventually
  60. produce more performant binaries. To build LLVM with this backend, set the
  61. CMake variable ``LLVM_EXPERIMENTAL_TARGETS_TO_BUILD`` to ``WebAssembly`` when
  62. building LLVM.
  63. Compiling with this backend outputs files in LLVM's ``.s`` format, which is
  64. translated to actual WebAssembly using a tool called ``s2wasm``. Emscripten
  65. manages these processes as well, so we just invoke SCons.
  66. In order to choose one of the two methods, the ``LLVM_ROOT`` variable in the
  67. Emscripten configuration file ``~/.emscripten`` is set. If it points to a
  68. directory containing binaries of Emscripten's *fastcomp* fork of clang,
  69. ``asm2wasm`` is used. This is the default in a normal Emscripten installation.
  70. Otherwise, LLVM binaries built with the WebAssembly backend will be expected
  71. and ``s2wasm`` is used. On Windows, make sure to escape backslashes of paths
  72. within this file as double backslashes ``\\`` or use Unix-style paths with
  73. a single forward slash ``/``.
  74. With ``LLVM_ROOT`` set up correctly, compiling to WebAssembly is as easy as
  75. adding ``wasm=yes`` to the SCons arguments::
  76. scons platform=javascript target=release wasm=yes
  77. scons platform=javascript target=release_debug wasm=yes
  78. These commands will build WebAssembly export templates in either release or
  79. debug mode. The generated files' names contain ``.webassembly`` as an
  80. additional file suffix before the extension.
  81. The templates simply replace the previous asm.js-based web export templates
  82. with the names ``javascript_release.zip`` and ``javascript_debug.zip``::
  83. cp bin/godot.javascript.opt.webassembly.zip ~/.godot/templates/javascript_release.zip
  84. cp bin/godot.javascript.opt.debug.webassembly.zip ~/.godot/templates/javascript_debug.zip
  85. Customizing the HTML page
  86. -------------------------
  87. Rather than the default HTML file generated when compiling, it is
  88. also possible to use a custom HTML page. This allows drastic customization of
  89. the final web presentation.
  90. This can be done in two ways. The first is to replace the
  91. ``platform/javascript/godot_shell.html`` file. In this case, the HTML file is
  92. used at build time, allowing Emscripten to substitute the ``{{{ SCRIPT }}}``
  93. placeholder by a ``<script>`` element containing the loader code. This makes
  94. the HTML file usable for both asm.js and WebAssembly templates, since they use
  95. different loading code.
  96. The other method is to simply replace the ``godot.html`` file within the
  97. complete export templates. This method does not require building the engine.
  98. However, in this case, no ``{{{ SCRIPT }}}`` placeholder should be used in the
  99. HTML file, since it would never be replaced — the loader code for either asm.js
  100. or WebAssembly must already be included in the file.
  101. In the HTML page, the JavaScript object ``Module`` is the page's interface to
  102. Emscripten. Check the official documentation for information on how to use it:
  103. https://kripken.github.io/emscripten-site/docs/api_reference/module.html
  104. The default HTML page offers an example to start off with, separating the
  105. Emscripten interface logic in the JavaScript ``Module`` object from the page
  106. logic in the ``Presentation`` object. Emscripten's default ``shell.html`` file
  107. is another example, but does not use Godot's placeholders, listed below.
  108. When exporting a game, several placeholders in the ``godot.html`` file are
  109. substituted by values dependent on the export:
  110. +------------------------------+-----------------------------------------------+
  111. | Placeholder | substituted by |
  112. +==============================+===============================================+
  113. | ``$GODOT_BASE`` | Basename of files referenced within the page, |
  114. | | without file extension or other suffixes |
  115. +------------------------------+-----------------------------------------------+
  116. | ``$GODOT_CANVAS_WIDTH`` | Integer specifying the initial display width |
  117. | | of the game |
  118. +------------------------------+-----------------------------------------------+
  119. | ``$GODOT_CANVAS_HEIGHT`` | Integer specifying the initial display height |
  120. | | of the game |
  121. +------------------------------+-----------------------------------------------+
  122. | ``$GODOT_DEBUG_ENABLED`` | String ``true`` if debugging, ``false`` |
  123. | | otherwise |
  124. +------------------------------+-----------------------------------------------+
  125. | ``$GODOT_CONTROLS_ENABLED`` | String ``true`` if ``html/controls_enabled`` |
  126. | | is enabled, ``false`` otherwise |
  127. +------------------------------+-----------------------------------------------+
  128. | ``$GODOT_HEAD_TITLE`` | Title of the page, normally used as content |
  129. | | of the HTML ``<title>`` element |
  130. +------------------------------+-----------------------------------------------+
  131. | ``$GODOT_HEAD_INCLUDE`` | Custom string to include just before the end |
  132. | | of the HTML ``<head>`` element |
  133. +------------------------------+-----------------------------------------------+
  134. | ``$GODOT_STYLE_FONT_FAMILY`` | CSS format ``font-family`` to use, without |
  135. | | terminating semicolon |
  136. +------------------------------+-----------------------------------------------+
  137. | ``$GODOT_STYLE_INCLUDE`` | Custom string to include just before the end |
  138. | | of the page's CSS |
  139. +------------------------------+-----------------------------------------------+
  140. | ``{{{ SCRIPT }}}`` | ``<script>`` that loads the engine, |
  141. | | substituted only when building, not on export |
  142. +------------------------------+-----------------------------------------------+
  143. The first three of the placeholders listed should always be implemented in the
  144. HTML page, since they are important for the correct presentation of the game.
  145. The last placeholder is important when rewriting the ``godot_shell.html`` file
  146. and is only substituted during build time, not during export time.
  147. The other placeholders are optional.