Balls in a Circle

[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_180":181,"_182":183},"routes/_app.x.$handle.$name",{"_97":96,"_32":45,"_105":87,"_27":106,"_13":14,"_107":-5,"_11":108,"_109":110,"_111":112,"_113":114,"_115":116,"_20":-5,"_117":-5,"_118":-5,"_119":25,"_120":121,"_122":59,"_123":-5,"_124":-5,"_125":126},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_43":44,"_32":45,"_38":46,"_47":-5,"_48":25,"_49":50,"_51":50,"_52":53,"_54":-5,"_18":55,"_56":57,"_58":59,"_60":-5,"_61":-5,"_62":63,"_64":65,"_66":-5,"_67":-5,"_68":-5,"_69":-5,"_70":71,"_72":71,"_73":74,"_75":74,"_76":74,"_77":71,"_78":71,"_79":80,"_81":82,"_83":84,"_85":25},"version",64,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":23,"_24":25,"_26":25,"_27":28,"_29":28},"file",{"_30":31,"_32":28,"_33":34,"_35":37,"_38":39,"_40":14,"_41":42,"_24":25},"previous",{"_30":31,"_32":28,"_33":34,"_35":36},"deleted",false,"deletedHere","path","sim.js","latestPath","fileId","962d4e18-a975-11f1-a4db-1607ee4eb77e","name","fileType","script","content","// =====================================================================\n// Balls in a circle\n// =====================================================================\n//\n// Two balls bounce inside a circle. Every time two of them collide, a third\n// is spawned. When the disc is so full that there is nowhere left to put a\n// new ball, the wall switches off and everything bursts out of the view.\n//\n// The physics rules, stated once so the code below can be checked against\n// them:\n//\n// * Between impacts a ball moves under gravity alone — a parabola.\n// * A bounce off the wall changes direction but never speed.\n// * A ball-ball collision is perfectly elastic between equal masses.\n// * Nothing damps, so total energy only ever goes up (see \"Energy\" below).\n//\n// The interesting part of this file is not the physics, which is a page of\n// vector algebra, but everything around it: how thousands of balls are\n// stored, how collisions are found without comparing every pair, and how a\n// spawn point is chosen without scanning the whole population. Those three\n// problems drove nearly every design decision here, and the comments call\n// out what the earlier, slower versions of each one looked like.\n//\n// A note on where this file lives: it is served at /sim.js by main.tsx and\n// loaded as a module by index.html. Module scripts are deferred and get\n// their own scope, which is why there is no IIFE wrapper and no \"use strict\"\n// — both are automatic.\n\n// ---------------------------------------------------------------------\n// DOM handles\n// ---------------------------------------------------------------------\n\nconst canvas = document.getElementById(\"c\");\nconst ctx = canvas.getContext(\"2d\");\nconst countEl = document.getElementById(\"count\");\nconst gravityBtn = document.getElementById(\"gravity\");\nconst resetBtn = document.getElementById(\"reset\");\n\nconst TAU = Math.PI * 2; // one full turn; every angle here is in radians\n\n// ---------------------------------------------------------------------\n// Tuning constants\n// ---------------------------------------------------------------------\n//\n// Anything measured in pixels is described at a REFERENCE VIEW SIZE rather\n// than in absolute terms, and scaled to the actual view in fit(). The reason\n// is worth understanding, because it took a bug report to find.\n//\n// Originally the ball radius was a flat 5.5px at every window size. That\n// seems harmless, but the number of balls that fit in the disc before it\n// saturates goes as (disc area / ball area) = radius^2 / ballRadius^2. Fix\n// the ball size and that ratio grows with the square of the window. A large\n// monitor held twice as many balls at break-out as a small one, and since\n// the expensive searches cost more per ball AND there were more balls, the\n// endgame got dramatically slower on big screens.\n//\n// Tying ball size to the view fixes the saturation count everywhere. Once\n// lengths scale, velocities and accelerations have to scale with them or the\n// motion stops looking the same: if lengths scale by s and time is left\n// alone, then v = dx/dt scales by s, and a = dv/dt scales by s as well. All\n// linear. (An earlier claim in conversation that gravity should scale as s^2\n// was wrong — that would only be true if the time axis were also stretched.)\n\nconst REF_VIEW = 600; // view size the reference numbers describe\nconst REF_BALL_R = 5.5; // ball radius, px, at the reference size\nconst MIN_BALL_R = 3; // floor, so tiny windows stay visible\nconst SPAWN_GAP_RATIO = 7 / 5.5; // required space around a new ball, in radii\nconst CELL_RATIO = 2.5; // broad-phase cell size, in radii\nconst REF_SPEED = 175; // px/sec launch speed at the reference size\nconst REF_GRAVITY = 260; // px/sec^2 down: enough to arc, not to slam\nconst REF_MAX_SPEED = 1500; // clamp, so nothing can tunnel the wall\nconst REF_BURST = 240; // outward kick, px/sec, at break-out\n\n// Search budgets. PLACE_TRIES is how many candidate points a spawn considers.\n// QUICK_TRIES is the reduced budget used once we already believe the disc is\n// packed — see spawnBall for why it is reduced rather than skipped entirely.\n// HOPELESS_AFTER abandons a sweep that has found no room in its first several\n// dozen samples. DIR_TRIES is how many launch headings are compared.\nconst PLACE_TRIES = 400;\nconst QUICK_TRIES = 12;\nconst HOPELESS_AFTER = 64;\nconst DIR_TRIES = 32;\n\n// STEP is the fixed physics timestep. 240Hz is well above the display rate;\n// small steps keep fast balls from passing through walls or each other in a\n// single update. MAX_STEPS bounds how much catch-up one frame may attempt —\n// see the frame loop at the bottom for the failure mode it prevents.\nconst STEP = 1 / 240;\nconst MAX_STEPS = 6;\n\n// CROWD_LIMIT is how many consecutive \"nowhere to put it\" spawns count as\n// proof that the disc is full and it is time to break out.\nconst CROWD_LIMIT = 4;\n\n// Hue advances in fixed increments, so only 360 fill styles are ever needed.\n// Building them once means draw() never allocates a string and the canvas can\n// reuse its parsed style. The earlier version stored a per-ball color string,\n// which meant one string object per ball and a fresh parse on every fill.\nconst COLORS = Array.from({ length: 360 }, (unused, h) => `hsl(${h} 92% 62%)`);\n\n// ---------------------------------------------------------------------\n// Derived state\n// ---------------------------------------------------------------------\n//\n// Everything here is in pixels or pixels/second, so all of it is recomputed\n// against the current view size on every resize. They are `let` rather than\n// `const` for exactly that reason — the naming convention is deliberate:\n// SHOUTY_CASE means \"fixed forever\", lowercase means \"recomputed\".\n\nlet scale = 1;\nlet ballR = REF_BALL_R;\nlet spawnGap = REF_BALL_R * SPAWN_GAP_RATIO;\nlet cell = REF_BALL_R * CELL_RATIO;\nlet speed = REF_SPEED;\nlet gravity = REF_GRAVITY;\nlet maxSpeed = REF_MAX_SPEED;\nlet burst = REF_BURST;\n\nlet gravityOn = true;\nlet brokenOut = false;\nlet crowded = 0; // consecutive spawns that found no room\nlet hue = 200;\nlet centerX = 0;\nlet centerY = 0;\nlet radius = 0; // radius of the circular wall\nlet viewSize = 0; // the canvas is square, so one number covers both axes\n\n// ---------------------------------------------------------------------\n// Ball storage: struct of arrays\n// ---------------------------------------------------------------------\n//\n// The obvious representation is an array of objects:\n//\n// balls = [{ x, y, vx, vy, r, color }, ...]\n//\n// and that is what this started as. It reads beautifully and it is the wrong\n// shape once there are thousands of them. Each ball is a separate heap\n// object; the array holds pointers, so walking it chases references all over\n// memory, and every spawn allocates. At a few thousand balls updated 240\n// times a second, that is a lot of pointer chasing and a lot of garbage.\n//\n// A struct of arrays inverts it: one contiguous typed array per field, and an\n// integer index in place of an object reference. Iterating xs[] walks memory\n// in a straight line, which is what caches and JITs are built for, and\n// spawning writes into pre-allocated slots instead of allocating.\n//\n// The cost is ergonomic. There is no longer a \"ball\" you can pass around —\n// functions take indices and reach into the arrays, so `b.vx` becomes\n// `vxs[i]`. Everything is more verbose and slightly easier to get wrong. It\n// is a real trade, worth making here and not worth making for fifty balls.\n//\n// Float32 is plenty: about 7 significant digits, so a coordinate up to a few\n// thousand pixels is exact to well under a thousandth of a pixel. All the\n// arithmetic below still happens in doubles; only the stored result rounds.\n//\n// rs[] holds a per-ball radius even though every ball currently has the same\n// one. It costs one array and keeps the code honest if balls ever differ.\n\nlet capacity = 0; // allocated slots\nlet count = 0; // live balls; slots [0, count) are meaningful\nlet xs = null;\nlet ys = null;\nlet vxs = null;\nlet vys = null;\nlet rs = null;\nlet hues = null;\nlet next = null; // broad-phase chain; see the grid section\n\n// Grow by doubling rather than by one. Doubling makes the total copying work\n// across a run linear in the final size — the array reallocates a handful of\n// times over thousands of spawns, instead of once per spawn.\nconst ensureCapacity = (needed) => {\n if (needed <= capacity) return;\n let size = capacity || 256;\n while (size < needed) size *= 2;\n\n const grown = (src) => {\n const out = new Float32Array(size);\n if (src) out.set(src);\n return out;\n };\n xs = grown(xs);\n ys = grown(ys);\n vxs = grown(vxs);\n vys = grown(vys);\n rs = grown(rs);\n\n const nextHues = new Uint16Array(size);\n if (hues) nextHues.set(hues);\n hues = nextHues;\n\n // `next` must be copied too, even though it is rebuilt every step. During a\n // burst of spawns the grid is live and its chains run through this array;\n // growing without copying silently corrupted them. That bug was invisible\n // until the exact moment a spawn burst crossed a capacity boundary.\n const nextChain = new Int32Array(size);\n if (next) nextChain.set(next);\n next = nextChain;\n\n capacity = size;\n};\n\nconst addBall = (x, y, angle) => {\n ensureCapacity(count + 1);\n hue = (hue + 71) % 360; // 71 is coprime with 360, so hues spread out\n xs[count] = x;\n ys[count] = y;\n vxs[count] = Math.cos(angle) * speed;\n vys[count] = Math.sin(angle) * speed;\n rs[count] = ballR;\n hues[count] = hue;\n count++;\n gridInsert(count - 1); // keep the broad phase usable between rebuilds\n};\n\n// Removal is a swap with the last live slot, then a decrement. Order carries\n// no meaning here — nothing indexes a ball by position — so there is no\n// reason to pay for the shift that splice() would do. O(1) and no allocation.\n//\n// The version before this rebuilt the entire array with filter() on every\n// frame of the escape phase, which allocated a fresh array per frame at\n// precisely the moment the simulation was most loaded.\nconst removeAt = (i) => {\n count--;\n if (i === count) return;\n xs[i] = xs[count];\n ys[i] = ys[count];\n vxs[i] = vxs[count];\n vys[i] = vys[count];\n rs[i] = rs[count];\n hues[i] = hues[count];\n};\n\n// ---------------------------------------------------------------------\n// Layout\n// ---------------------------------------------------------------------\n\nconst fit = () => {\n const size = Math.max(240, Math.min(window.innerWidth - 16, window.innerHeight - 90));\n\n // Canvas has two sizes: the CSS box it occupies and its backing-store\n // resolution. Setting the backing store to size * devicePixelRatio and\n // scaling the context by the same factor gives crisp output on a retina\n // display while letting all the drawing code work in CSS pixels.\n const dpr = window.devicePixelRatio ?? 1;\n canvas.style.width = `${size}px`;\n canvas.style.height = `${size}px`;\n canvas.width = Math.round(size * dpr);\n canvas.height = Math.round(size * dpr);\n ctx.setTransform(dpr, 0, 0, dpr, 0, 0);\n\n viewSize = size;\n centerX = size / 2;\n centerY = size / 2;\n radius = size / 2 - 6;\n\n // Rescale the simulation. See the tuning-constants section for why this is\n // a single linear factor applied to lengths, velocities and accelerations\n // alike.\n const nextScale = size / REF_VIEW;\n const ratio = nextScale / scale;\n scale = nextScale;\n\n ballR = Math.max(MIN_BALL_R, REF_BALL_R * scale);\n spawnGap = ballR * SPAWN_GAP_RATIO;\n cell = ballR * CELL_RATIO;\n speed = REF_SPEED * scale;\n gravity = REF_GRAVITY * scale;\n maxSpeed = REF_MAX_SPEED * scale;\n burst = REF_BURST * scale;\n\n resizeGrid();\n\n // How far the clearance search has to look: far enough to see any ball that\n // could sit within the capped clearance, plus a cell of slack.\n querySpan = Math.ceil((spawnGap * 3 + 2 * ballR) / cell) + 1;\n\n // Balls already in flight keep their trajectories under the new scale.\n // Without this, a resize mid-run would leave everything moving at the wrong\n // speed for its new size.\n for (let i = 0; i < count; i++) {\n rs[i] = ballR;\n vxs[i] *= ratio;\n vys[i] *= ratio;\n }\n};\n\nconst reset = () => {\n brokenOut = false;\n crowded = 0;\n count = 0; // no deallocation needed: the slots are simply reused\n addBall(centerX - radius * 0.45, centerY - radius * 0.1, 0.35);\n addBall(centerX + radius * 0.45, centerY + radius * 0.1, Math.PI * 1.18);\n};\n\n// ---------------------------------------------------------------------\n// Physics: the wall\n// ---------------------------------------------------------------------\n//\n// A circular wall is the easiest possible collision geometry, because the\n// surface normal at the point of contact is just the radial direction. There\n// is no edge to identify and no per-wall normal to look up, unlike a polygon.\n//\n// The bounce is the standard reflection, v -= 2(v·n)n, and it is worth\n// unpacking because it carries the \"speed never changes\" guarantee:\n//\n// * n is the outward unit normal. Dividing (dx, dy) by its own length\n// gives a vector of length 1 pointing the same way: the length of\n// (dx/d, dy/d) is sqrt((dx^2 + dy^2)/d^2) = sqrt(d^2/d^2) = 1.\n// * v·n is the dot product. Because n has unit length, it equals\n// |v|cos(theta) — the signed amount of the velocity pointing along the\n// normal. Positive means moving outward, into the wall.\n// * Subtracting (v·n)n once would cancel the outward component, leaving\n// the ball sliding along the wall. Subtracting it twice flips that\n// component inward and leaves the tangential part untouched.\n//\n// Only one of two perpendicular components changes sign, so the magnitude is\n// unchanged — the hypotenuse of a right triangle does not care about the sign\n// of a leg. Speed preservation falls out of the geometry rather than being\n// enforced by a separate correction.\nconst wallBounce = (i) => {\n const dx = xs[i] - centerX;\n const dy = ys[i] - centerY;\n const d = Math.hypot(dx, dy);\n const lim = radius - rs[i];\n\n // Nothing to do unless the ball is poking through the wall. The d === 0\n // guard is for a ball exactly at the centre, where there is no meaningful\n // direction and dividing by d would produce NaN.\n if (d <= lim || d === 0) return;\n\n const nx = dx / d;\n const ny = dy / d;\n\n // Position correction: put the ball back on the boundary along the same\n // radial line. Without this it would still be outside next step, drifting\n // further out each time (the reflection below only fires on approach), and\n // would eventually escape. The overshoot is at most one step of travel —\n // sub-pixel at 240Hz — so the snap is invisible.\n xs[i] = centerX + nx * lim;\n ys[i] = centerY + ny * lim;\n\n const vn = vxs[i] * nx + vys[i] * ny;\n\n // The vn > 0 guard matters more than it looks. A ball can be outside the\n // boundary while already heading back inward — usually because another ball\n // shoved it out. Reflecting then would flip an inward velocity to outward\n // and fire it straight through the wall.\n if (vn > 0) {\n vxs[i] -= 2 * vn * nx;\n vys[i] -= 2 * vn * ny;\n }\n};\n\n// After break-out the circle is inert and balls leave the view. With gravity\n// on they need something to land on, so the bottom edge becomes a floor.\n// Same reflection as above, but the normal is a constant (0, -1), which\n// collapses the whole calculation to flipping the sign of vy.\nconst floorBounce = (i) => {\n const lim = viewSize - rs[i];\n if (ys[i] < lim) return;\n ys[i] = lim;\n if (vys[i] > 0) vys[i] = -vys[i];\n};\n\n// The disc is packed: switch the wall off and kick everything outward.\n//\n// The kick is cosmetic — the pile is already under enormous pressure and\n// would spread on its own — but without it the escape oozes rather than\n// bursts, which reads as a bug rather than an event.\nconst breakOut = () => {\n brokenOut = true;\n for (let i = 0; i < count; i++) {\n let dx = xs[i] - centerX;\n let dy = ys[i] - centerY;\n let d = Math.hypot(dx, dy);\n if (d < 1e-6) { // a ball exactly at the centre has no outward direction\n const angle = Math.random() * TAU;\n dx = Math.cos(angle);\n dy = Math.sin(angle);\n d = 1;\n }\n vxs[i] += (dx / d) * burst;\n vys[i] += (dy / d) * burst;\n }\n};\n\n// ---------------------------------------------------------------------\n// Physics: ball against ball\n// ---------------------------------------------------------------------\n//\n// Elastic collision between equal masses has a famously tidy result: the two\n// bodies swap the components of their velocities along the line of centres,\n// and their tangential components are untouched. Solving conservation of\n// momentum and kinetic energy simultaneously for equal masses gives exactly\n// that, which is why there is no mass term anywhere below.\n//\n// Note the structure is the same as the wall bounce — decompose along a\n// normal, act only on the normal component, leave the tangent alone. The\n// difference is that here the normal points from one ball to the other rather\n// than from a wall, and the component is exchanged rather than reversed.\n//\n// This is a discrete-time approximation. A \"proper\" continuous-collision\n// solver would compute the exact time of impact within the step, rewind both\n// balls to it, resolve, and replay the remainder. That is the right approach\n// for a few fast objects; it is the wrong approach for a jammed pile of\n// thousands, where impacts are near-simultaneous and the exact ordering does\n// not survive the next step anyway. A small fixed timestep plus overlap\n// correction is cheaper and stable under crowding.\nconst pairCollide = (i, j) => {\n let dx = xs[j] - xs[i];\n let dy = ys[j] - ys[i];\n let d = Math.hypot(dx, dy);\n const min = rs[i] + rs[j];\n if (d >= min) return false; // not touching\n\n if (d === 0) { // exactly coincident: pick an arbitrary axis to separate on\n dx = 1;\n dy = 0;\n d = 1e-6;\n }\n\n const nx = dx / d;\n const ny = dy / d;\n\n // Positional correction: push each ball half the overlap apart, plus a hair\n // extra so they are not left exactly touching. Without this, overlapping\n // pairs would re-trigger every step and the pile would sink into itself.\n //\n // This is also where the simulation quietly gains energy. Separating two\n // balls does work on them for free, and in a jam there are hundreds of\n // these corrections per step. It is why the pile is so hot by the time it\n // bursts. The 0.01 term is the tunable part of that.\n const push = (min - d) / 2 + 0.01;\n xs[i] -= nx * push;\n ys[i] -= ny * push;\n xs[j] += nx * push;\n ys[j] += ny * push;\n\n const an = vxs[i] * nx + vys[i] * ny;\n const bn = vxs[j] * nx + vys[j] * ny;\n\n // Overlapping but already moving apart. This happens constantly in a\n // crowded pile — a pair gets separated by the correction above, or shoved\n // apart by a third ball. Treating it as an impact would inject energy and,\n // worse, would count as a collision and spawn another ball, so a stuck pair\n // would breed forever.\n if (an - bn <= 0) return false;\n\n vxs[i] += (bn - an) * nx;\n vys[i] += (bn - an) * ny;\n vxs[j] += (an - bn) * nx;\n vys[j] += (an - bn) * ny;\n return true;\n};\n\n// ---------------------------------------------------------------------\n// Broad phase: finding candidate pairs\n// ---------------------------------------------------------------------\n//\n// The naive way to find collisions is to test every pair:\n//\n// for (i) for (j > i) pairCollide(i, j)\n//\n// That is O(n^2), and this simulation is a machine for producing large n. At\n// 2000 balls it is two million tests per step, 240 steps a second — utterly\n// impossible. This was the original implementation and it was the single\n// biggest source of the stall before break-out.\n//\n// The fix is a uniform grid. Balls are bucketed by position into square\n// cells, and each ball only tests its own cell and the eight around it. If\n// cells are at least as wide as the largest possible contact distance, a 3x3\n// neighbourhood provably cannot miss a touching pair. Cost drops to roughly\n// O(n), because the number of balls near any given ball is bounded by\n// geometry rather than by the population.\n//\n// Two implementation details are worth more than they look:\n//\n// STORAGE. The first version was a Map from a hashed cell key to an Array of\n// indices, rebuilt each step. That allocates one array per occupied cell per\n// step. It is now a flat Int32Array of cell heads, with next[] chaining the\n// rest — a linked list threaded through typed arrays. Rebuilding is a fill()\n// plus one write per ball, and allocates nothing at all.\n//\n// INDEXING VS HASHING. Dropping the Map matters because clearanceAt() below\n// does roughly 80 cell lookups per candidate point, and there can be dozens\n// of candidates per spawn and dozens of spawns per step. Array indexing is a\n// couple of nanoseconds; hashing is tens. That difference alone would have\n// eaten the entire benefit of using the grid for placement.\n//\n// Because cell size scales with ball radius, and ball radius scales with the\n// view, the total cell count is roughly constant (~2000) at any window size.\n// The fill() per rebuild is therefore trivially cheap and does not grow.\n\nconst GRID_PAD = 4; // cells of margin, for balls that have left the view\nlet gridW = 0;\nlet gridH = 0;\nlet heads = null; // heads[c] = index of first ball in cell c, or -1\nlet querySpan = 3; // cells the clearance search reaches; set in fit()\n\nconst resizeGrid = () => {\n gridW = Math.ceil(viewSize / cell) + GRID_PAD * 2;\n gridH = gridW; // the canvas is square\n heads = new Int32Array(gridW * gridH);\n heads.fill(-1);\n};\n\n// Column and row for a position, clamped into the grid. Escaped balls get\n// folded into the edge cells rather than being dropped. That costs a few\n// redundant pair tests out beyond the view and never misses a real one:\n// two neighbouring balls outside the grid clamp to the same or adjacent\n// cells, so they still find each other.\nconst gridCol = (x) => {\n const c = Math.floor(x / cell) + GRID_PAD;\n return c < 0 ? 0 : c >= gridW ? gridW - 1 : c;\n};\n\nconst gridRow = (y) => {\n const c = Math.floor(y / cell) + GRID_PAD;\n return c < 0 ? 0 : c >= gridH ? gridH - 1 : c;\n};\n\n// Push one ball onto the front of its cell's chain. Called from addBall so a\n// burst of spawns stays consistent without rebuilding the whole grid per ball.\nconst gridInsert = (i) => {\n if (!heads) return; // before the first fit()\n const c = gridRow(ys[i]) * gridW + gridCol(xs[i]);\n next[i] = heads[c];\n heads[c] = i;\n};\n\nconst buildGrid = () => {\n heads.fill(-1);\n for (let i = 0; i < count; i++) {\n const c = gridRow(ys[i]) * gridW + gridCol(xs[i]);\n next[i] = heads[c];\n heads[c] = i;\n }\n};\n\n// Returns the number of genuine impacts, which is what drives spawning.\n//\n// The j > i test is how each pair gets resolved exactly once. Both balls of a\n// pair see each other in their 3x3 neighbourhoods, so without it every\n// collision would be applied twice — and would count as two impacts, and\n// spawn two balls.\nconst collideAll = () => {\n buildGrid();\n\n let impacts = 0;\n for (let i = 0; i < count; i++) {\n const cx = gridCol(xs[i]);\n const cy = gridRow(ys[i]);\n for (let ox = -1; ox <= 1; ox++) {\n const gx = cx + ox;\n if (gx < 0 || gx >= gridW) continue;\n for (let oy = -1; oy <= 1; oy++) {\n const gy = cy + oy;\n if (gy < 0 || gy >= gridH) continue;\n let j = heads[gy * gridW + gx];\n while (j !== -1) {\n if (j > i && pairCollide(i, j)) impacts++;\n j = next[j];\n }\n }\n }\n }\n return impacts;\n};\n\n// ---------------------------------------------------------------------\n// The step\n// ---------------------------------------------------------------------\n\nconst isOffScreen = (i) =>\n xs[i] + rs[i] < 0 || xs[i] - rs[i] > viewSize ||\n ys[i] + rs[i] < 0 || ys[i] - rs[i] > viewSize;\n\n// Order of operations within a step: integrate, then resolve walls, then\n// resolve ball-ball, then spawn. Walls before balls means a ball shoved\n// through the wall by a neighbour is corrected before anything else looks at\n// it; spawning last means new balls do not get integrated on the step they\n// were born.\nconst step = (dt) => {\n for (let i = 0; i < count; i++) {\n // Semi-implicit (symplectic) Euler: update velocity first, then use the\n // NEW velocity to update position. The one-line difference from plain\n // Euler — which would move using the old velocity — buys much better\n // energy behaviour over long runs, and it is why a bouncing ball here\n // does not slowly climb higher and higher on its own.\n if (gravityOn) vys[i] += gravity * dt;\n\n // Speed clamp. Purely defensive: if numerical drift ever produced a\n // ridiculous velocity, a ball could cross the wall entirely within one\n // step and escape. In normal operation this never fires.\n const mag = Math.hypot(vxs[i], vys[i]);\n if (mag > maxSpeed) {\n vxs[i] *= maxSpeed / mag;\n vys[i] *= maxSpeed / mag;\n }\n\n xs[i] += vxs[i] * dt;\n ys[i] += vys[i] * dt;\n }\n\n for (let i = 0; i < count; i++) {\n if (!brokenOut) wallBounce(i);\n else if (gravityOn) floorBounce(i);\n }\n\n const impacts = collideAll();\n\n if (!brokenOut) {\n // Collision resolution nudged positions, so rebuild before the placement\n // searches read the grid. New balls insert themselves as they arrive.\n if (impacts > 0) buildGrid();\n for (let i = 0; i < impacts; i++) spawnBall();\n } else {\n // Escaped balls stop breeding, and are dropped once fully out of view.\n // Walking backwards is what makes swap-removal safe here: the ball\n // swapped into slot i comes from a higher index, which this loop has\n // already visited and judged.\n for (let i = count - 1; i >= 0; i--) {\n if (isOffScreen(i)) removeAt(i);\n }\n }\n};\n\n// ---------------------------------------------------------------------\n// Spawning\n// ---------------------------------------------------------------------\n//\n// Every collision produces a ball, and the original requirement was that a\n// new ball must not be placed where it would immediately collide. That turns\n// out to be two separate questions: WHERE to put it, and WHICH WAY to send\n// it. A spot can be perfectly clear and still be a bad start if the ball is\n// launched straight at a neighbour.\n//\n// The approach here is rejection sampling with a best-of-N fallback: throw\n// darts at the disc, score each by how much empty space surrounds it, and\n// keep the best. This is not the only option. A maintained free-space\n// structure (a quadtree of empty regions, say) could answer \"where is there\n// room\" exactly, but it has to be updated as thousands of balls move every\n// step, which costs far more than the sampling it would replace. Sampling is\n// approximate and embarrassingly cheap, and approximate is fine here: nothing\n// depends on finding the *best* free spot, only a good one.\n\n// Smallest positive time until a ball at (x, y) with velocity (vx, vy) would\n// touch any existing ball.\n//\n// The trick that makes this exact rather than a guess: gravity accelerates\n// every ball identically, so it cancels out of the RELATIVE motion of any two\n// balls. In the relative frame the motion is a straight line even though both\n// paths are curved, so the contact time is the root of a plain quadratic.\n//\n// Setting |p + v*t| = r1 + r2 and squaring gives\n// (v·v)t^2 + 2(p·v)t + (p·p - sum^2) = 0, which is the a, b, c below. The\n// smaller positive root is the moment of first contact; a negative discriminant\n// means the paths never come within touching distance at all.\nconst timeToFirstContact = (x, y, vx, vy, r) => {\n let soonest = Infinity;\n for (let i = 0; i < count; i++) {\n const px = xs[i] - x; // relative position\n const py = ys[i] - y;\n const rvx = vxs[i] - vx; // relative velocity\n const rvy = vys[i] - vy;\n const sum = rs[i] + r;\n\n const a = rvx * rvx + rvy * rvy;\n if (a < 1e-9) continue; // no relative motion: never converges\n const b = 2 * (px * rvx + py * rvy);\n const c = px * px + py * py - sum * sum;\n const disc = b * b - 4 * a * c;\n if (disc < 0) continue; // paths never touch\n\n const root = Math.sqrt(disc);\n const t1 = (-b - root) / (2 * a);\n const t2 = (-b + root) / (2 * a);\n const t = t1 > 0 ? t1 : t2 > 0 ? t2 : Infinity;\n if (t < soonest) soonest = t;\n }\n return soonest;\n};\n\n// Clearance at a candidate point: distance to the nearest surface, negative\n// if the point overlaps something.\n//\n// This function is the reason the endgame is playable. The original scanned\n// every ball for every candidate point — O(n) per sample, up to 64 samples\n// per spawn, and dozens of spawns per step near saturation. That is a cubic\n// term hiding inside an otherwise linear simulation, and it was the last real\n// bottleneck. Consulting only nearby cells makes a sample cost about the same\n// whether there are ten balls or ten thousand.\n//\n// Two shortcuts do the rest of the work:\n//\n// CAP. Clearance is capped just past the accept threshold. Beyond that the\n// exact value cannot change any decision — a spot that roomy wins outright\n// and ends the sweep — and capping is what bounds the search to a fixed\n// radius of cells instead of the whole disc.\n//\n// FLOOR. The caller passes the best clearance found so far. The moment this\n// candidate is known to lose, it is abandoned. Most candidates in a crowded\n// disc lose on their first or second neighbour.\nconst clearanceAt = (x, y, r, floor) => {\n const cap = spawnGap * 3 + 1;\n\n let clear = radius - r - Math.hypot(x - centerX, y - centerY); // wall\n if (clear > cap) clear = cap;\n if (clear <= floor) return clear;\n\n const cx = gridCol(x);\n const cy = gridRow(y);\n for (let ox = -querySpan; ox <= querySpan; ox++) {\n const gx = cx + ox;\n if (gx < 0 || gx >= gridW) continue;\n for (let oy = -querySpan; oy <= querySpan; oy++) {\n const gy = cy + oy;\n if (gy < 0 || gy >= gridH) continue;\n let j = heads[gy * gridW + gx];\n while (j !== -1) {\n const gap = Math.hypot(x - xs[j], y - ys[j]) - (r + rs[j]);\n if (gap < clear) {\n clear = gap;\n if (clear <= floor) return clear;\n }\n j = next[j];\n }\n }\n }\n return clear;\n};\n\nconst spawnBall = () => {\n const r = ballR;\n const maxRad = Math.max(0, radius - r - spawnGap);\n\n // --- 1. Where? -----------------------------------------------------\n //\n // Sample points uniformly over the disc and keep the roomiest. Note the\n // sqrt() on the radius: sampling radius uniformly would cluster points near\n // the centre, because a ring's area grows with its radius. Taking the\n // square root of a uniform number spreads them evenly across the area.\n //\n // Placement is best-effort, not a veto. An earlier version refused to spawn\n // when it could not find a clear spot, which was correct by the letter of\n // \"avoid immediate collisions\" but violated the later requirement that\n // every collision spawns. Now the roomiest spot found is used no matter how\n // cramped it is, and the overlap resolves itself over the next few steps.\n //\n // The reduced QUICK_TRIES budget deserves its own note. The obvious\n // optimization is to skip the sweep entirely once we know the disc is\n // packed — but `crowded` only resets when a sweep FINDS room, so skipping\n // the sweep would make the counter a one-way ratchet and break-out would\n // fire four spawns after the first unlucky sample, with no way to recover.\n // A token sweep is ~3% of the cost and keeps the signal honest.\n const tries = crowded === 0 ? PLACE_TRIES : QUICK_TRIES;\n let bestX = centerX;\n let bestY = centerY;\n let bestClear = -Infinity;\n\n for (let k = 0; k < tries; k++) {\n const angle = Math.random() * TAU;\n const dist = Math.sqrt(Math.random()) * maxRad;\n const x = centerX + Math.cos(angle) * dist;\n const y = centerY + Math.sin(angle) * dist;\n\n const clear = clearanceAt(x, y, r, bestClear);\n if (clear > bestClear) {\n bestClear = clear;\n bestX = x;\n bestY = y;\n }\n\n if (bestClear > spawnGap * 3) break; // comfortably clear\n if (k >= HOPELESS_AFTER && bestClear < 0) break; // packed; stop paying\n }\n\n // --- 2. Which way? -------------------------------------------------\n //\n // Compare headings and take the one that stays clear longest. Skipped\n // entirely when there is no clearance: every direction is an immediate hit\n // in a jam, so the answer is known in advance and DIR_TRIES full scans\n // would be pure waste at the worst possible moment.\n //\n // `jitter` has to be a separate constant from `bestDir`. A previous version\n // used bestDir as both the sweep origin and the running winner, so the\n // moment a better heading was found the remaining candidates were measured\n // from the new origin — the fan stopped being evenly spaced and started\n // walking around the circle.\n const jitter = Math.random() * TAU;\n let bestDir = jitter;\n if (bestClear >= 0) {\n let bestTime = -1;\n for (let m = 0; m < DIR_TRIES; m++) {\n const angle = jitter + (m / DIR_TRIES) * TAU;\n const t = timeToFirstContact(\n bestX, bestY,\n Math.cos(angle) * speed, Math.sin(angle) * speed,\n r,\n );\n if (t > bestTime) {\n bestTime = t;\n bestDir = angle;\n }\n }\n }\n\n addBall(bestX, bestY, bestDir);\n\n // --- 3. Is the disc full? ------------------------------------------\n //\n // Saturation is detected from the search itself rather than guessed from a\n // ball count. If several sweeps in a row cannot find a single point with\n // any clearance, there is genuinely nowhere left — and that conclusion\n // holds at any window size, any ball radius, without a magic number.\n //\n // The alternative, comparing count against an area-derived packing limit,\n // needs a hand-tuned packing fraction and gets it wrong whenever the pile\n // is unevenly distributed.\n crowded = bestClear < 0 ? crowded + 1 : 0;\n if (crowded >= CROWD_LIMIT) breakOut();\n};\n\n// ---------------------------------------------------------------------\n// Rendering\n// ---------------------------------------------------------------------\n//\n// Deliberately plain: clear, stroke the wall, fill a circle per ball. At a\n// few thousand balls this is a few thousand path operations per frame and is\n// probably now the most expensive single thing in the program — the physics\n// has been optimized several times, this has not been touched.\n//\n// The next step, if it ever matters, is to batch: group balls by colour and\n// build one path per colour, cutting the state changes by orders of\n// magnitude. Beyond that lies WebGL, drawing every ball as a point sprite in\n// a single call. Neither is worth it while the frame budget holds.\nconst draw = () => {\n ctx.clearRect(0, 0, canvas.width, canvas.height);\n\n ctx.beginPath();\n ctx.arc(centerX, centerY, radius, 0, TAU);\n ctx.strokeStyle = brokenOut ? \"#1c2438\" : \"#3d4a6b\"; // dim once inert\n ctx.lineWidth = 2;\n ctx.stroke();\n\n for (let i = 0; i < count; i++) {\n ctx.beginPath();\n ctx.arc(xs[i], ys[i], rs[i], 0, TAU);\n ctx.fillStyle = COLORS[hues[i]];\n ctx.fill();\n }\n\n countEl.textContent = count;\n};\n\n// ---------------------------------------------------------------------\n// The frame loop\n// ---------------------------------------------------------------------\n//\n// Physics runs on a FIXED timestep while rendering runs at whatever rate the\n// display offers. Stepping the physics by the real frame delta instead would\n// make behaviour depend on frame rate: collisions would be missed on a slow\n// frame, and results would differ between a 60Hz and a 144Hz monitor. So real\n// elapsed time goes into an accumulator, and fixed-size steps are drained\n// from it.\n//\n// MAX_STEPS is the guardrail on that loop, and it exists because of a\n// specific failure. If one step costs more real time than it simulates, the\n// accumulator grows faster than it drains: the frame takes longer, which\n// leaves more time to catch up next frame, which makes that frame longer\n// still. The classic spiral of death. Near saturation this turned a slow\n// frame into a full multi-second lock-up.\n//\n// Capping the steps per frame and discarding the backlog trades accuracy for\n// responsiveness: the simulation quietly runs in slow motion under extreme\n// load instead of freezing the tab. For this program that is obviously the\n// right trade. For a physics sim whose results must be reproducible, it would\n// not be.\n\nlet last = performance.now();\nlet acc = 0;\n\nconst frame = (now) => {\n // The clamp handles returning from a background tab, where `now - last`\n // can be minutes and would otherwise queue an unbounded amount of work.\n const dt = Math.min((now - last) / 1000, 0.2);\n last = now;\n acc += dt;\n\n let steps = 0;\n while (acc >= STEP && steps < MAX_STEPS) {\n step(STEP);\n acc -= STEP;\n steps++;\n }\n if (acc > STEP * MAX_STEPS) acc = 0; // gave up catching up; drop it\n\n draw();\n requestAnimationFrame(frame);\n};\n\n// ---------------------------------------------------------------------\n// Input\n// ---------------------------------------------------------------------\n\n// Click or tap inside the circle to add a ball. The pointer position is used\n// only to test that the click landed inside the wall — the ball itself goes\n// wherever the usual search says there is room, so a hand-placed ball is no\n// more likely to spawn in someone's lap than an automatic one.\n//\n// Clicks are ignored after break-out, because spawnBall also feeds the\n// crowding counter and can call breakOut(), which would re-kick every ball\n// outward on each click. Allowing it would mean separating the placement\n// logic from the saturation bookkeeping.\ncanvas.addEventListener(\"pointerdown\", ({ clientX, clientY }) => {\n if (brokenOut) return;\n const rect = canvas.getBoundingClientRect();\n const x = clientX - rect.left;\n const y = clientY - rect.top;\n if (Math.hypot(x - centerX, y - centerY) > radius) return;\n spawnBall();\n});\n\nwindow.addEventListener(\"resize\", fit);\nresetBtn.addEventListener(\"click\", reset);\ngravityBtn.addEventListener(\"click\", () => {\n gravityOn = !gravityOn;\n gravityBtn.textContent = `Gravity: ${gravityOn ? \"on\" : \"off\"}`;\n});\n\n// ---------------------------------------------------------------------\n// Energy, and why the burst is so violent\n// ---------------------------------------------------------------------\n//\n// Worth stating plainly, because it surprises people watching it: this\n// simulation has no dissipation at all. Bounces are perfectly elastic, there\n// is no drag and no restitution loss. Meanwhile three separate things ADD\n// energy:\n//\n// 1. Every spawned ball is created moving at full speed, out of nothing.\n// Thousands of spawns is thousands of injections.\n// 2. Overlap correction displaces balls for free, including upward against\n// gravity. Hundreds of times per step in a jam.\n// 3. Gravity does work on everything continuously and never gets it back.\n//\n// So by saturation the pile is far hotter than the initial two balls imply,\n// and removing the wall releases all of it at once. The outward kick in\n// breakOut() is a garnish on top of that.\n//\n// If you wanted a calmer escape, the honest fix is not a smaller kick — it is\n// giving pairCollide a restitution coefficient below 1, so collisions lose a\n// little energy the way real ones do.\n\nfit();\nreset();\nrequestAnimationFrame(frame);\n","// =====================================================================\n// Balls in a circle\n// =====================================================================\n//\n// Two balls bounce inside a circle. Every time two of them collide, a third\n// is spawned. When the disc is so full that there is nowhere left to put a\n// new ball, the wall switches off and everything bursts out of the view.\n//\n// The physics rules, stated once so the code below can be checked against\n// them:\n//\n// * Between impacts a ball moves under gravity alone — a parabola.\n// * A bounce off the wall changes direction but never speed.\n// * A ball-ball collision is perfectly elastic between equal masses.\n// * Nothing damps, so total energy only ever goes up (see \"Energy\" below).\n//\n// The interesting part of this file is not the physics, which is a page of\n// vector algebra, but everything around it: how thousands of balls are\n// stored, how collisions are found without comparing every pair, and how a\n// spawn point is chosen without scanning the whole population. Those three\n// problems drove nearly every design decision here, and the comments call\n// out what the earlier, slower versions of each one looked like.\n//\n// A note on where this file lives: it is served at /sim.js by main.tsx and\n// loaded as a module by index.html. Module scripts are deferred and get\n// their own scope, which is why there is no IIFE wrapper and no \"use strict\"\n// — both are automatic.\n\n// ---------------------------------------------------------------------\n// DOM handles\n// ---------------------------------------------------------------------\n\nconst canvas = document.getElementById(\"c\");\nconst ctx = canvas.getContext(\"2d\");\nconst countEl = document.getElementById(\"count\");\nconst gravityBtn = document.getElementById(\"gravity\");\nconst resetBtn = document.getElementById(\"reset\");\n\nconst TAU = Math.PI * 2; // one full turn; every angle here is in radians\n\n// ---------------------------------------------------------------------\n// Tuning constants\n// ---------------------------------------------------------------------\n//\n// Anything measured in pixels is described at a REFERENCE VIEW SIZE rather\n// than in absolute terms, and scaled to the actual view in fit(). The reason\n// is worth understanding, because it took a bug report to find.\n//\n// Originally the ball radius was a flat 5.5px at every window size. That\n// seems harmless, but the number of balls that fit in the disc before it\n// saturates goes as (disc area / ball area) = radius^2 / ballRadius^2. Fix\n// the ball size and that ratio grows with the square of the window. A large\n// monitor held twice as many balls at break-out as a small one, and since\n// the expensive searches cost more per ball AND there were more balls, the\n// endgame got dramatically slower on big screens.\n//\n// Tying ball size to the view fixes the saturation count everywhere. Once\n// lengths scale, velocities and accelerations have to scale with them or the\n// motion stops looking the same: if lengths scale by s and time is left\n// alone, then v = dx/dt scales by s, and a = dv/dt scales by s as well. All\n// linear. (An earlier claim in conversation that gravity should scale as s^2\n// was wrong — that would only be true if the time axis were also stretched.)\n\nconst REF_VIEW = 600; // view size the reference numbers describe\nconst REF_BALL_R = 5.5; // ball radius, px, at the reference size\nconst MIN_BALL_R = 3; // floor, so tiny windows stay visible\nconst SPAWN_GAP_RATIO = 7 / 5.5; // required space around a new ball, in radii\nconst CELL_RATIO = 2.5; // broad-phase cell size, in radii\nconst REF_SPEED = 175; // px/sec launch speed at the reference size\nconst REF_GRAVITY = 260; // px/sec^2 down: enough to arc, not to slam\nconst REF_MAX_SPEED = 1500; // clamp, so nothing can tunnel the wall\nconst REF_BURST = 240; // outward kick, px/sec, at break-out\n\n// Search budgets. PLACE_TRIES is how many candidate points a spawn considers.\n// QUICK_TRIES is the reduced budget used once we already believe the disc is\n// packed — see spawnBall for why it is reduced rather than skipped entirely.\n// HOPELESS_AFTER abandons a sweep that has found no room in its first several\n// dozen samples. DIR_TRIES is how many launch headings are compared.\nconst PLACE_TRIES = 400;\nconst QUICK_TRIES = 12;\nconst HOPELESS_AFTER = 64;\nconst DIR_TRIES = 32;\n\n// STEP is the fixed physics timestep. 240Hz is well above the display rate;\n// small steps keep fast balls from passing through walls or each other in a\n// single update. MAX_STEPS bounds how much catch-up one frame may attempt —\n// see the frame loop at the bottom for the failure mode it prevents.\nconst STEP = 1 / 240;\nconst MAX_STEPS = 6;\n\n// CROWD_LIMIT is how many consecutive \"nowhere to put it\" spawns count as\n// proof that the disc is full and it is time to break out.\nconst CROWD_LIMIT = 4;\n\n// Hue advances in fixed increments, so only 360 fill styles are ever needed.\n// Building them once means draw() never allocates a string and the canvas can\n// reuse its parsed style. The earlier version stored a per-ball color string,\n// which meant one string object per ball and a fresh parse on every fill.\nconst COLORS = Array.from({ length: 360 }, (unused, h) => `hsl(${h} 92% 62%)`);\n\n// ---------------------------------------------------------------------\n// Derived state\n// ---------------------------------------------------------------------\n//\n// Everything here is in pixels or pixels/second, so all of it is recomputed\n// against the current view size on every resize. They are `let` rather than\n// `const` for exactly that reason — the naming convention is deliberate:\n// SHOUTY_CASE means \"fixed forever\", lowercase means \"recomputed\".\n\nlet scale = 1;\nlet ballR = REF_BALL_R;\nlet spawnGap = REF_BALL_R * SPAWN_GAP_RATIO;\nlet cell = REF_BALL_R * CELL_RATIO;\nlet speed = REF_SPEED;\nlet gravity = REF_GRAVITY;\nlet maxSpeed = REF_MAX_SPEED;\nlet burst = REF_BURST;\n\nlet gravityOn = true;\nlet brokenOut = false;\nlet crowded = 0; // consecutive spawns that found no room\nlet hue = 200;\nlet centerX = 0;\nlet centerY = 0;\nlet radius = 0; // radius of the circular wall\nlet viewSize = 0; // the canvas is square, so one number covers both axes\n\n// ---------------------------------------------------------------------\n// Ball storage: struct of arrays\n// ---------------------------------------------------------------------\n//\n// The obvious representation is an array of objects:\n//\n// balls = [{ x, y, vx, vy, r, color }, ...]\n//\n// and that is what this started as. It reads beautifully and it is the wrong\n// shape once there are thousands of them. Each ball is a separate heap\n// object; the array holds pointers, so walking it chases references all over\n// memory, and every spawn allocates. At a few thousand balls updated 240\n// times a second, that is a lot of pointer chasing and a lot of garbage.\n//\n// A struct of arrays inverts it: one contiguous typed array per field, and an\n// integer index in place of an object reference. Iterating xs[] walks memory\n// in a straight line, which is what caches and JITs are built for, and\n// spawning writes into pre-allocated slots instead of allocating.\n//\n// The cost is ergonomic. There is no longer a \"ball\" you can pass around —\n// functions take indices and reach into the arrays, so `b.vx` becomes\n// `vxs[i]`. Everything is more verbose and slightly easier to get wrong. It\n// is a real trade, worth making here and not worth making for fifty balls.\n//\n// Float32 is plenty: about 7 significant digits, so a coordinate up to a few\n// thousand pixels is exact to well under a thousandth of a pixel. All the\n// arithmetic below still happens in doubles; only the stored result rounds.\n//\n// rs[] holds a per-ball radius even though every ball currently has the same\n// one. It costs one array and keeps the code honest if balls ever differ.\n\nlet capacity = 0; // allocated slots\nlet count = 0; // live balls; slots [0, count) are meaningful\nlet xs = null;\nlet ys = null;\nlet vxs = null;\nlet vys = null;\nlet rs = null;\nlet hues = null;\nlet next = null; // broad-phase chain; see the grid section\n\n// Grow by doubling rather than by one. Doubling makes the total copying work\n// across a run linear in the final size — the array reallocates a handful of\n// times over thousands of spawns, instead of once per spawn.\nconst ensureCapacity = (needed) => {\n if (needed <= capacity) return;\n let size = capacity || 256;\n while (size < needed) size *= 2;\n\n const grown = (src) => {\n const out = new Float32Array(size);\n if (src) out.set(src);\n return out;\n };\n xs = grown(xs);\n ys = grown(ys);\n vxs = grown(vxs);\n vys = grown(vys);\n rs = grown(rs);\n\n const nextHues = new Uint16Array(size);\n if (hues) nextHues.set(hues);\n hues = nextHues;\n\n // `next` must be copied too, even though it is rebuilt every step. During a\n // burst of spawns the grid is live and its chains run through this array;\n // growing without copying silently corrupted them. That bug was invisible\n // until the exact moment a spawn burst crossed a capacity boundary.\n const nextChain = new Int32Array(size);\n if (next) nextChain.set(next);\n next = nextChain;\n\n capacity = size;\n};\n\nconst addBall = (x, y, angle) => {\n ensureCapacity(count + 1);\n hue = (hue + 71) % 360; // 71 is coprime with 360, so hues spread out\n xs[count] = x;\n ys[count] = y;\n vxs[count] = Math.cos(angle) * speed;\n vys[count] = Math.sin(angle) * speed;\n rs[count] = ballR;\n hues[count] = hue;\n count++;\n gridInsert(count - 1); // keep the broad phase usable between rebuilds\n};\n\n// Removal is a swap with the last live slot, then a decrement. Order carries\n// no meaning here — nothing indexes a ball by position — so there is no\n// reason to pay for the shift that splice() would do. O(1) and no allocation.\n//\n// The version before this rebuilt the entire array with filter() on every\n// frame of the escape phase, which allocated a fresh array per frame at\n// precisely the moment the simulation was most loaded.\nconst removeAt = (i) => {\n count--;\n if (i === count) return;\n xs[i] = xs[count];\n ys[i] = ys[count];\n vxs[i] = vxs[count];\n vys[i] = vys[count];\n rs[i] = rs[count];\n hues[i] = hues[count];\n};\n\n// ---------------------------------------------------------------------\n// Layout\n// ---------------------------------------------------------------------\n\nconst fit = () => {\n const size = Math.max(240, Math.min(window.innerWidth - 16, window.innerHeight - 90));\n\n // Canvas has two sizes: the CSS box it occupies and its backing-store\n // resolution. Setting the backing store to size * devicePixelRatio and\n // scaling the context by the same factor gives crisp output on a retina\n // display while letting all the drawing code work in CSS pixels.\n const dpr = window.devicePixelRatio ?? 1;\n canvas.style.width = `${size}px`;\n canvas.style.height = `${size}px`;\n canvas.width = Math.round(size * dpr);\n canvas.height = Math.round(size * dpr);\n // The six arguments are a 2D affine matrix in column-major order —\n // (a, b, c, d, e, f) meaning\n //\n // | a c e | | dpr 0 0 |\n // | b d f | = | 0 dpr 0 |\n //\n // where a and d scale x and y, b and c skew, and e and f translate. So this\n // is \"scale both axes by dpr, no skew, no translation\": a drawing call at\n // (100, 100) lands on backing-store pixel (200, 200) at dpr 2.\n //\n // setTransform rather than scale(dpr, dpr) because setTransform REPLACES\n // the matrix while scale MULTIPLIES into it. fit() runs on every resize, so\n // scale() would compound — two resizes at dpr 2 would leave a 4x transform.\n // Replacing makes the function idempotent, which is what a layout routine\n // that can run any number of times needs to be.\n ctx.setTransform(dpr, 0, 0, dpr, 0, 0);\n\n viewSize = size;\n centerX = size / 2;\n centerY = size / 2;\n radius = size / 2 - 6;\n\n // Rescale the simulation. See the tuning-constants section for why this is\n // a single linear factor applied to lengths, velocities and accelerations\n // alike.\n const nextScale = size / REF_VIEW;\n const ratio = nextScale / scale;\n scale = nextScale;\n\n ballR = Math.max(MIN_BALL_R, REF_BALL_R * scale);\n spawnGap = ballR * SPAWN_GAP_RATIO;\n cell = ballR * CELL_RATIO;\n speed = REF_SPEED * scale;\n gravity = REF_GRAVITY * scale;\n maxSpeed = REF_MAX_SPEED * scale;\n burst = REF_BURST * scale;\n\n resizeGrid();\n\n // How far the clearance search has to look: far enough to see any ball that\n // could sit within the capped clearance, plus a cell of slack.\n querySpan = Math.ceil((spawnGap * 3 + 2 * ballR) / cell) + 1;\n\n // Balls already in flight keep their trajectories under the new scale.\n // Without this, a resize mid-run would leave everything moving at the wrong\n // speed for its new size.\n for (let i = 0; i < count; i++) {\n rs[i] = ballR;\n vxs[i] *= ratio;\n vys[i] *= ratio;\n }\n};\n\nconst reset = () => {\n brokenOut = false;\n crowded = 0;\n count = 0; // no deallocation needed: the slots are simply reused\n addBall(centerX - radius * 0.45, centerY - radius * 0.1, 0.35);\n addBall(centerX + radius * 0.45, centerY + radius * 0.1, Math.PI * 1.18);\n};\n\n// ---------------------------------------------------------------------\n// Physics: the wall\n// ---------------------------------------------------------------------\n//\n// A circular wall is the easiest possible collision geometry, because the\n// surface normal at the point of contact is just the radial direction. There\n// is no edge to identify and no per-wall normal to look up, unlike a polygon.\n//\n// The bounce is the standard reflection, v -= 2(v·n)n, and it is worth\n// unpacking because it carries the \"speed never changes\" guarantee:\n//\n// * n is the outward unit normal. Dividing (dx, dy) by its own length\n// gives a vector of length 1 pointing the same way: the length of\n// (dx/d, dy/d) is sqrt((dx^2 + dy^2)/d^2) = sqrt(d^2/d^2) = 1.\n// * v·n is the dot product. Because n has unit length, it equals\n// |v|cos(theta) — the signed amount of the velocity pointing along the\n// normal. Positive means moving outward, into the wall.\n// * Subtracting (v·n)n once would cancel the outward component, leaving\n// the ball sliding along the wall. Subtracting it twice flips that\n// component inward and leaves the tangential part untouched.\n//\n// Only one of two perpendicular components changes sign, so the magnitude is\n// unchanged — the hypotenuse of a right triangle does not care about the sign\n// of a leg. Speed preservation falls out of the geometry rather than being\n// enforced by a separate correction.\nconst wallBounce = (i) => {\n const dx = xs[i] - centerX;\n const dy = ys[i] - centerY;\n const d = Math.hypot(dx, dy);\n const lim = radius - rs[i];\n\n // Nothing to do unless the ball is poking through the wall. The d === 0\n // guard is for a ball exactly at the centre, where there is no meaningful\n // direction and dividing by d would produce NaN.\n if (d <= lim || d === 0) return;\n\n const nx = dx / d;\n const ny = dy / d;\n\n // Position correction: put the ball back on the boundary along the same\n // radial line. Without this it would still be outside next step, drifting\n // further out each time (the reflection below only fires on approach), and\n // would eventually escape. The overshoot is at most one step of travel —\n // sub-pixel at 240Hz — so the snap is invisible.\n xs[i] = centerX + nx * lim;\n ys[i] = centerY + ny * lim;\n\n const vn = vxs[i] * nx + vys[i] * ny;\n\n // The vn > 0 guard matters more than it looks. A ball can be outside the\n // boundary while already heading back inward — usually because another ball\n // shoved it out. Reflecting then would flip an inward velocity to outward\n // and fire it straight through the wall.\n if (vn > 0) {\n vxs[i] -= 2 * vn * nx;\n vys[i] -= 2 * vn * ny;\n }\n};\n\n// After break-out the circle is inert and balls leave the view. With gravity\n// on they need something to land on, so the bottom edge becomes a floor.\n// Same reflection as above, but the normal is a constant (0, -1), which\n// collapses the whole calculation to flipping the sign of vy.\nconst floorBounce = (i) => {\n const lim = viewSize - rs[i];\n if (ys[i] < lim) return;\n ys[i] = lim;\n if (vys[i] > 0) vys[i] = -vys[i];\n};\n\n// The disc is packed: switch the wall off and kick everything outward.\n//\n// The kick is cosmetic — the pile is already under enormous pressure and\n// would spread on its own — but without it the escape oozes rather than\n// bursts, which reads as a bug rather than an event.\nconst breakOut = () => {\n brokenOut = true;\n for (let i = 0; i < count; i++) {\n let dx = xs[i] - centerX;\n let dy = ys[i] - centerY;\n let d = Math.hypot(dx, dy);\n if (d < 1e-6) { // a ball exactly at the centre has no outward direction\n const angle = Math.random() * TAU;\n dx = Math.cos(angle);\n dy = Math.sin(angle);\n d = 1;\n }\n vxs[i] += (dx / d) * burst;\n vys[i] += (dy / d) * burst;\n }\n};\n\n// ---------------------------------------------------------------------\n// Physics: ball against ball\n// ---------------------------------------------------------------------\n//\n// Elastic collision between equal masses has a famously tidy result: the two\n// bodies swap the components of their velocities along the line of centres,\n// and their tangential components are untouched. Solving conservation of\n// momentum and kinetic energy simultaneously for equal masses gives exactly\n// that, which is why there is no mass term anywhere below.\n//\n// Note the structure is the same as the wall bounce — decompose along a\n// normal, act only on the normal component, leave the tangent alone. The\n// difference is that here the normal points from one ball to the other rather\n// than from a wall, and the component is exchanged rather than reversed.\n//\n// This is a discrete-time approximation. A \"proper\" continuous-collision\n// solver would compute the exact time of impact within the step, rewind both\n// balls to it, resolve, and replay the remainder. That is the right approach\n// for a few fast objects; it is the wrong approach for a jammed pile of\n// thousands, where impacts are near-simultaneous and the exact ordering does\n// not survive the next step anyway. A small fixed timestep plus overlap\n// correction is cheaper and stable under crowding.\nconst pairCollide = (i, j) => {\n let dx = xs[j] - xs[i];\n let dy = ys[j] - ys[i];\n let d = Math.hypot(dx, dy);\n const min = rs[i] + rs[j];\n if (d >= min) return false; // not touching\n\n if (d === 0) { // exactly coincident: pick an arbitrary axis to separate on\n dx = 1;\n dy = 0;\n d = 1e-6;\n }\n\n const nx = dx / d;\n const ny = dy / d;\n\n // Positional correction: push each ball half the overlap apart, plus a hair\n // extra so they are not left exactly touching. Without this, overlapping\n // pairs would re-trigger every step and the pile would sink into itself.\n //\n // This is also where the simulation quietly gains energy. Separating two\n // balls does work on them for free, and in a jam there are hundreds of\n // these corrections per step. It is why the pile is so hot by the time it\n // bursts. The 0.01 term is the tunable part of that.\n const push = (min - d) / 2 + 0.01;\n xs[i] -= nx * push;\n ys[i] -= ny * push;\n xs[j] += nx * push;\n ys[j] += ny * push;\n\n const an = vxs[i] * nx + vys[i] * ny;\n const bn = vxs[j] * nx + vys[j] * ny;\n\n // Overlapping but already moving apart. This happens constantly in a\n // crowded pile — a pair gets separated by the correction above, or shoved\n // apart by a third ball. Treating it as an impact would inject energy and,\n // worse, would count as a collision and spawn another ball, so a stuck pair\n // would breed forever.\n if (an - bn <= 0) return false;\n\n vxs[i] += (bn - an) * nx;\n vys[i] += (bn - an) * ny;\n vxs[j] += (an - bn) * nx;\n vys[j] += (an - bn) * ny;\n return true;\n};\n\n// ---------------------------------------------------------------------\n// Broad phase: finding candidate pairs\n// ---------------------------------------------------------------------\n//\n// The naive way to find collisions is to test every pair:\n//\n// for (i) for (j > i) pairCollide(i, j)\n//\n// That is O(n^2), and this simulation is a machine for producing large n. At\n// 2000 balls it is two million tests per step, 240 steps a second — utterly\n// impossible. This was the original implementation and it was the single\n// biggest source of the stall before break-out.\n//\n// The fix is a uniform grid. Balls are bucketed by position into square\n// cells, and each ball only tests its own cell and the eight around it. If\n// cells are at least as wide as the largest possible contact distance, a 3x3\n// neighbourhood provably cannot miss a touching pair. Cost drops to roughly\n// O(n), because the number of balls near any given ball is bounded by\n// geometry rather than by the population.\n//\n// Two implementation details are worth more than they look:\n//\n// STORAGE. The first version was a Map from a hashed cell key to an Array of\n// indices, rebuilt each step. That allocates one array per occupied cell per\n// step. It is now a flat Int32Array of cell heads, with next[] chaining the\n// rest — a linked list threaded through typed arrays. Rebuilding is a fill()\n// plus one write per ball, and allocates nothing at all.\n//\n// INDEXING VS HASHING. Dropping the Map matters because clearanceAt() below\n// does roughly 80 cell lookups per candidate point, and there can be dozens\n// of candidates per spawn and dozens of spawns per step. Array indexing is a\n// couple of nanoseconds; hashing is tens. That difference alone would have\n// eaten the entire benefit of using the grid for placement.\n//\n// Because cell size scales with ball radius, and ball radius scales with the\n// view, the total cell count is roughly constant (~2000) at any window size.\n// The fill() per rebuild is therefore trivially cheap and does not grow.\n\nconst GRID_PAD = 4; // cells of margin, for balls that have left the view\nlet gridW = 0;\nlet gridH = 0;\nlet heads = null; // heads[c] = index of first ball in cell c, or -1\nlet querySpan = 3; // cells the clearance search reaches; set in fit()\n\nconst resizeGrid = () => {\n gridW = Math.ceil(viewSize / cell) + GRID_PAD * 2;\n gridH = gridW; // the canvas is square\n heads = new Int32Array(gridW * gridH);\n heads.fill(-1);\n};\n\n// Column and row for a position, clamped into the grid. Escaped balls get\n// folded into the edge cells rather than being dropped. That costs a few\n// redundant pair tests out beyond the view and never misses a real one:\n// two neighbouring balls outside the grid clamp to the same or adjacent\n// cells, so they still find each other.\nconst gridCol = (x) => {\n const c = Math.floor(x / cell) + GRID_PAD;\n return c < 0 ? 0 : c >= gridW ? gridW - 1 : c;\n};\n\nconst gridRow = (y) => {\n const c = Math.floor(y / cell) + GRID_PAD;\n return c < 0 ? 0 : c >= gridH ? gridH - 1 : c;\n};\n\n// Push one ball onto the front of its cell's chain. Called from addBall so a\n// burst of spawns stays consistent without rebuilding the whole grid per ball.\nconst gridInsert = (i) => {\n if (!heads) return; // before the first fit()\n const c = gridRow(ys[i]) * gridW + gridCol(xs[i]);\n next[i] = heads[c];\n heads[c] = i;\n};\n\nconst buildGrid = () => {\n heads.fill(-1);\n for (let i = 0; i < count; i++) {\n const c = gridRow(ys[i]) * gridW + gridCol(xs[i]);\n next[i] = heads[c];\n heads[c] = i;\n }\n};\n\n// Returns the number of genuine impacts, which is what drives spawning.\n//\n// The j > i test is how each pair gets resolved exactly once. Both balls of a\n// pair see each other in their 3x3 neighbourhoods, so without it every\n// collision would be applied twice — and would count as two impacts, and\n// spawn two balls.\nconst collideAll = () => {\n buildGrid();\n\n let impacts = 0;\n for (let i = 0; i < count; i++) {\n const cx = gridCol(xs[i]);\n const cy = gridRow(ys[i]);\n for (let ox = -1; ox <= 1; ox++) {\n const gx = cx + ox;\n if (gx < 0 || gx >= gridW) continue;\n for (let oy = -1; oy <= 1; oy++) {\n const gy = cy + oy;\n if (gy < 0 || gy >= gridH) continue;\n let j = heads[gy * gridW + gx];\n while (j !== -1) {\n if (j > i && pairCollide(i, j)) impacts++;\n j = next[j];\n }\n }\n }\n }\n return impacts;\n};\n\n// ---------------------------------------------------------------------\n// The step\n// ---------------------------------------------------------------------\n\nconst isOffScreen = (i) =>\n xs[i] + rs[i] < 0 || xs[i] - rs[i] > viewSize ||\n ys[i] + rs[i] < 0 || ys[i] - rs[i] > viewSize;\n\n// Order of operations within a step: integrate, then resolve walls, then\n// resolve ball-ball, then spawn. Walls before balls means a ball shoved\n// through the wall by a neighbour is corrected before anything else looks at\n// it; spawning last means new balls do not get integrated on the step they\n// were born.\nconst step = (dt) => {\n for (let i = 0; i < count; i++) {\n // Semi-implicit (symplectic) Euler: update velocity first, then use the\n // NEW velocity to update position. The one-line difference from plain\n // Euler — which would move using the old velocity — buys much better\n // energy behaviour over long runs, and it is why a bouncing ball here\n // does not slowly climb higher and higher on its own.\n if (gravityOn) vys[i] += gravity * dt;\n\n // Speed clamp. Purely defensive: if numerical drift ever produced a\n // ridiculous velocity, a ball could cross the wall entirely within one\n // step and escape. In normal operation this never fires.\n const mag = Math.hypot(vxs[i], vys[i]);\n if (mag > maxSpeed) {\n vxs[i] *= maxSpeed / mag;\n vys[i] *= maxSpeed / mag;\n }\n\n xs[i] += vxs[i] * dt;\n ys[i] += vys[i] * dt;\n }\n\n for (let i = 0; i < count; i++) {\n if (!brokenOut) wallBounce(i);\n else if (gravityOn) floorBounce(i);\n }\n\n const impacts = collideAll();\n\n if (!brokenOut) {\n // Collision resolution nudged positions, so rebuild before the placement\n // searches read the grid. New balls insert themselves as they arrive.\n if (impacts > 0) buildGrid();\n for (let i = 0; i < impacts; i++) spawnBall();\n } else {\n // Escaped balls stop breeding, and are dropped once fully out of view.\n // Walking backwards is what makes swap-removal safe here: the ball\n // swapped into slot i comes from a higher index, which this loop has\n // already visited and judged.\n for (let i = count - 1; i >= 0; i--) {\n if (isOffScreen(i)) removeAt(i);\n }\n }\n};\n\n// ---------------------------------------------------------------------\n// Spawning\n// ---------------------------------------------------------------------\n//\n// Every collision produces a ball, and the original requirement was that a\n// new ball must not be placed where it would immediately collide. That turns\n// out to be two separate questions: WHERE to put it, and WHICH WAY to send\n// it. A spot can be perfectly clear and still be a bad start if the ball is\n// launched straight at a neighbour.\n//\n// The approach here is rejection sampling with a best-of-N fallback: throw\n// darts at the disc, score each by how much empty space surrounds it, and\n// keep the best. This is not the only option. A maintained free-space\n// structure (a quadtree of empty regions, say) could answer \"where is there\n// room\" exactly, but it has to be updated as thousands of balls move every\n// step, which costs far more than the sampling it would replace. Sampling is\n// approximate and embarrassingly cheap, and approximate is fine here: nothing\n// depends on finding the *best* free spot, only a good one.\n\n// Smallest positive time until a ball at (x, y) with velocity (vx, vy) would\n// touch any existing ball.\n//\n// The trick that makes this exact rather than a guess: gravity accelerates\n// every ball identically, so it cancels out of the RELATIVE motion of any two\n// balls. In the relative frame the motion is a straight line even though both\n// paths are curved, so the contact time is the root of a plain quadratic.\n//\n// Setting |p + v*t| = r1 + r2 and squaring gives\n// (v·v)t^2 + 2(p·v)t + (p·p - sum^2) = 0, which is the a, b, c below. The\n// smaller positive root is the moment of first contact; a negative discriminant\n// means the paths never come within touching distance at all.\nconst timeToFirstContact = (x, y, vx, vy, r) => {\n let soonest = Infinity;\n for (let i = 0; i < count; i++) {\n const px = xs[i] - x; // relative position\n const py = ys[i] - y;\n const rvx = vxs[i] - vx; // relative velocity\n const rvy = vys[i] - vy;\n const sum = rs[i] + r;\n\n const a = rvx * rvx + rvy * rvy;\n if (a < 1e-9) continue; // no relative motion: never converges\n const b = 2 * (px * rvx + py * rvy);\n const c = px * px + py * py - sum * sum;\n const disc = b * b - 4 * a * c;\n if (disc < 0) continue; // paths never touch\n\n const root = Math.sqrt(disc);\n const t1 = (-b - root) / (2 * a);\n const t2 = (-b + root) / (2 * a);\n const t = t1 > 0 ? t1 : t2 > 0 ? t2 : Infinity;\n if (t < soonest) soonest = t;\n }\n return soonest;\n};\n\n// Clearance at a candidate point: distance to the nearest surface, negative\n// if the point overlaps something.\n//\n// This function is the reason the endgame is playable. The original scanned\n// every ball for every candidate point — O(n) per sample, up to 64 samples\n// per spawn, and dozens of spawns per step near saturation. That is a cubic\n// term hiding inside an otherwise linear simulation, and it was the last real\n// bottleneck. Consulting only nearby cells makes a sample cost about the same\n// whether there are ten balls or ten thousand.\n//\n// Two shortcuts do the rest of the work:\n//\n// CAP. Clearance is capped just past the accept threshold. Beyond that the\n// exact value cannot change any decision — a spot that roomy wins outright\n// and ends the sweep — and capping is what bounds the search to a fixed\n// radius of cells instead of the whole disc.\n//\n// FLOOR. The caller passes the best clearance found so far. The moment this\n// candidate is known to lose, it is abandoned. Most candidates in a crowded\n// disc lose on their first or second neighbour.\nconst clearanceAt = (x, y, r, floor) => {\n const cap = spawnGap * 3 + 1;\n\n let clear = radius - r - Math.hypot(x - centerX, y - centerY); // wall\n if (clear > cap) clear = cap;\n if (clear <= floor) return clear;\n\n const cx = gridCol(x);\n const cy = gridRow(y);\n for (let ox = -querySpan; ox <= querySpan; ox++) {\n const gx = cx + ox;\n if (gx < 0 || gx >= gridW) continue;\n for (let oy = -querySpan; oy <= querySpan; oy++) {\n const gy = cy + oy;\n if (gy < 0 || gy >= gridH) continue;\n let j = heads[gy * gridW + gx];\n while (j !== -1) {\n const gap = Math.hypot(x - xs[j], y - ys[j]) - (r + rs[j]);\n if (gap < clear) {\n clear = gap;\n if (clear <= floor) return clear;\n }\n j = next[j];\n }\n }\n }\n return clear;\n};\n\nconst spawnBall = () => {\n const r = ballR;\n const maxRad = Math.max(0, radius - r - spawnGap);\n\n // --- 1. Where? -----------------------------------------------------\n //\n // Sample points uniformly over the disc and keep the roomiest. Note the\n // sqrt() on the radius: sampling radius uniformly would cluster points near\n // the centre, because a ring's area grows with its radius. Taking the\n // square root of a uniform number spreads them evenly across the area.\n //\n // Placement is best-effort, not a veto. An earlier version refused to spawn\n // when it could not find a clear spot, which was correct by the letter of\n // \"avoid immediate collisions\" but violated the later requirement that\n // every collision spawns. Now the roomiest spot found is used no matter how\n // cramped it is, and the overlap resolves itself over the next few steps.\n //\n // The reduced QUICK_TRIES budget deserves its own note. The obvious\n // optimization is to skip the sweep entirely once we know the disc is\n // packed — but `crowded` only resets when a sweep FINDS room, so skipping\n // the sweep would make the counter a one-way ratchet and break-out would\n // fire four spawns after the first unlucky sample, with no way to recover.\n // A token sweep is ~3% of the cost and keeps the signal honest.\n const tries = crowded === 0 ? PLACE_TRIES : QUICK_TRIES;\n let bestX = centerX;\n let bestY = centerY;\n let bestClear = -Infinity;\n\n for (let k = 0; k < tries; k++) {\n const angle = Math.random() * TAU;\n const dist = Math.sqrt(Math.random()) * maxRad;\n const x = centerX + Math.cos(angle) * dist;\n const y = centerY + Math.sin(angle) * dist;\n\n const clear = clearanceAt(x, y, r, bestClear);\n if (clear > bestClear) {\n bestClear = clear;\n bestX = x;\n bestY = y;\n }\n\n if (bestClear > spawnGap * 3) break; // comfortably clear\n if (k >= HOPELESS_AFTER && bestClear < 0) break; // packed; stop paying\n }\n\n // --- 2. Which way? -------------------------------------------------\n //\n // Compare headings and take the one that stays clear longest. Skipped\n // entirely when there is no clearance: every direction is an immediate hit\n // in a jam, so the answer is known in advance and DIR_TRIES full scans\n // would be pure waste at the worst possible moment.\n //\n // `jitter` has to be a separate constant from `bestDir`. A previous version\n // used bestDir as both the sweep origin and the running winner, so the\n // moment a better heading was found the remaining candidates were measured\n // from the new origin — the fan stopped being evenly spaced and started\n // walking around the circle.\n const jitter = Math.random() * TAU;\n let bestDir = jitter;\n if (bestClear >= 0) {\n let bestTime = -1;\n for (let m = 0; m < DIR_TRIES; m++) {\n const angle = jitter + (m / DIR_TRIES) * TAU;\n const t = timeToFirstContact(\n bestX, bestY,\n Math.cos(angle) * speed, Math.sin(angle) * speed,\n r,\n );\n if (t > bestTime) {\n bestTime = t;\n bestDir = angle;\n }\n }\n }\n\n addBall(bestX, bestY, bestDir);\n\n // --- 3. Is the disc full? ------------------------------------------\n //\n // Saturation is detected from the search itself rather than guessed from a\n // ball count. If several sweeps in a row cannot find a single point with\n // any clearance, there is genuinely nowhere left — and that conclusion\n // holds at any window size, any ball radius, without a magic number.\n //\n // The alternative, comparing count against an area-derived packing limit,\n // needs a hand-tuned packing fraction and gets it wrong whenever the pile\n // is unevenly distributed.\n crowded = bestClear < 0 ? crowded + 1 : 0;\n if (crowded >= CROWD_LIMIT) breakOut();\n};\n\n// ---------------------------------------------------------------------\n// Rendering\n// ---------------------------------------------------------------------\n//\n// Deliberately plain: clear, stroke the wall, fill a circle per ball. At a\n// few thousand balls this is a few thousand path operations per frame and is\n// probably now the most expensive single thing in the program — the physics\n// has been optimized several times, this has not been touched.\n//\n// The next step, if it ever matters, is to batch: group balls by colour and\n// build one path per colour, cutting the state changes by orders of\n// magnitude. Beyond that lies WebGL, drawing every ball as a point sprite in\n// a single call. Neither is worth it while the frame budget holds.\nconst draw = () => {\n ctx.clearRect(0, 0, canvas.width, canvas.height);\n\n ctx.beginPath();\n ctx.arc(centerX, centerY, radius, 0, TAU);\n ctx.strokeStyle = brokenOut ? \"#1c2438\" : \"#3d4a6b\"; // dim once inert\n ctx.lineWidth = 2;\n ctx.stroke();\n\n for (let i = 0; i < count; i++) {\n ctx.beginPath();\n ctx.arc(xs[i], ys[i], rs[i], 0, TAU);\n ctx.fillStyle = COLORS[hues[i]];\n ctx.fill();\n }\n\n countEl.textContent = count;\n};\n\n// ---------------------------------------------------------------------\n// The frame loop\n// ---------------------------------------------------------------------\n//\n// Physics runs on a FIXED timestep while rendering runs at whatever rate the\n// display offers. Stepping the physics by the real frame delta instead would\n// make behaviour depend on frame rate: collisions would be missed on a slow\n// frame, and results would differ between a 60Hz and a 144Hz monitor. So real\n// elapsed time goes into an accumulator, and fixed-size steps are drained\n// from it.\n//\n// MAX_STEPS is the guardrail on that loop, and it exists because of a\n// specific failure. If one step costs more real time than it simulates, the\n// accumulator grows faster than it drains: the frame takes longer, which\n// leaves more time to catch up next frame, which makes that frame longer\n// still. The classic spiral of death. Near saturation this turned a slow\n// frame into a full multi-second lock-up.\n//\n// Capping the steps per frame and discarding the backlog trades accuracy for\n// responsiveness: the simulation quietly runs in slow motion under extreme\n// load instead of freezing the tab. For this program that is obviously the\n// right trade. For a physics sim whose results must be reproducible, it would\n// not be.\n\nlet last = performance.now();\nlet acc = 0;\n\nconst frame = (now) => {\n // The clamp handles returning from a background tab, where `now - last`\n // can be minutes and would otherwise queue an unbounded amount of work.\n const dt = Math.min((now - last) / 1000, 0.2);\n last = now;\n acc += dt;\n\n let steps = 0;\n while (acc >= STEP && steps < MAX_STEPS) {\n step(STEP);\n acc -= STEP;\n steps++;\n }\n if (acc > STEP * MAX_STEPS) acc = 0; // gave up catching up; drop it\n\n draw();\n requestAnimationFrame(frame);\n};\n\n// ---------------------------------------------------------------------\n// Input\n// ---------------------------------------------------------------------\n\n// Click or tap inside the circle to add a ball. The pointer position is used\n// only to test that the click landed inside the wall — the ball itself goes\n// wherever the usual search says there is room, so a hand-placed ball is no\n// more likely to spawn in someone's lap than an automatic one.\n//\n// Clicks are ignored after break-out, because spawnBall also feeds the\n// crowding counter and can call breakOut(), which would re-kick every ball\n// outward on each click. Allowing it would mean separating the placement\n// logic from the saturation bookkeeping.\ncanvas.addEventListener(\"pointerdown\", ({ clientX, clientY }) => {\n if (brokenOut) return;\n const rect = canvas.getBoundingClientRect();\n const x = clientX - rect.left;\n const y = clientY - rect.top;\n if (Math.hypot(x - centerX, y - centerY) > radius) return;\n spawnBall();\n});\n\nwindow.addEventListener(\"resize\", fit);\nresetBtn.addEventListener(\"click\", reset);\ngravityBtn.addEventListener(\"click\", () => {\n gravityOn = !gravityOn;\n gravityBtn.textContent = `Gravity: ${gravityOn ? \"on\" : \"off\"}`;\n});\n\n// ---------------------------------------------------------------------\n// Energy, and why the burst is so violent\n// ---------------------------------------------------------------------\n//\n// Worth stating plainly, because it surprises people watching it: this\n// simulation has no dissipation at all. Bounces are perfectly elastic, there\n// is no drag and no restitution loss. Meanwhile three separate things ADD\n// energy:\n//\n// 1. Every spawned ball is created moving at full speed, out of nothing.\n// Thousands of spawns is thousands of injections.\n// 2. Overlap correction displaces balls for free, including upward against\n// gravity. Hundreds of times per step in a jam.\n// 3. Gravity does work on everything continuously and never gets it back.\n//\n// So by saturation the pile is far hotter than the initial two balls imply,\n// and removing the wall releases all of it at once. The outward kick in\n// breakOut() is a garnish on top of that.\n//\n// If you wanted a calmer escape, the honest fix is not a smaller kick — it is\n// giving pairCollide a restitution coefficient below 1, so collisions lose a\n// little energy the way real ones do.\n\nfit();\nreset();\nrequestAnimationFrame(frame);\n","createdAt",["D",1788675048780],"branchVersion","branchId","829c7d11-4752-4dc9-b231-6228a44ae8c9","id","67eb7b8a-f123-4693-b128-99f4d21574cc","bouncing-balls-circle",["D",1788569603047],"deletedAt","legacyEnvVars","privacy","public","httpPrivacy","description","2 balls bouncing in a circle; collisions spawn new balls","imageUrl","7e2a7670-3af7-4da2-b7ff-bc616c08969d","pinnedFileId","32050158-a8c4-11f1-9a2d-1607ee4eb77e","pinPreview",true,"pinMigrated","screenshotVersion","likeCount",0,"orgId","efbed71c-69f2-45a6-9aeb-25d2155b8aad","tursoName","tursoHostname","tursoMeasuredAt","pinned","userPerm","r","valPerm","blobPerm","rw","emailPerm","sqlitePerm","projectPerm","telemetryPerm","user",{"_97":96,"_104":100},"org",{"_97":96,"_98":-5,"_99":100,"_18":55,"_101":102,"_103":25},"branch",{"_13":86,"_32":87,"_43":42,"_88":44,"_89":-5,"_90":-5,"_91":-5,"_92":-5,"_93":-5,"_94":45,"_95":96},"isOwned",67,"main","projectId","forkedBranchId","forkedBranchVersion","forkedProjectPrivacy","forkedProjectId","forkedProjectOrgId","projectName","userHandle","swanchaos","handle","displayName","avatar","https://img.clerk.com/eyJ0eXBlIjoiZGVmYXVsdCIsImlpZCI6Imluc18yTm10cGhQUklwU0tqZHNiOHNnNGd2ZjJURFUiLCJyaWQiOiJ1c2VyXzJodmROZzhvZmNEMjR0cHpCeVVFeDk5UVBpVSJ9","tier","free","canRestrictVals","profileImageUrl","branchName","","adoptOrgId",{"_43":44,"_32":45,"_38":176,"_47":-5,"_48":25,"_49":50,"_51":50,"_52":53,"_54":-5,"_18":55,"_56":57,"_58":59,"_60":-5,"_61":-5,"_62":63,"_64":65,"_66":-5,"_67":-5,"_68":-5,"_69":-5,"_70":71,"_72":71,"_73":74,"_75":74,"_76":74,"_77":71,"_78":71,"_79":177,"_81":178,"_83":179,"_85":25},"tree",[163,164,165],"files",[163,164,165],"counts",{"_152":63,"_153":154,"_155":63,"_156":157,"_158":159},"contents",[127,128,129],"upstreamProject","upstreamBranch","emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{},{"_43":145,"_32":146,"_30":147,"_131":-5,"_41":42,"_40":148,"_132":59,"_38":149,"_13":63,"_33":20,"_35":150,"_24":25,"_135":-5,"_27":151},{"_43":137,"_32":138,"_30":57,"_131":-5,"_41":42,"_40":139,"_132":59,"_38":140,"_13":141,"_33":142,"_35":143,"_24":25,"_135":-5,"_27":144},{"_43":130,"_32":28,"_30":31,"_131":-5,"_41":42,"_40":14,"_132":25,"_38":133,"_13":134,"_33":34,"_35":37,"_24":25,"_135":-5,"_27":136},"4c1f683a-4dd6-4d3a-9c4d-0675467a2054","parentId","latest",["D",1788675048780],10,"label",[28],"6d440a6f-42e1-489e-b982-7deb1ae8636a","main.tsx",54,["D",1788645819837],51,"http","// The runtime doesn't allow importing files as text, so the two static files\n// are fetched from this module's own origin and cached for the process.\nconst BASE = new URL(\".\", import.meta.url);\nconst cache = new Map();\n\nconst load = async (name: string): Promise => {\n const cached = cache.get(name);\n if (cached !== undefined) return cached;\n\n const res = await fetch(new URL(name, BASE));\n if (!res.ok) throw new Error(`could not load ${name}: ${res.status}`);\n\n const text = await res.text();\n cache.set(name, text);\n return text;\n};\n\n// Two routes: the page itself, and the simulation module it loads.\nexport default async (req: Request): Promise => {\n const { pathname } = new URL(req.url);\n\n if (pathname === \"/sim.js\") {\n return new Response(await load(\"sim.js\"), {\n headers: { \"content-type\": \"text/javascript; charset=utf-8\" },\n });\n }\n\n return new Response(await load(\"index.html\"), {\n headers: { \"content-type\": \"text/html; charset=utf-8\" },\n });\n};\n",[138],"410ad68f-22b0-4dd5-b50d-3c53ae812f85","index.html","99fb19d0-a975-11f1-81e2-1607ee4eb77e",52,["D",1788645798465],"\n\n\n\n\nBalls in a Circle\n\n\n\n

\n 2 balls\n \n \n

\n\n\n\n",[146],"pulls","branches",1,"forks","envVars",{"_160":63,"_162":63},"connections",{"_160":63,"_161":63},"count","unfilledCount","emptyCount",{"_43":145,"_32":146,"_30":147,"_131":-5,"_41":42,"_40":148,"_132":59,"_38":173,"_13":63,"_33":20,"_35":150,"_24":25,"_135":-5,"_167":174,"_27":175},{"_43":137,"_32":138,"_30":57,"_131":-5,"_41":42,"_40":139,"_132":59,"_38":170,"_13":141,"_33":142,"_35":143,"_24":25,"_135":-5,"_167":171,"_27":172},{"_43":130,"_32":28,"_30":31,"_131":-5,"_41":42,"_40":14,"_132":25,"_38":166,"_13":134,"_33":34,"_35":37,"_24":25,"_135":-5,"_167":168,"_27":169},["D",1788675048780],"children",[],[28],["D",1788645819837],[],[138],["D",1788645798465],[],[146],["D",1788569603047],{"_97":96,"_104":100},{"_97":96,"_98":-5,"_99":100,"_18":55,"_101":102,"_103":25},{"_13":86,"_32":87,"_43":42,"_88":44,"_89":-5,"_90":-5,"_91":-5,"_92":-5,"_93":-5,"_94":45,"_95":96},"ctx",{"_79":-5,"_124":213,"_214":215,"_216":217,"_218":25,"_219":25,"_220":25,"_221":59,"_222":-5,"_223":-7,"_224":-7,"_225":63,"_226":25,"_227":25,"_228":-5,"_229":25,"_230":25,"_231":25,"_232":-5},"ENV",{"_184":185,"_186":187,"_188":87,"_189":190,"_191":192,"_193":194,"_195":196,"_197":198,"_199":200,"_201":202,"_203":204,"_205":206,"_207":208,"_209":210,"_211":212},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e87eb04e707cf64e7e532c8e8ec395f209e17f15","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]

Diff · v64