compiling_for_web.rst 8.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169
  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 <http://emscripten.org/>`__: The easiest way to install it, if it's not up to date in your Linux package manager, is to use the `Emscripten SDK <http://emscripten.org/>`__ (Install in a path without spaces, i.e. not in "Program Files")
  9. - `Python 2.7+ or Python 3.5+ <https://www.python.org/>`__
  10. - `SCons <http://www.scons.org>`__ build system
  11. Building export templates
  12. -------------------------
  13. Start a terminal and set the environment variable ``EMSCRIPTEN_ROOT`` to the
  14. installation directory of Emscripten:
  15. - If you installed Emscripten via the Emscripten SDK, you will declare the variable with a path to your downloaded folder::
  16. export EMSCRIPTEN_ROOT=~/emsdk/emscripten/master
  17. - If you installed Emscripten via your package manager, you can know the path with the ``em-config`` command::
  18. em-config EMSCRIPTEN_ROOT
  19. So you will declare the variable as for example::
  20. export EMSCRIPTEN_ROOT=/usr/lib/emscripten
  21. The Emscripten variables are defined in the ``~/.emscripten`` file, so this is an alternative way to check. Erase this file if you want to reinstall Emscripten with a fresh new method.
  22. If you are on Windows and used Emscripten SDK, start a regular prompt or the Emscripten Command Prompt.
  23. Do **not** use the Developer Command Prompt nor any of the ones that come with
  24. Visual Studio. You can set the environment variable in the system settings or
  25. in the prompt itself::
  26. set EMSCRIPTEN_ROOT=C:\emsdk\emscripten\master
  27. Now go to the root directory of the engine source code and instruct SCons to
  28. compile for JavaScript. Specify ``target`` as either ``release`` for a release
  29. build or ``release_debug`` for a debug build::
  30. scons platform=javascript tools=no target=release
  31. scons platform=javascript tools=no target=release_debug
  32. The engine will now be compiled to JavaScript by Emscripten. If all goes well,
  33. the resulting file will be placed in the ``bin`` subdirectory. Its name is
  34. ``godot.javascript.opt.zip`` for release or ``godot.javascript.opt.debug.zip``
  35. for debug.
  36. If it's not, check if you have properly installed everything, and if EMSCRIPTEN_ROOT path is correctly defined, including in the ``~/.emscripten`` file.
  37. Finally, rename the zip archive to ``javascript_release.zip`` for the
  38. release template::
  39. mv bin/godot.javascript.opt.zip bin/javascript_release.zip
  40. And ``javascript_debug.zip`` for the debug template::
  41. mv bin/godot.javascript.opt.debug.zip bin/javascript_debug.zip
  42. Compiling to WebAssembly
  43. -------------------------
  44. The current default for exporting to the web is to compile to *asm.js*, a
  45. highly optimizable subset of JavaScript.
  46. It is also possible to compile to the *WebAssembly* format, which offers better
  47. performance and loading times. Running a game in this format requires a browser
  48. with WebAssembly support.
  49. Compiling to WebAssembly requires using the latest version of Emscripten.
  50. If your OS does not offer up-to-date packages for Emscripten, the easiest way
  51. is usually to install using Emscripten's `emsdk <http://kripken.github.io/emscripten-site/docs/getting_started/downloads.html>`_.
  52. WebAssembly can be compiled in two ways: The default way is to first
  53. compile to asm.js similarly to the default method, then translate to
  54. WebAssembly using a tool called ``asm2wasm``. Emscripten automatically takes
  55. care of both processes, we simply run SCons.
  56. The other method uses LLVM's WebAssembly backend. This backend is not yet
  57. available in release versions of LLVM, only in development builds.
  58. Compiling with this backend outputs files in LLVM's ``.s`` format, which is
  59. translated into actual WebAssembly using a tool called ``s2wasm``.
  60. Emscripten manages these processes as well, so we just invoke SCons.
  61. In order to choose one of the two methods, the ``LLVM_ROOT`` variable in the
  62. Emscripten configuration file ``~/.emscripten`` is set. If it points to a
  63. directory containing binaries of Emscripten's *fastcomp* fork of clang,
  64. ``asm2wasm`` is used. This is the default in a normal Emscripten installation.
  65. Otherwise, LLVM binaries built with the WebAssembly backend will be expected
  66. and ``s2wasm`` is used. On Windows, make sure to escape backslashes of paths
  67. within this file as double backslashes ``\\`` or use Unix-style paths with
  68. a single forward slash ``/``.
  69. With ``LLVM_ROOT`` set up correctly, compiling to WebAssembly is as easy as
  70. adding ``wasm=yes`` to the SCons arguments::
  71. scons platform=javascript target=release wasm=yes
  72. scons platform=javascript target=release_debug wasm=yes
  73. These commands will build WebAssembly export templates in either release or
  74. debug mode. The generated files' names contain ``.webassembly`` as an
  75. additional file suffix before the extension.
  76. If it's not compiling, check if you have properly installed everything, and if ``LLVM_ROOT`` and ``BINARYEN_ROOT`` variables are defined in the ``~/.emscripten`` file. You can define the ``BINARYEN_ROOT`` path manually in this file if you already installed Binaryen an other way and want to avoid SCons to compile it from ports during template compilation. Emscripten SDK comes with its own fork of LLVM called fastcomp, which has the JSBackend needed for asm.js and asm2wasm, so the ``LLVM_ROOT`` path must lead to an ``/emscripten-fastcomp`` directory.
  77. Finally, the WebAssembly templates are renamed to ``webassembly_release.zip``
  78. and ``webassembly_debug.zip``::
  79. mv bin/godot.javascript.opt.webassembly.zip bin/webassembly_release.zip
  80. mv bin/godot.javascript.opt.debug.webassembly.zip bin/webassembly_debug.zip
  81. Customizing the HTML page
  82. -------------------------
  83. Rather than the default HTML file generated when compiling, it is
  84. also possible to use a custom HTML page. This allows drastic customization of
  85. the final web presentation.
  86. This can be done in two ways. The first is to replace the
  87. ``platform/javascript/godot_shell.html`` file. In this case, the HTML file is
  88. used at build time, allowing Emscripten to substitute the ``{{{ SCRIPT }}}``
  89. placeholder by a ``<script>`` element containing the loader code. This makes
  90. the HTML file usable for both asm.js and WebAssembly templates, since they use
  91. different loading code.
  92. The other method is to simply replace the ``godot.html`` file within the
  93. complete export templates. This method does not require building the engine.
  94. However, in this case, no ``{{{ SCRIPT }}}`` placeholder should be used in the
  95. HTML file, since it would never be replaced — the loader code for either asm.js
  96. or WebAssembly must already be included in the file.
  97. In the HTML page, the JavaScript object ``Module`` is the page's interface to
  98. Emscripten. Check the official documentation for information on how to use it:
  99. https://kripken.github.io/emscripten-site/docs/api_reference/module.html
  100. The default HTML page offers an example to start off with, separating the
  101. Emscripten interface logic in the JavaScript ``Module`` object from the page
  102. logic in the ``Presentation`` object. Emscripten's default ``shell.html`` file
  103. is another example, but does not use Godot's placeholders, listed below.
  104. When exporting a game, several placeholders in the ``godot.html`` file are
  105. substituted by values dependent on the export:
  106. +------------------------------+-----------------------------------------------+
  107. | Placeholder | substituted by |
  108. +==============================+===============================================+
  109. | ``$GODOT_BASE`` | Basename of files referenced within the page, |
  110. | | without suffixes |
  111. +------------------------------+-----------------------------------------------+
  112. | ``$GODOT_DEBUG_ENABLED`` | ``true`` if debugging, ``false`` otherwise |
  113. +------------------------------+-----------------------------------------------+
  114. | ``$GODOT_HEAD_INCLUDE`` | Custom string to include just before the end |
  115. | | of the HTML ``<head>`` element |
  116. +------------------------------+-----------------------------------------------+
  117. | ``{{{ SCRIPT }}}`` | ``<script>`` that loads the engine, |
  118. | | substituted only when building, not on export |
  119. +------------------------------+-----------------------------------------------+
  120. The first three of the placeholders listed should always be implemented in the
  121. HTML page, since they are important for the correct presentation of the game.
  122. The last placeholder is important when rewriting the ``godot_shell.html`` file
  123. and is substituted during build time rather than export.