Input: keyboard, pointer and gamepad

Keyboard goes through named actions

Do not poll key codes. Bind a key to an action string, then poll the action — this is what lets gamepad and virtual controls map onto the same handling.

import { input } from "melonjs";

input.bindKey(input.KEY.LEFT,  "left");
input.bindKey(input.KEY.RIGHT, "right");
input.bindKey(input.KEY.X,     "jump", true);   // true = locked: one press per keydown

// in update()
if (input.isKeyPressed("left"))  { /* … */ }
if (input.isKeyPressed("jump"))  { /* fires once per press, not per frame */ }

The third argument to bindKey is lock (default false). Without it, isKeyPressed stays true for as long as the key is held — correct for movement, wrong for jump or fire. A locked action stays consumed until the key is released or you call input.unlockKey("jump"). Use input.keyStatus(action) when you want the raw held/not-held state regardless of locking.

A poll can miss a press entirely

isKeyPressed is sampled once per frame, and keyup decrements the key's counter the moment it arrives — locked or not. A press that goes down and up between two frames therefore leaves the counter back at zero and is never seen. At 60fps that is anything under ~16ms: rare from a human finger, routine from a synthetic event, and more likely the slower the frame rate.

For a screen where a missed press is a dead end — a splash, a "press any key", a notice to acknowledge — listen for the event instead, which cannot be missed:

import { event } from "melonjs";

// action is the bound action name, or undefined for an unbound key
const onKey = (action) => { if (action === "menuSelect") continue(); };
event.on(event.KEYDOWN, onKey);      // in onResetEvent
event.off(event.KEYDOWN, onKey);     // in onDestroyEvent — it does not self-remove

KEYDOWN fires for every key, bound or not, so matching on action is what narrows it; it also repeats while the key is held, so guard anything that must happen once. Keep polling for movement and for a menu cursor, where one step per press and a key held across a state change are the things that matter.

The full signature is bindKey(keyCode, action, lock?, preventDefault?); preventDefault defaults to input.preventDefault (itself true). Pass the fourth argument per binding, or change the global default with input.setPreventDefault(false) — assigning input.preventDefault = false does not work, it is a read-only module binding.

Pointer events need isKinematic = false

This is the trap. Renderable.isKinematic defaults to true, and both the broadphase and the pointer dispatcher skip any candidate whose isKinematic is still true. The handler registers successfully and simply never fires.

class Button extends Renderable {
    constructor(x, y, w, h) {
        super(x, y, w, h);
        this.isKinematic = false;               // ← required
    }
    onActivateEvent() {
        input.registerPointerEvent("pointerdown", this, this.onDown.bind(this));
    }
    onDeactivateEvent() {
        input.releasePointerEvent("pointerdown", this);
    }
}

Container, Camera2d, Draggable, DropTarget and the UI* elements set it to false for you, and so does attaching a physics body (Body's constructor sets ancestor.isKinematic = false) — so plain Renderable and Sprite subclasses with no body are the ones that catch people.

Register in onActivateEvent and release in onDeactivateEvent, not in the constructor — pooled objects are reused and would otherwise accumulate handlers.

app.viewport works as a whole-screen region when you want global clicks. Note it is asked before everything else, not as a fallback after nothing matched: the dispatcher appends it to the candidate list and walks that list from the end. So a viewport handler must not return false unless it really means to swallow every pointer event in the game.

The accepted event names are exactly "pointerdown", "pointerup", "pointermove", "pointercancel", "pointerenter", "pointerover", "pointerleave" and "wheel". Anything else — "click", "mousedown", "touchstart" — makes both registerPointerEvent and releasePointerEvent throw invalid event type. melonJS maps the canonical name onto whichever mouse/touch events the device actually supports, so you always register the pointer name.

Which object gets the event

The dispatcher collects the regions near the pointer from the broadphase, bounds-checks each one, orders them the way they are drawn and asks the topmost first, walking down until something consumes.

A handler consumes by returning false. This is the DOM sense and it reads backwards: false means handled, and anything else, undefined included, lets the walk carry on to whatever is underneath.

input.registerPointerEvent("pointerdown", this, () => {
    this.fire();
    return false;        // nothing under this gets the click
});

Three things decide the order, and only the first is obvious:

• pos.z, among siblings of one container. Higher is on top.
• Across containers, the common ancestor decides. pos.z is container-local, since autoDepth numbers each container's children from 1, so a button at z = 8 inside one panel does not outrank a second panel at z = 2. The pair is resolved by walking both up to their shared parent and comparing the two siblings there, which is exactly how drawing resolves it. Raise a whole panel with ancestor.moveToTop(panel), not by inflating a child's z.
• A child is asked before the container holding it, since it draws over it.

Equal z between siblings falls back to child order, lower index on top. Two callbacks registered on the same region for the same event run last-registered-first.

Consuming a move also takes the pointer away from the regions below: each one still holding it gets its pointerleave, because it is covered now and being inside its own bounds no longer decides. Consuming a press, a release or a wheel does not, since none of those says where the pointer is.

World coordinates versus screen coordinates

The pointer carries several, and picking the wrong one produces a feedback loop:

property	meaning	use for
pointer.gameScreenX / gameScreenY	canvas-relative position	anything that moves the camera
pointer.gameWorldX / gameWorldY	projected into world space	picking and spawning objects
pointer.gameLocalX / gameLocalY	relative to the region's ancestor container	hit-testing inside a container
pointer.gameX / gameY	context-dependent — see below	region handlers on non-floating regions

gameX/gameY is not a fixed coordinate space. The dispatcher rewrites it per candidate just before calling your handler: world coordinates for a normal region, screen coordinates for a isFloating === true region. On the global event.POINTERMOVE broadcast it is set to the screen coordinates. When you need one specific space, read gameWorldX/gameWorldY or gameScreenX/gameScreenY by name rather than relying on gameX.

Using world coordinates for a camera-orbit drag means the same pixel maps to a different world point every frame as the camera moves — the drag jumps wildly.

Pointer move and release outside a region

Region handlers only fire while the pointer is over the region. For drag tracking, listen globally:

import { event } from "melonjs";
event.on(event.POINTERMOVE, (pointer) => { /* … */ });

There is no global pointer-up system event — event.ts publishes only POINTERMOVE, POINTERLOCKCHANGE, DRAGSTART and DRAGEND. For "released anywhere" you need a raw listener:

globalThis.addEventListener("pointerup", onRelease);

For plain drag-and-drop, Draggable / DropTarget already wire all of this up (pointerdown / pointerup / pointercancel regions plus a global POINTERMOVE listener) and emit event.DRAGSTART / event.DRAGEND. DRAGEND still originates from a region handler, so it only fires when the release lands on the draggable itself.

Gamepad

Gamepad input maps onto the same action strings, so game code does not branch:

input.bindGamepad(0,
    { type: "buttons", code: input.GAMEPAD.BUTTONS.FACE_1 },
    input.KEY.X);        // → the "jump" action bound above

Order matters: bindGamepad throws no action defined for keycode N if the keycode has not already been passed to bindKey.

Axes use the same call with a threshold, and bind one half of the axis each — the sign selects which half:

input.bindGamepad(0, { type: "axes", code: input.GAMEPAD.AXES.LX, threshold: -0.15 }, input.KEY.LEFT);
input.bindGamepad(0, { type: "axes", code: input.GAMEPAD.AXES.LX, threshold:  0.15 }, input.KEY.RIGHT);

threshold is added to the deadzone, it does not replace it. The test is abs(value) >= deadzone + abs(threshold), so with the default deadzone of 0.1 a threshold of 0.5 does not fire until 0.6 of full travel, and 0.15 fires at 0.25. Pick the number you want the stick to break at and subtract the deadzone. Raising setGamepadDeadzone moves every axis binding with it.

unbindGamepad(index, button, type?), setGamepadDeadzone(value) and setGamepadMapping(id, mapping) complete the surface.

Which index to bind

Bindings are per pad index, and the index is plug order, not identity — nothing reports which pad is "the" controller. Slot 0 is a guess: a wheel, a spare pad or a keyboard-shaped device left plugged in can hold it for a whole session while the player presses buttons on slot 1.

So a one-player game binds every slot it will accept to the same actions, and lets activeGamepad() say which one is in use when something has to go back the other way:

for (let pad = 0; pad < 4; pad++) {
    input.bindGamepad(pad, { type: "buttons", code: input.GAMEPAD.BUTTONS.FACE_1 }, input.KEY.X);
}
input.activeGamepad();   // the last pad to produce a bound input, else the
                         // first connected one, else -1

Binding spare slots costs nothing: the poll skips a bound index with no pad in it. activeGamepad() follows bound inputs only, which is what makes it an answer about the player rather than about electrical noise — a worn stick at rest reports movement for ever and would otherwise claim to be the active pad.

Rumble

input.vibrateGamepad(input.activeGamepad(), {
    duration: 120, strongMagnitude: 0.6, weakMagnitude: 0.9,
});
input.stopGamepadVibration(index);   // cut a long effect short
input.hasGamepadVibration(index);    // for an options-screen toggle

Safe to call blind: no pad, no motors, or no Gamepad API at all resolves false and does nothing, so game code never branches on support. Magnitudes default to full — the underlying web API defaults every parameter to zero, which makes a bare playEffect a silent no-op. A second call preempts the first on the same pad, so a rapid series of hits reads as a rapid series of hits rather than as a queue. For a SUSTAINED rumble issue one effect with a long duration instead of calling every frame.

Hot-plugging needs no polling of your own — the engine listens for the browser's own events and republishes them:

import { event } from "melonjs";

event.on(event.GAMEPAD_CONNECTED,    (gamepad) => { /* gamepad.id, .index */ });
event.on(event.GAMEPAD_DISCONNECTED, (gamepad) => { /* pause, show a prompt */ });

Bindings survive a disconnect: they are attached to the index, not to the device, so a pad unplugged and plugged back into the same slot keeps working.

Virtual controls

On-screen buttons synthesise key events, again reaching the same actions:

input.triggerKeyEvent(input.KEY.LEFT, true);    // press
input.triggerKeyEvent(input.KEY.LEFT, false);   // release

Symptom → cause

symptom	cause
pointer handler never fires	isKinematic left at its true default
handlers fire twice, or on dead objects	registered in the constructor instead of onActivateEvent
camera drag jumps around	using world coordinates instead of gameScreenX/gameScreenY
gameX holds screen coords where world coords were expected	read on event.POINTERMOVE, or on a floating region — use gameWorldX/gameWorldY
drag stops when leaving the object	region events end at the region — use event.POINTERMOVE
release never detected outside the region	no global pointer-up event — add a raw listener
jump fires every frame while held	bindKey without its third lock argument
invalid event type thrown at registration	non-pointer name ("click", "mousedown", …) passed to registerPointerEvent
no action defined for keycode N	bindGamepad called before bindKey for that keycode
stick has to be pushed well past its threshold before it registers	threshold is ADDED to the deadzone, not used instead of it
one half of a stick does nothing	each half is a separate bindGamepad, chosen by the sign of threshold
a widget under an overlapping panel still reacts	the panel consumes nothing — return false from its onClick and onOver
a widget stays highlighted after the pointer moves onto a panel over it	the panel consumes no pointermove, so nothing takes the pointer off the widget
a child's big z does not put it in front of another container	pos.z is container-local — use ancestor.moveToTop() on the container
every click in the game stops working	a handler on app.viewport returning false, which is asked first

Related skills

• melonjs-renderables — isKinematic also gates the physics broadphase
• melonjs-ui-and-text — UISpriteElement and UITextButton handle this for you