Commit Graph

3 Commits

Author SHA1 Message Date
b17ca34de2 Bindata: Embedding Doodads and Levels (for WASM)
* Use `go-bindata` to embed built-in doodads and levels directly into
  the Doodle binary. `make bindata` produces the bindata source file.
* Add `FromJSON()` method to Levels and Doodads to load objects from
  JSON strings in memory (for bindata built-ins or WASM ajax requests)
* Update file loading functions to check the embedded bindata files.
  * pkg/config.go#EditFile:
    * Supports editing a level from bindata (TODO: remove this support)
    * If the "assets/levels/%(simple-name.level)" exists in bindata,
      edits that drawing.
    * No such support for editing built-in doodads.
    * WASM has no filesystem access to edit files except built-in
      levels (yet)
  * pkg/doodads#ListDoodads:
    * Prepends built-in doodads from bindata to the returned list.
    * WASM: no filesystem access so gets only the built-ins.
  * pkg/doodads#LoadFile:
    * Checks built-in bindata store first for doodad files.
    * WASM: tries an HTTP request if not found in bindata but can go no
      further if not found (no filesystem access)
  * pkg/filesystem#FindFile:
    * This function finds a level/doodad by checking all the places.
    * If the level or doodad exists in bindata built-in, always returns
      its system path like "assets/doodads/test.doodad"
    * WASM: always returns the built-in candidate path even if not found
      in bindata so that ajax GET can be attempted.
  * pkg/level#ListSystemLevels:
    * New function that lists the system level files, similar to the
      equivalent doodads function.
    * Prepends the bindata built-in level files.
    * WASM: only returns the built-ins (no filesystem support)
    * Desktop: also lists and returns the assets/levels/ directory.
  * pkg/level#LoadFile:
    * Like the doodads.LoadFile, tries from built-in bindata first, then
      ajax request (WASM) before accessing the filesystem (desktop)
* Menu Scene: TODO, list the built-in levels in the Load Level menu.
  This feature will soon go away when WASM gets its own storage for user
  levels (localStorage instead of filesystem)
2019-06-27 15:07:34 -07:00
ba6892aa95 WASM Texture Caching
* Refactor texture caching in render.Engine:
  * New interface method: NewTexture(filename string, image.Image)
  * WASM immediately encodes the image to PNG and generates a JavaScript
    `Image()` object to load it with a data URI and keep it in memory.
  * SDL2 saves the bitmap to disk as it did before.
  * WASM: deprecate the sessionStorage for holding image data. Session
    storage methods panic if called. The image data is directly kept in
    Go memory as a js.Value holding an Image().
* Shared Memory workaround: the level.Chunk.ToBitmap() function is where
  chunk textures get cached, but it had no access to the render.Engine
  used in the game. The `pkg/shmem` package holds global pointers to
  common structures like the CurrentRenderEngine as a work-around.
  * Also shmem.Flash() so Doodle can make its d.Flash() function
    globally available, any sub-package can now flash text to the screen
    regardless of source code location.
  * JavaScript API for Doodads now has a global Flash() function
    available.
* WASM: Handle window resize so Doodle can recompute its dimensions
  instead of scaling/shrinking the view.
2019-06-27 12:03:52 -07:00
48fc40ade4 Texture Caching for WASM Canvas Engine
* Add RGBA color blending support in WASM build.
* Initial texture caching API for Canvas renderer engine. The WASM build
  writes the chunk caches as a "data:image/png" base64 URL on the
  browser's sessionStorage, for access to copy into the Canvas.
* Separated the ClickEvent from the MouseEvent (motion) in the WASM
  event queue system, to allow clicking and dragging.
* Added the EscapeKey handler, which will abruptly terminate the WASM
  application, same as it kills the window in the desktop build.
* Optimization fix: I discovered that if the user clicks and holds over
  a single pixel when drawing a level, repeated Set() operations were
  firing meaning multiple cache invalidations. Not noticeable on PC but
  on WebAssembly it crippled the browser. Now if the cursor isn't moving
  it doesn't do anything.
2019-06-26 22:44:08 -07:00