My NoisyHexagons Problem Solved: 5 Easy Fixes for 2025

// Bad: Raw floating-point values cause jitter
const xPos = worldX + viewOffsetX;
const yPos = worldY + viewOffsetY;
drawHexagon(xPos, yPos);

// Good: Stabilize the base position before drawing
// This ensures the hexagon's origin doesn't jump between pixels
const stableX = Math.round(worldX + viewOffsetX);
const stableY = Math.round(worldY + viewOffsetY);
drawHexagon(stableX, stableY);
  

// The grid coordinates (q, r) for an axial system
const q = hexagon.q;
const r = hexagon.r;

// Define a scale for your noise field
const noiseScale = 0.1;

// Bad: Using screen position can introduce jitter
// const screenPos = hexagon.toPixel();
// const noiseValue = noise.simplex2(screenPos.x * noiseScale, screenPos.y * noiseScale);

// Good: Using stable grid coordinates guarantees consistent results
const noiseValue = noise.simplex2(q * noiseScale, r * noiseScale);

// Now use this stable noiseValue to determine color, height, etc.
const color = mapValueToColor(noiseValue);
  

By decoupling the noise calculation from the screen rendering, you ensure that the underlying data for your grid is rock-solid. The pattern will now move smoothly with the grid, not shimmer on top of it.

Fix 3: Embrace Integer-Based Coordinates

This builds upon the previous fixes and is arguably the most robust solution. Instead of thinking about your hexagons in terms of `x`/`y` pixels, manage them exclusively with integer-based grid coordinates. The most popular system for hex grids is the axial coordinate system, which uses two axes (`q`, `r`) to define every hexagon.

Your entire application logic—pathfinding, neighbor-finding, data storage—should operate on these `(q, r)` integer pairs. You should only convert to pixel coordinates at the very last moment, inside your rendering loop.

The Logic-to-Render Pipeline

1. Logic Loop: All your updates happen here. A hexagon moves from `(q: 1, r: 2)` to `(q: 1, r: 3)`. No pixels involved.
2. Rendering Loop: Iterate through the hexagons you need to draw. For each one, take its integer coordinates `(q, r)` and run them through a `hexToPixel()` conversion function.
3. Drawing: Use the resulting pixel coordinates to draw the hexagon.

This separation of concerns is powerful. Since all your state is managed with integers, there are no floating-point errors to accumulate. The conversion to pixels happens fresh every frame, eliminating historical errors.

// A function to convert integer axial coordinates to screen pixels
function hexToPixel(q, r) {
  const x = size * (3/2 * q);
  const y = size * (Math.sqrt(3)/2 * q + Math.sqrt(3) * r);
  return { x: x, y: y };
}

// In your render loop
for (const hex of visibleHexagons) {
  // hex.q and hex.r are integers!
  const pixelPosition = hexToPixel(hex.q, hex.r);
  
  // Add camera offset *after* the conversion
  const finalX = pixelPosition.x - camera.x;
  const finalY = pixelPosition.y - camera.y;

  drawHexagonOnCanvas(finalX, finalY, hex.color);
}
  

This approach completely eradicates jitter caused by floating-point drift in your application state.

Fix 4: Decouple Rendering from Logic

Sometimes, the flicker you see isn’t jitter—it’s screen tearing. This can happen if you update a hexagon’s state (like its color) and draw it in the same function call, especially if that call happens multiple times per frame. The browser might render the screen halfway through one of your updates, showing a mix of old and new states.

The classic game development solution is to separate your `update` logic from your `draw` logic. The `requestAnimationFrame` browser API is perfect for this.

The Game Loop Pattern

Structure your code into a main loop. In each frame, you first process all logic/state updates, and only then do you perform any drawing.

const allHexagons = [/* ... your hex data ... */];

function updateState(deltaTime) {
  // Handle user input, animations, physics, etc.
  for (const hex of allHexagons) {
    hex.update(deltaTime); // e.g., change color based on noise over time
  }
}

function drawScene() {
  // Clear the canvas
  context.clearRect(0, 0, canvas.width, canvas.height);

  // Draw every hexagon based on its *current* state
  for (const hex of allHexagons) {
    hex.draw(context);
  }
}

function gameLoop(timestamp) {
  const deltaTime = timestamp - lastTimestamp;
  lastTimestamp = timestamp;

  updateState(deltaTime);
  drawScene();

  requestAnimationFrame(gameLoop);
}

// Start the loop
let lastTimestamp = 0;
requestAnimationFrame(gameLoop);
  

This ensures that every frame you draw is a complete, consistent snapshot of your application’s state. No more drawing a half-updated scene.

Fix 5: The Double-Buffering Trick

If you’ve implemented all the above and still see a stubborn flicker, especially on complex scenes, it’s time to bring out the secret weapon: double-buffering.

The concept is simple: instead of drawing directly to the main canvas that the user sees, you draw your entire scene to a hidden, off-screen canvas first. Once everything is perfectly drawn on this hidden canvas, you copy the entire result to the visible canvas in a single, atomic operation.

This completely eliminates any flicker caused by the browser rendering the canvas while you’re still in the middle of drawing hundreds or thousands of hexagons.

A Simple Implementation

// Main canvas visible on the page
const visibleCanvas = document.getElementById('myCanvas');
const visibleCtx = visibleCanvas.getContext('2d');

// Hidden off-screen canvas for buffering
const bufferCanvas = document.createElement('canvas');
bufferCanvas.width = visibleCanvas.width;
bufferCanvas.height = visibleCanvas.height;
const bufferCtx = bufferCanvas.getContext('2d');

function drawScene() {
  // 1. Draw everything to the HIDDEN buffer
  bufferCtx.clearRect(0, 0, bufferCanvas.width, bufferCanvas.height);
  for (const hex of allHexagons) {
    // Pass the buffer's context to your draw functions
    hex.draw(bufferCtx);
  }

  // 2. Clear the VISIBLE canvas
  visibleCtx.clearRect(0, 0, visibleCanvas.width, visibleCanvas.height);

  // 3. Copy the finished buffer to the visible canvas in one go
  visibleCtx.drawImage(bufferCanvas, 0, 0);
}

// Your gameLoop remains the same, just calling this new drawScene()
// requestAnimationFrame(gameLoop);
  

This technique is the ultimate solution for achieving buttery-smooth, tear-free rendering, and it’s a standard practice in graphics programming for a reason.

Conclusion: No More Noisy Hexagons

The NoisyHexagons problem can feel like a mysterious curse, but it almost always boils down to predictable issues with floating-point math and rendering timing. By systematically applying these five fixes, you can build a stable and performant foundation for your hexagonal creations.

To recap:

• Stabilize coordinates: Round inputs to prevent pixel-level jitter.
• Optimize noise sampling: Use grid coordinates, not screen coordinates, for noise.
• Use integer coordinates: Manage state with integers (`q`, `r`) and convert to pixels only for drawing.
• Decouple logic and rendering: Use an `update`/`draw` loop with `requestAnimationFrame`.
• Use double-buffering: Draw to a hidden canvas first for perfectly smooth frames.

Don’t let rendering glitches derail your creative vision. With these strategies in your toolkit, you can focus on what really matters: bringing your amazing hexagonal worlds to life. Happy coding!