Phaser home
Log inCreate a game

← Expansion packsRenderers

Phaser AE

Renderer (WebGPU or WebGL2)

Free packv3.0.0-32D and 3DRenderers

The renderer every game composes. It tests the device at startup, runs WebGPU where it works and WebGL2 where it does not, from one bundle, and tells the player in plain words when neither can start.

This is a Free pack. Every phaser.io account can use it in their games.

Released October 14, 2026 · updated October 19, 2026

Renderer (WebGPU or WebGL2): a screenshot of its demo
A note about these graphics

Expansion packs don't come with graphics. This screenshot is one way of drawing what the pack does, made for its demo: none of the sprites, tiles or backgrounds in it are in the pack.

That's by design. A pack is a game's logic, mechanics and effects, and it works with whatever art you give it. Some packs draw effects, backdrops or 3D scenes of their own, but none carries a game's sprites.

So the look is yours. Make the art on phaser.io, bring your own, or let your agent draw it in code: the same pack can look like anything.

What it does

A browser that reports WebGPU is not the same as WebGPU working. So at startup the pack tests each backend for real. For WebGPU it requests an adapter and a device, configures a canvas, checks the device's texture limit against the atlas and submits a frame. For WebGL2 it creates a context with the renderer's own settings, checks the texture limit and reads back a cleared pixel. Each test has a ten-second limit. The first to pass, WebGPU before WebGL2, becomes the renderer, and the context it tested is the one the game uses rather than a second one requested later. If WebGPU passes its test but then fails while setting up, WebGL2 is tried next.

When nothing can start, game.start() rejects and an accessible message appears over the canvas, saying the game cannot start and suggesting an updated browser, hardware acceleration or another device. The reason each backend failed is kept in game.renderer.failures, for support and bug reports.

The choice also respects what the game is made of. Every composed pack can declare the backends it supports, so a game with skymax or watermax runs only on WebGPU and says so on a device without it, rather than quietly drawing a simpler sky or sea.

Features

  • Real device tests — an adapter, a device, a context, the texture limit and actual GPU work, not just a check that the API exists.
  • One bundle, two backends — every player gets the same build, and startup chooses.
  • Fallback during setup — WebGPU that passes its test but fails to initialise falls back to WebGL2.
  • A readable failure — an accessible alert with steps to try, instead of a blank canvas.
  • Pack requirements honoured — WebGPU-only packs keep the game on WebGPU, with the reason reported.
  • Diagnostics — game.renderer reports status, backend, ready, error and failures, and game.gpu and game.gl give draw counts for the backend in use.
  • A forced backend for tests — game.renderer.prefer('webgl2') before game.start(), or the backend option.
  • Headless runs — with no page to draw on it skips the device tests and the simulation runs as normal.

Good for

  • Every browser game — one build that runs on WebGPU where it can and on WebGL2 everywhere else.
  • Games played on unknown hardware — each player gets a working game or a clear message, never a black screen.
  • Testing the fallback — force WebGL2 to see exactly what players without WebGPU see.
  • Games built on WebGPU-only effects — skymax skies or watermax oceans, where the game should say it needs WebGPU rather than draw something less.
  • Support — the failure reasons say why a player's device fell back or could not start.

Make it yours

There is one option, backend. 'auto', the default, tries WebGPU and then WebGL2; 'webgpu' or 'webgl2' tests only that one. The same choice can be made in code with game.renderer.prefer before the game starts. Pixel art is a screen setting rather than a renderer one: "pixelArt": true in the manifest's screen keeps scaled sprites crisp on both backends while they still move smoothly between pixels.

Two different uses. A game meant for everyone composes it, or a core bundle that brings it, and never thinks about backends again. A test build sets backend to 'webgl2' to check the game on the fallback path, then to 'webgpu' to check that path alone, with game.renderer.failures saying what went wrong on each.

A quick look

Forcing the fallback for a test, and reading what was chosen:

game.renderer.prefer('webgl2');                 // optional, before start: test the fallback path
await game.start();                             // device tests and setup finish here, or it rejects with an explanation
const { backend, failures } = game.renderer;    // 'webgpu' or 'webgl2', and why any other failed

Works with

Good to know

  • The tests check that a device can start, not how fast it is: it is not a performance ranking, and feature packs still make their own GPU checks.
  • The backend is chosen once, at startup.
  • The WebGL2 path has fewer features: no screen recording, one shadow map rather than cascades, at most eight local lights, and no skymax or watermax.
  • Compose exactly one renderer; a headless test or replay needs none.

More Renderers packs

Show all →