exporting_for_web.rst 6.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154
  1. .. _doc_exporting_for_web:
  2. Exporting for the Web
  3. =====================
  4. Exporting for the web generates several files to be served from a web server,
  5. including a default HTML page for presentation. A custom HTML file can be
  6. used, see :ref:`doc_compiling_for_web`.
  7. The default HTML file is designed to fit the game perfectly without cutting off
  8. parts of the canvas when the browser window is scaled to the game's dimensions.
  9. This way it can be inserted into an ``<iframe>`` with the game's size, as is
  10. common on most web game hosting sites.
  11. Serving the files
  12. -----------------
  13. The generated ``.html`` file can be used as ``DirectoryIndex`` and can be
  14. renamed to e.g. ``index.html`` at any time, its name is never depended on.
  15. It can also be inserted into another HTML file as an ``<iframe>`` element.
  16. Users must allow **third-party** cookies when playing a game presented in an
  17. iframe.
  18. The other exported files are served as they are next to the ``.html`` file,
  19. names unchanged.
  20. The ``.mem`` and ``.pck`` files are binary, usually delivered with the
  21. MIME-type ``application/octet-stream``. The ``.wasm`` file is the WebAssembly
  22. module, delivered as ``application/wasm``.
  23. Delivering the files with gzip compression is recommended especially for the
  24. ``.pck``, ``.asm.js``, ``.mem`` and ``.wasm`` files, which are usually large in
  25. size.
  26. Export options
  27. --------------
  28. If a runnable web export template is available, a button appears between the
  29. *Stop scene* and *Play edited Scene* buttons in the editor to quickly open the
  30. game in the default browser for testing.
  31. **Target** sets the format of the engine. *WebAssembly* is a newer and more
  32. performant technology that is only supported by recent browser versions.
  33. *asm.js* is a highly optimizable subset of JavaScript and supported by some
  34. older browser versions. A 64-bit browser is required to run games in asm.js
  35. format. Most notably, this is a problem with Firefox, which on Windows is
  36. shipped as a 32-bit application by default.
  37. For asm.js **Memory Size** is fixed and must thus be set during export. Try
  38. using no more than necessary to strain users' browsers as little as possible.
  39. For WebAssembly, memory growth is enabled, so this option is not needed nor
  40. displayed.
  41. **Head Include** is appended into the ``<head>`` element of the generated
  42. HTML page. This allows, for example, linking web fonts for use in the page.
  43. Turning on **Debugging Enabled** when exporting will, in addition to enabling
  44. various debug features of the engine, display a debug output below the canvas,
  45. displaying JavaScript and engine errors.
  46. You can also use the browser-integrated developer console, usually opened with
  47. the F12 key, which often shows more information, including WebGL errors.
  48. Web export limitations
  49. ----------------------
  50. Exported files must not be reused
  51. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  52. The exported files ending with ``.html`` and ``fs.js`` are adjusted on export
  53. specifically for that game's version and the given export options. They must
  54. not be reused in futher exports.
  55. Some functions must be called from input callbacks
  56. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  57. Browsers do not allow arbitrarily **entering full screen** at any time. The same
  58. goes for **capturing the cursor**. Instead, these actions have to occur as a
  59. response to a JavaScript input event. In Godot, this is most easily done by
  60. entering full screen from within an input callback such ``_input`` or
  61. ``_unhandled_input``.
  62. Starting exported games from the local file system
  63. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  64. Many browsers will not load exported projects when **opened locally**
  65. per ``file://`` protocol. To get around this, use a local server.
  66. Python offers an easy method for this, using ``python -m SimpleHTTPServer``
  67. with Python 2 or ``python -m http.server`` with Python 3 will serve the current
  68. working directory on ``http://localhost:8000``.
  69. Locale lookup
  70. ~~~~~~~~~~~~~
  71. Godot tries to detect the user's locale using information provided by the
  72. browser, but this is rather unreliable. A better way is to use CGI to read the
  73. HTTP ``Accept-Language`` header. If you assign its value to the JavaScript
  74. property ``Module.locale`` after the ``Module`` objects is created, but before
  75. the engine starts, Godot will use that value to initialize the locale.
  76. In any case, users should always be offered the option to configure the locale
  77. manually.
  78. Calling JavaScript from script
  79. ------------------------------
  80. In web builds, the ``JavaScript`` singleton is available. If offers a single
  81. method called ``eval`` that works similarly to the JavaScript function of the
  82. same name. It takes a string as an argument and executes it as JavaScript code.
  83. This allows interacting with the browser in ways not possible with script
  84. languages integrated into Godot.
  85. In order to keep your code compatible with other platforms, check if the
  86. JavaScript singleton is available before using it::
  87. var JavaScript
  88. func _ready():
  89. # retrieve the singleton here, will return `null` on platforms other than web
  90. JavaScript = Globals.get_singleton("JavaScript")
  91. func my_func():
  92. # call JavaScript.eval only if available
  93. if JavaScript:
  94. JavaScript.eval("alert('Calling JavaScript per GDScript!');")
  95. The return value of the last JavaScript statement is converted to a GDScript
  96. value and returned by ``eval()`` under certain circumstances:
  97. * JavaScript ``number`` is returned as GDScript :ref:`class_int` if it is an
  98. integer or as :ref:`class_float` otherwise
  99. * JavaScript ``boolean`` is returned as GDScript :ref:`class_bool`
  100. * JavaScript ``string`` is returned as GDScript :ref:`class_String`
  101. * JavaScript ``object`` is only converted and returned if it has certain
  102. ``Number``-type properties, listed in order of priority:
  103. * Objects with ``x``, ``y`` and ``z`` properties are returned as a :ref:`class_Vector3`
  104. * Objects with ``x``, ``y``, ``width`` and ``height`` properties are returned as a :ref:`class_Rect2`
  105. * Objects with ``x`` and ``y`` properties are returned as a :ref:`class_Vector2`
  106. * Objects with an ``r``, ``g``, ``b`` and an optional ``a`` property are
  107. returned as a :ref:`class_Color`, the JavaScript values are interpreted
  108. as 8-bit values (0-255) for the color components and
  109. floating point values (0.0-1.0) for the alpha channel
  110. Any other JavaScript value is returned as ``null``.
  111. The ``eval`` method also accepts a second, optional Boolean argument, which
  112. specifies whether to execute the code in the global execution context,
  113. defaulting to ``false`` to prevent polluting the global namespace::
  114. func my_func2():
  115. if JavaScript:
  116. # execute in global execution context,
  117. # thus adding a new JavaScript global variable `MyGlobal`
  118. JavaScript.eval("var MyGlobal = {};", true)