For each requested animation frame (RAF) in Phaser, Phaser calls the "update" method, then the "render" method of each scenes.
The "render" method takes some time (and energy) to perform the rendering.
The fact is we probably don't need to call "render" if nothing changed on the screen (which happens most of the frames in a typical WorkAdventure game).
This commit is therefore overloading the "Game" class of Phaser to add a "dirty" flag.
Scenes can now add a "isDirty()" method. If all displayed scenes are pristine (not dirty), Phaser will skip rendering the frame altogether.
This saves "a lot" of energy, resulting in laptops that are not overheating when using WorkAdventure \o/
By default, maps are loaded in HTTPS if WorkAdventure is running in HTTPS, and in HTTP is WorkAdventure is running in HTTP.
Also, if WorkAdventure is running in HTTP and map loading fails, we try map loading in HTTPS (useful when we are working on WorkAdventure locally and want to load a map on a secure domain).
This commit adds the last combination: If WorkAdventure is running in HTTPS, and map loading fails in HTTPS **AND** if the map URL is targetting "localhost", "*.localhost" or "127.0.0.1", then we attempt to load the resource in HTTP.
Why?
"localhost" is considered secure context by modern browsers. So even if a page is loaded in HTTPS, it can load resources from any secure context (including localhost in HTTP).
This means that from "https://play.workadventu.re", I can now test a map running locally on my machine (served by a classic webserver without any certificate).
This change should make map testing easier, since map developers will not have to install the whole WorkAdventure project to test their map locally.
If users are willing to use Typescript to develop scripts for maps, they will need typings for the `WA` object.
This commit creates a new package (@workadventure/iframe-api-typings) that contains only the `iframe_api.d.ts` file.
The file is generated from the build of the front and isolated in this package.
This is necessary because the iframe_api.js file is supposed to always be loaded from WorkAdventure directly (and there is no @workadventure/iframe-api package and there will never be one)
