6.9 Timing and Async

Step 1 — Recall the definition: Synchronous means code that runs to completion before anything else can happen (Definition 6.9.1).

Step 2 — Apply it to the draw loop: moSHion calls your draw function about 60 times a second, and each call runs every one of your lines, top to bottom, with nothing interrupting. Only after your last line has finished does the engine move the physics, redraw the screen, and schedule the next frame — so no two frames ever overlap, and nothing can happen "in the middle" of one.

Answer: Saying the draw loop is synchronous means each frame runs to completion — the engine calls draw, waits for every line to finish, and only then moves the physics and schedules the next frame; nothing else can happen during a frame.

Step 1 — Remember the frame budget: At 60 frames a second, one frame gets about \(1000 \div 60 \approx 16.7\) milliseconds, and your draw code is included in that budget.

Step 2 — See what happens when the budget is blown: If draw takes too long, the engine cannot finish the frame in time, so frames get dropped and the whole game stutters or slows down. Because the loop is synchronous, a slow draw doesn't just waste time — it blocks the physics update and the next frame, making the game unplayable rather than merely untidy.

Answer: A slow draw is fatal, not just inefficient: the entire frame budget is only about 16 ms and your code is part of it, so a slow draw blows the budget, drops frames, and makes the game stutter or crawl.

Step 1 — Set up the division: One second is \(1000\) milliseconds, and at 60 frames per second that second is split evenly among 60 frames.

Step 2 — Do the arithmetic: \(1000 \div 60 \approx 16.7\), so each frame gets roughly 16–17 milliseconds.

Answer: About 16 milliseconds per frame (\(1000 \div 60 \approx 16.7\) ms) — and that budget includes your draw code.

Step 1 — Say what it is: frameCount is a read-only count of the frames elapsed since the sketch started (Definition 6.9.2). The engine adds 1 to it every time it runs your draw function, so after 5 seconds at 60 fps it reads about 300.

Step 2 — Explain why you cannot set it: The count belongs to the engine, not to you — moSHion increments it as part of driving the loop, and your code merely reads it. If sketches could assign to it, they could corrupt the engine's record of how much game time has passed, so it is kept read-only.

Answer: frameCount is a read-only counter of frames since the sketch started, incremented by the engine itself once per frame; you cannot set it because it is the engine's internal bookkeeping — you can read it, but not write it.

Step 1 — Convert seconds to frames: At about 60 frames per second, two seconds is \(60 \times 2 = 120\) frames.

Step 2 — Write the modulo condition: frameCount % 120 === 0 is true whenever the frame count is an exact multiple of 120, which happens once every 120 frames — that is, once every two seconds.

if (frameCount % 120 === 0) {
  // runs once every two seconds
}

Answer: frameCount % 120 === 0 — true once every 120 frames, which is once every two seconds at 60 frames a second.

Step 1 — Recall what setTimeout actually does: setTimeout(callback, 1500) hands the callback to the browser and returns immediately — it schedules the work for later; it does not wait for it (Definition 6.9.3).

Step 2 — Trace the 1.5 seconds: Because the call returned instantly, the engine keeps calling draw about 60 times a second for the entire 1.5 seconds, so the camera keeps scrolling, the keys keep working, and the world keeps updating. Only when 1500 real milliseconds have elapsed does the browser fire the callback that resets the player's position and makes it visible again.

Answer: The level keeps updating because setTimeout is asynchronous — it schedules the respawn and returns at once, so the draw loop never pauses; the browser simply fires the callback 1.5 seconds later, after the game has been running normally the whole time.

Step 1 — Define synchronous (one sentence): Take it straight from Definition 6.9.1.

Step 2 — Define asynchronous (one sentence): Take it straight from Definition 6.9.3 and the comparison table.

Answer:

• Synchronous: code that runs to completion before anything else can happen.
• Asynchronous: work handed to the browser to run later, while the current code carries straight on.

Step 1 — Identify the first argument: Both functions take a callback function first — the code to run when the timer fires (fn in setTimeout(fn, ms) and setInterval(fn, ms)).

Step 2 — Identify the unit of the second argument: The delay is measured in milliseconds, so setTimeout(fn, 1500) means 1.5 real seconds — not 1500 frames.

Answer: Both take a callback function as their first argument, and the second argument is a number of milliseconds.

Step 1 — Classify each timed event: Bonus coins are a game-world event — a spawn rate that should stay consistent with the action on screen. The respawn is a real-world wait — the player is watching the clock and expects an actual 1.5 seconds.

Step 2 — Match each to its mechanism: Frame counting (frameCount % 180) naturally speeds up and slows down with the game, which is exactly what a spawn rate wants; milliseconds (setTimeout(..., 1500)) measure wall-clock time, which is exactly what a player-timed delay wants.

Step 3 — Break it by swapping: A coin spawner on setTimeout would keep firing on real time even if the frame rate collapsed, spawning coins faster than the game world is actually progressing. A respawn on frameCount % 90 would take 90 frames however long those frames last — at a struggling 30 fps that is 3 full seconds, and the player has no idea why.

Answer: Coins use frameCount because a spawn rate belongs to the game world and should slow down when the game slows down; the respawn uses setTimeout because a player-timed delay belongs to the real world and must be a true 1.5 seconds. Swapped, coins would spawn on wall-clock time even while the game crawled, and the respawn would silently stretch well past 1.5 seconds on any machine not hitting 60 fps.

Step 1 — Convert half a second to frames: \(0.5 \times 60 = 30\) frames, so the visibility should flip once every 30 frames — that is the condition frameCount % 30 === 0.

Step 2 — Toggle a flag and draw conditionally: Keep a boolean, flip it on every 30th frame, and only draw the text while it is true. Dropped into the §6.9.5 countdown (which already has remaining):

▶ Press Run to see the output…

Step 3 — Consider the alternative: An interval could do the toggling too (setInterval(() => showText = !showText, 500)), but doing it inside draw with frameCount keeps the blink in the same loop that renders it — and there is no interval to remember to clear.

Answer: Use if (frameCount % 30 === 0) showText = !showText; inside draw (30 frames = 0.5 s at 60 fps) and draw the "Get Ready!" text only when showText is true.

Step 1 — Remember that setInterval is forever: It fires every ms milliseconds until you explicitly cancel it with clearInterval(id) — the browser will never stop it on its own.

Step 2 — Trace what happens without the clear: The callback keeps firing long after the thing it belonged to is gone. In the countdown, skipping clearInterval(countdown) means remaining keeps decrementing forever — \(-1, -2, -3, \ldots\) — quietly consuming resources and corrupting the very state the game reads. Nothing crashes, which is exactly what makes it a quiet bug.

Answer: Every setInterval needs a matching clearInterval because the interval otherwise repeats forever: the callback keeps running after it has any meaning — ticking counters into negative numbers and leaking resources — a quiet bug that never announces itself. That is why you decide where the interval gets cleared in the same breath you write it.

Step 1 — Match each job to its natural rate: The countdown changes once per second, and an interval fires exactly once per second — a perfect match. draw runs about 60 times a second, so it is the wrong place to count; worse, starting the setInterval inside draw would create 60 new intervals every second.

Step 2 — Separate state from display: The interval owns the state: it decrements remaining and clears itself once remaining hits zero. draw owns the display: each frame it just reads whatever remaining currently holds and renders it. Neither needs to know the other's timing, and the number on screen is automatically in sync with the count.

Answer: The interval ticks at once per second — exactly how often the countdown changes — so it owns the counting (and its own clearInterval); draw runs 60 times a second, so it only reads remaining and displays it. Counting and displaying are different jobs at different rates, so each lives where its rate is natural.