Love.js - A Direct Emscripten Port

[Tanner]

Introducing the 0.11 branch of love.js.

This is a significant departure from the previous version released and is the shape of what I imagine will eventually be the official release of this port.

A few things of note:

• This is compiled with and relies on Emscripten's pthreads. This severely restricts which browsers will run this project but it's necessary to support Love's full range of features; not just Lua threads but also media decoding. It also means that this project cannot be compiled to Web Assembly yet. But fixes for these problems are just a matter of time. If you have an up-to-date browser you likely already have support for SharedArrayBuffers behind a flag and so you can run the multithreaded code even if it's still experimental.
• Errors should properly propagate to the Love error screen now. A long-time frustration of users of the previous version was that errors just killed the process (sometimes without so much as an error message). This fix is brought to us by some in-progress work to reconcile native and browser main loops. Screenshot: https://love2d.org/imgmirrur/Z5EvLBq.png
• We now make much more effective use of the cmake build files. This includes not using the emscripten ports repositories to ensure dependencies are the same across platforms and compile SDL2 with pthreads support. This was, pleasantly, not as big an undertaking as I thought it might be.
• The project is modularized which means that you can run more than one instance on a page. See the provided index.html pages for examples.

How you can help: The easiest way for you to help would be to expanding the testing files with the features you'd like to see. Grab a nightly build of Love 0.11 and run the specs in the repository.

[Ulydev]

Amazing work!! Keep it up!

[undef]

Yaaay!

[Tanner]

I've put together a node.js cli tool to facilitate building using this project.

Ensure you have the latest version of node.js installed and then you can run:

Code: Select all

npm install -g love.js

From that point, creating a new love.js project should be as easy. Running love.js will prompt you for some information and then output all the necessary files to debug and release you game.

For more information, view the help message.

Code: Select all

  Usage: love.js [options] <input> <output>

  Options:

    -h, --help            output usage information
    -V, --version         output the version number
    -t, --title <string>  specify game name
    -m, --memory [bytes]  how much memory your game will require [16777216]

[Ulydev]

I've put together a node.js cli tool to facilitate building using this project.

This. is. amazing.

[D0NM]

Tanner, thank you.

[Tanner]

I wanted to share an update. It may look like this project is stagnating but I want to reiterate my commitment and explain why things are moving slowly.

One of the goals I have with the 0.11.x version of this project was to eliminate that half-measures that I used to hack 0.10.x together. Not properly using the cmake files, not using megasource and not having thread support all necessitated a bunch of hacks that have created significant bit rot on that branch of the project. The eccentricities of that build also generated a lot of error reports and even I found porting anything of any complexity very frustrating as it was a process of trial and error with very bad error messages. The experience was not up to the high standard of the rest of the Love codebase, in my opinion.

As such, I leveraged some very new additions JavaScript: most notably SharedArrayBuffers to make threading possible. This was not a trivial amount of work but I was generally pleased with the results. It wasn't perfect but it was a step in the right direction and I was confident that the situation would only get better once WebAssembly started supporting shared memory threads.

Then 2018 came and, with it, one of the worst computer security disasters of all time: Spectre. Both Chrome and Firefox disabled SharedArrayBuffers by default and lowered the resolution of the browser timer API in an effort to mitigate this new attack vector. It was and still is a very disheartening setback as asking users to go in an enable an experimental flag in their browser is a point of friction that this entire project intended to avoid!

It's not all bad news, I suppose: WebAssembly is making terrific strides in both binary size, speed, features, and robustness; Emscripten browser APIs keep getting better; interfaces like AudioWorklet are awesome solutions to non-blocking media decoding. On a personal note, my experience with this project has helped me get a job using a lot of these technologies building a C++ game engine that targets Emscripten and I'm excited to leverage that experience back to helping this project progress.

I think that by the end of this year we will have a really stable and feature-complete version of Love for the web. It's going to take some patience as we wait for the tech to catch up to our dreams but the groundwork has already been laid. And you know when it's all working cause I'll be the first person using it.

[Nelvin]

Thanks a lot for the update and information and, of course, even more for the great work you're doing.

Even though I'm still in a very early stage with my first project using Löve I'm looking forward to use Love.js in the future.

[jack0088]

thankfully you keep working on it. this is great news!

[yintercept]

This is compiled with and relies on Emscripten's pthreads.

Thats super cool! What was it like implementing that from a technical perspective? What did you have
to change?

not just Lua threads

Wait, you have lua running in the browser? How does the port handle lua? Or is it converted to js first?

It may look like this project is stagnating but I want to reiterate my commitment

Life is slow, and often patience is short, things happen. People get busy.

One of the goals I have with the 0.11.x version of this project was to eliminate that half-measures that I used to hack 0.10.x together

Sometimes it is necessary to get it working first and then fix it as you go, or make it correct after.

very frustrating as it was a process of trial and error with very bad error messages.

Could be worse. Thats been by entire programming ability since day 1. Use it till it breaks. Fix it when it does. Sometimes fix (break) it when it works just fine because it's not done how it should be.
Like writing mandarin in the dark.

one of the worst computer security disasters of all time: Spectre. Both Chrome and Firefox disabled SharedArrayBuffers by default and lowered the resolution of the browser timer API

Their mistakes should not penalize everyone else. Should be a prompt to enable those flags. Can never accomplish anything without *something* going sideways.

WebAssembly is making terrific strides in both binary size, speed, features, and robustness; Emscripten browser APIs keep getting better; interfaces like AudioWorklet

I'm envious that I don't have the time like you and won't get to hack something together with these. Maybe you should do a technical post or two talking about it. I think a number of people would appreciate what you have to write.

On a personal note, my experience with this project has helped me get a job using a lot of these technologies

Congratulations on earning a job doing what you enjoy and are obviously good at.

I think that by the end of this year we will have a really stable and feature-complete version of Love for the web

The future looks bright. Keep up the great work.