* { margin: 0; padding: 0; box-sizing: border-box; }

html, body {
  width: 100%;
  height: 100%;
  overflow: hidden;
  background: #0d0b14;
  touch-action: none;
  -webkit-user-select: none;
  user-select: none;
}

body {
  display: flex;
  align-items: center;
  justify-content: center;
}

#screen {
  image-rendering: pixelated;
  image-rendering: crisp-edges;
  display: block;
}

#rotate { display: none; }

/* The game is 16:9. Fitted into a portrait phone it is a band across the middle
   whatever the scaling — a 390x844 screen gives it 390x219 and leaves the rest
   empty — so ask for landscape, where the same phone gives it 694x390 instead.
   Touch only: a tall desktop window is portrait too, and has nothing to turn.
   js/main.js pauses the simulation while this is up, so nothing happens behind
   it. */
@media (orientation: portrait) {
  body.touch #rotate {
    display: flex;
    position: fixed;
    inset: 0;
    z-index: 10;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    gap: 1.5rem;
    background: #0d0b14;
    color: #f2e9dc;
    font-family: sans-serif;
    font-size: 1.1rem;
    text-align: center;
    padding: 2rem;
  }

  body.touch #screen,
  body.touch #pad { visibility: hidden; }
}

.rotate-icon {
  font-size: 4rem;
  line-height: 1;
  color: #a077c9;
  animation: rotate-hint 2.4s ease-in-out infinite;
}

@keyframes rotate-hint {
  0%, 40% { transform: rotate(90deg); }
  60%, 100% { transform: rotate(0deg); }
}

@media (prefers-reduced-motion: reduce) {
  .rotate-icon { animation: none; transform: rotate(90deg); }
}

#pad { display: none; }

body.touch #pad {
  display: block;
  position: fixed;
  inset: 0;
  pointer-events: none;

  /* The band beside the canvas is exactly --canvas-left wide, on both sides:
     the canvas is centred, so what is left over is split evenly. Two arrows
     share the left one, the jump key has the right one to itself. clamp() keeps
     the widths sane on the single frame before resize() has published anything,
     when --canvas-left is still 0. */
  --gutter: var(--canvas-left, 0px);
  --arrow: clamp(0px, calc((var(--gutter) - 16px) / 2), 72px);
  --jump: clamp(0px, calc(var(--gutter) * 0.8), 84px);
}

/* The keys are laid out against the CANVAS, not the window, and always beside
   it, never over it — computeViewport in js/viewport.js holds the band back for
   exactly this. touchToAction in js/input.js reads the same geometry: the outer
   half of the left band steers left, its inner half right, the right band
   jumps, and the canvas answers to nothing. Each key is drawn inside the column
   it triggers, so what the player presses is what the player sees.

   With the usual 104px band the arrows come out 44px across and sit at 8..52
   and 56..100 — one per half — and the jump key is 83px, centred in the band on
   the other side. The two 4px offsets and the 8px between the arrows are what
   stops a key spilling over a boundary once the widths hit their caps. */
.pad-key {
  position: absolute;
  bottom: 6vh;
  display: flex;
  align-items: center;
  justify-content: center;
  aspect-ratio: 1;
  border-radius: 50%;
  background: rgba(242, 233, 220, 0.14);
  color: rgba(242, 233, 220, 0.6);
  font-family: sans-serif;
}

.pad-left,
.pad-right {
  width: var(--arrow);
  font-size: min(calc(var(--arrow) * 0.45), 25px);
}

.pad-left { left: calc(var(--gutter) - 2 * var(--arrow) - 8px); }
.pad-right { left: calc(var(--gutter) - var(--arrow) - 4px); }

.pad-jump {
  width: var(--jump);
  font-size: min(calc(var(--jump) * 0.35), 25px);
  right: calc((var(--gutter) - var(--jump)) / 2);
}
