v6.0.0

Do not use: suffers from performance/size regression introduced in v5.0.0. Prefer v6.0.2

Simplified (i.e. flattened) directory structure introduced in v5.0.0, to make it easier to import the library and serve deferred assets.

Inlined SIMD feature detection, eliminating dependency on wasm-feature-detect. This simplifies the entrypoints (fewer files to locate and load in).

Eliminated "ES explicit" entrypoint (now that we are zero-dependency again, we no longer need to cater for differences in ES module resolution).

Simplified UMD entrypoint by writing bespoke loaders for each of CommonJS, AMD and Browser globals.

Tested AMD entrypoint and confirmed working. Can be used by serving a folder with the following assets:

entry.js
Box2D.js
Box2D.wasm
Box2D.simd.js
Box2D.simd.wasm
index.html
main.js
require.js

<!-- load RequireJS library, import main.js -->
<script data-main="main" src="require.js"></script>

// main.js
// import Box2D's umd/entry.js
requirejs(['./entry.js'], function (Box2DFactory) {
  (async () => {
    const box2D = await Box2DFactory();
    console.log(box2D);
  })();
});

v5.0.3

Do not use: suffers from performance/size regression introduced in v5.0.0. Prefer v6.0.2

Additionally: UMD release appears to be broken (was built using a text-replace trick which doesn't work in newer Emscripten)

Updated from Emscripten 2.0.17->2.0.26.

Box2D.js is still 319kB.
Box2D.wasm is 226kB (up from 162kB).

Hopefully the extra code means more performance (more inlining?).
The most dramatic change in the changelog is the LLVM library/runtime updates in Emscripten 2.0.23.

Emscripten 2.0.21 introduces some hints that will help your bundler locate the .wasm asset (and obviate the need to implement locateFile). Will try to determine whether there's any instructions that can be simplified as a result of this.

v5.0.2

Do not use: suffers from performance/size regression introduced in v5.0.0. Prefer v6.0.2

The ES module entrypoint es/entry.js introduced in v5.0.0 relied on NodeJS-style import resolution of the library wasm-feature-detect. This worked in environments where a bundler is available, but not on the Web. An additional entrypoint, es-explicit/entry.js is provided to support ES imports on the Web.

The "modern" demo demonstrates a working configuration of SIMD, and a simpler configuration without SIMD.

v5.0.1

Do not use: suffers from performance/size regression introduced in v5.0.0. Prefer v6.0.2

The UMD module distribution in v5.0.0 was a misnomer — it was actually only ever a CJS module.

5.0.1 introduces a real UMD module, which has been confirmed working in NodeJS and on the Web. It includes an attempt at AMD support, but this is untested.

On the Web, entry.js expects the wasm-feature-detect UMD module to be already-loaded into your webpage, inserted as a <script> tag prior to Box2D's. Additionally it expects
node_modules/box2d-wasm/build/flavour/simd/umd/Box2D.simd.{js,wasm} to be served from /build/flavour/simd/umd, and node_modules/box2d-wasm/build/flavour/standard/umd/Box2D.{js,wasm} to be served from /build/flavour/standard/umd.

The "classic" demo demonstrates a working configuration of SIMD, and a simpler configuration without SIMD.

v5.0.0

Do not use: introduces performance/size regression due to building without optimizations enabled. Prefer v6.0.2

Added support for WebAssembly SIMD acceleration (in supported browsers). This can make specific parts of the code 4x faster (but performance overall is unlikely to be dramatically different).

package.json now specifies the entrypoint to the library as entry.js (rather than pointing directly to Box2D.js). entry.js uses wasm-feature-detect to determine whether SIMD is available on your platform. It will then load in either Box2D.js or Box2D.simd.js as appropriate (after which, said .js file will load in Box2D.wasm or Box2D.simd.wasm respectively).

If you import the ES module distribution of box2d-wasm: entry.js will use ES2020 dynamic import() and ES2017 await to load in Box2D.js or Box2D.simd.js.
The browsers which support dynamic import and async/await are very similar to the ones which support WebAssembly.
You may find that you need to reconfigure your bundler. The Svelte/Rollup demo demonstrates a working configuration (format: 'esm' is the important part).

If you import the UMD module distribution of box2d-wasm: entry.js will use CommonJS require() to load in Box2D.js or Box2D.simd.js.

v4.1.0

Updated Emscripten 2.0.16->2.0.17. This uses LLVM's new pass manager:

Use LLVM's new pass manager by default, as LLVM does. This changes a bunch of things about how LLVM optimizes and inlines, so it may cause noticeable changes in compile times, code size, and speed, either for better or for worse.

In practice, code size seems comparable:
Box2D.js is still 319kB.
Box2D.wasm is 162kB (down from 163kB).

If you encounter any performance regressions, please say so (in case we need to tune --one-caller-inline-max-function-size emscripten-core/emscripten#13899, or revert to legacy pass manager).

Exposed new helpers b2LinearStiffness and b2AngularStiffness:

const { _malloc, _free, b2LinearStiffness, HEAPF32 } = box2D;
// allocate two 4-byte floats on emscripten heap
const output_p = _malloc(Float32Array.BYTES_PER_ELEMENT * 2);
// give Box2D pointers to our floats on the heap, so it can mutate them
b2LinearStiffness(output_p, output_p + Float32Array.BYTES_PER_ELEMENT, 0.9, 0.3, bodyA, bodyB)
// create a Float32Array view over our heap offset, destructure two floats out of it
const [stiffness, damping] = HEAPF32.subarray(output_p >> 2)
// free the memory we allocated
_free(output_p);

const { _malloc, _free, b2AngularStiffness, HEAPF32 } = box2D;
// allocate two 4-byte floats on emscripten heap
const output_p = _malloc(Float32Array.BYTES_PER_ELEMENT * 2);
// give Box2D pointers to our floats on the heap, so it can mutate them
b2AngularStiffness(output_p, output_p + Float32Array.BYTES_PER_ELEMENT, 0.9, 0.3, bodyA, bodyB)
// create a Float32Array view over our heap offset, destructure two floats out of it
const [stiffness, damping] = HEAPF32.subarray(output_p >> 2)
// free the memory we allocated
_free(output_p);

liquidfun-v4.1.0

liquidfun.0 rebased onto v4.1.0.

v4.0.2

Exposed restitutionThreshold on b2Fixture, b2FixtureDef, b2Contact.

liquidfun-v4.0.2

liquidfun.0 rebased onto v4.0.2.

New release versioning convention

Liquidfun releases will now be released under a separate package-name, liquidfun-wasm.
Previously they were specially-tagged releases under the package name box2d-wasm.

This means that if you want to subscribe to a version range like ^4.0.2, you now can (there's no longer any risk that you would get updated to a non-liquidfun release).

New installation instructions

# old way
npm i "[email protected]"

# new way
npm i "box2d-wasm@npm:liquidfun-wasm@^4.0.2"

The new install convention will install liquidfun-wasm under a package alias, box2d-wasm:

"dependencies": {
    "box2d-wasm": "npm:liquidfun-wasm@^4.0.2",

So your source code doesn't need to change (you still import from box2d-wasm), and code snippets from the box2d-wasm documentation will continue to work verbatim with liquidfun-wasm. 🙂

v4.0.1-liquidfun.0

liquidfun.0 rebased onto v4.0.1.

Main reason to upgrade is ~7x faster b2World#Step.