Pixel-Art Motion: Walks, Cameras and Doors on iPhone

Pokémon Red, Crystal and Emerald, one game from each of the three Game Boy and Game Boy Advance generations, all walk a 16-pixel cell in 16 frames at about 59.73 hertz, 3.73 cells a second, and nothing about the step is left to a clock: Emerald moves the player exactly one pixel a frame, shows one stride drawing and one standing drawing per step, and scrolls the camera on the same frame by the same pixels.¹²³ Red and Crystal reach the same sixteen frames by moving two pixels every second frame.⁴ Emerald’s door opens in four drawings held five frames each, the player is walked one forced step in, the door shuts, and the screen fades in nine stepped levels: at least 79 frames, 1.32 seconds, before the next map can begin to load.¹⁵ Kiradex’s world walks by elapsed time and eases its camera, and a model of that code (a model, not a capture from a phone) says the sprite hitches two pixels once a tile at 60 hertz, the camera falls about a pixel further behind with each tile of a walk at 60 hertz (9 pixels by the fifth, and 13 on a run) and comes to rest 4 to 9 pixels short, and the walk drawings keep a clock of their own, one cycle to 3.00 tiles where Emerald’s covers two.⁶ Apple gives games special priority at 30 and 60 hertz and RealityKit typically renders at 60, so the brief is a fixed 60-hertz tick with whole-pixel steps, walk drawings chosen by the distance walked (my proposal, not how the handhelds do it), a locked camera, Emerald’s door ceremony in our own art, three optional haptic events, and 60 hertz rather than 120.⁷⁸ This is the canon measured from the decompilations, the iPhone side from Apple’s pages, and the brief with the checks it must pass.

TL;DR

• A step is a contract, not a speed. Every Emerald step table sums to 16 pixels: the walk is 1 pixel a frame for 16 frames (268 milliseconds a cell), running and surfing 2 for 8, the Mach Bike’s top speed 4 for 4, and only the Acro Bike’s 2-3-3-2-3-3 is uneven. Red and Crystal walk the same 16 frames in 2-pixel jumps at 30 updates a second.¹²⁴
• The legs and the step are timed to match. Emerald counts the drawings and the step in frames, separately, and makes the counts agree: the walk is stride, stand, stride, stand at 8 frames a drawing over two 16-frame cells; faster gaits halve the hold rather than add drawings, so there is one footfall per 16 pixels at every speed. Turning from standing takes 8 frames (134 milliseconds), turning while walking none, and walking into a wall plays a 32-frame bump.¹⁹¹⁰²
• The camera is the player. Emerald’s camera copies the player’s position and scrolls by the same pixels on the same frame, with no lag and no lead, and never stops at a map’s edge because the outside is drawn from border tiles. Game Freak wrote a camera that leads the bike and shipped it switched off.²³¹¹¹²
• A door is a ceremony. Four drawings of five frames (335 milliseconds), a forced step of 16 frames, the door closing in 20, and a fade whose last blend lands on its 17th frame and which finishes on its 22nd: at least 79 frames, 1.32 seconds, with no input before the map can load. That confirms this series’ structures post, about 84 milliseconds a drawing, and corrects the research notes behind it, which had “4 ticks each (16 frames, about 0.27 s at 59.7 Hz).” Crystal fades to white in 8 frames; Red fades to black in 32.^1513144
• On iPhone, pace evenly at 60. preferredFrameRateRange (iOS 15.0) is a hint; ProMotion iPhones run 10 to 120 hertz in twelve steps; above 60 needs CADisableMinimumFrameDurationOnPhone; games get “special priority to 30Hz and 60Hz”; RealityKit “typically limits the refresh rate” to 60. A whole-pixel walk gains nothing at 120: each pixel is simply held for two refreshes.^1571686
• Kiradex today, modeled rather than measured. The code walks at 4 tiles a second by elapsed time, so a model at a steady 60 hertz takes 15 frames a tile and moves 2 pixels on one of them; it eases and rounds the camera, which falls further behind as a walk goes on (5 pixels after the first tile, 9 after the fifth, 13 on a run) and comes to rest 4 pixels off the player at 60 hertz and 9 at 120; its six-drawing walk at 8 a second covers 3.00 tiles a cycle walking and 4.50 running. No phone has been measured.¹⁷⁶
• What this gives Kiradex: a brief, not a shipped build. A fixed 60-hertz tick with 1-pixel steps and a stated backlog rule, walk drawings chosen by distance, a locked camera on whole pixels, the full door sequence with a stepped fade, a refused step shown, three optional haptic events, no request for 120 hertz, and for each a check that a motion log, a capture or a script can verify.

1. Emerald’s walk: sixteen pixels in sixteen frames

The first two posts in this series measured what a pixel world and its people look like; the third measured its buildings. This one measures time: how many pixels a frame, how many frames a step, which drawing shows on which frame, how long a turn, a door and a fade take, and what the camera does while all of that happens. The games are read the way the earlier posts read them, from pret’s decompilations of the published Game Boy and Game Boy Advance games, at the commits the earlier posts used: pokered d2704a6, pokecrystal 5beda23, pokeemerald 731ad5b.¹⁸ Five small scripts did the counting; each is named in the notes with its saved output.

One number first, because everything else is in frames. The Game Boy Advance draws a frame in 280,896 cycles of a 2^24-hertz clock, which is 59.7275 frames a second, 16.743 milliseconds a frame; GBATEK rounds it to “ca. 59.737 Hz”.¹⁹ The original Game Boy’s 4,194,304-hertz clock over 70,224 dots a frame gives the same 59.7275; Pan Docs says “@ 59.7 fps”.¹⁹ Milliseconds in this post use 59.7275.¹⁹

Every speed is a table that sums to sixteen

Emerald does not move a walker by speed times time. Each overworld speed is a table of per-frame pixel moves, and the source says what every table has in common: “Over the course of the step animation, these sum to 16 pixels (one full metatile).”² sStep1Funcs is sixteen one-pixel moves, sStep2Funcs eight two-pixel moves, sStep4Funcs four of four, sStep8Funcs two of eight, and sStep3Funcs is the odd one, Step2, Step3, Step3, Step2, Step3, Step3.² Counted by script against the movement source, that gives:

Source for every row: measure_gen3_motion.py over src/event_object_movement.c.¹

The walk is the number to remember: one pixel on every frame, sixteen frames a cell, 3.73 cells a second, 268 milliseconds a cell, used by PlayerWalkNormal and by every walking NPC.¹ Running with the B button is PlayerRun, and surfing is PlayerWalkFast, which the source annotates “same speed as running”; ice slides call the same function. All three are two pixels a frame, eight frames a cell, 7.47 cells a second.¹¹⁰ There is also a slow walk, UpdateWalkSlowAnim, that steps one pixel on even timer values, 31 to 32 frames a cell, for scripted scenes.¹

The Acro Bike is the only speed whose pixels are uneven: 2, 3, 3, 2, 3, 3 over six frames, 2.67 pixels a frame on average, 9.95 cells a second.¹ It is reached through PlayerRideWaterCurrent from AcroBikeTransition_Moving, the same function the water currents use.¹²⁰ On my reading the unevenness is the price of a speed that does not divide sixteen: three pixels a frame would overshoot the cell, so the table alternates twos and threes to land on sixteen exactly. Every other speed is a whole divisor of the cell.

The Mach Bike accelerates by step rather than by frame. sMachBikeSpeedCallbacks is PlayerWalkNormal, PlayerWalkFast, PlayerWalkFaster, and bikeFrameCounter rises by one per step to a cap of 2, so the first step from standing takes 16 frames, the second 8, and every later step 4: four pixels a frame, 14.93 cells a second.¹²⁰ The bike never sits between two speeds. Each step is one of the tables, run to completion, and the speed only changes at a cell boundary.

Every gait measured in Red, Crystal and Emerald is a whole number of frames per 16-pixel cell; Kiradex’s numbers are a model of its code, not a capture.¹⁴⁶²¹

One footfall per sixteen pixels

The walk animation is stride, stand, stride, stand. sAnim_GoSouth is ANIMCMD_FRAME(3, 8), (0, 8), (4, 8), (0, 8): drawing 3 for eight frames, the standing drawing 0 for eight, drawing 4 for eight, the standing drawing again for eight, 32 frames in all, which is two cells of walking.⁹¹ The hold is exact: sprite.c loads the frame’s duration minus one into the delay counter and counts down to zero, so a frame of duration 8 is on screen for eight frames.⁹¹ Each step therefore shows one stride drawing and one standing drawing, and SetStepAnimHandleAlternation starts every new step at the other half of the cycle (animPos = {1, 3, 0, 2}), so the left and right legs alternate step by step even when the player stops and starts.² This series’ first post described the same cycle from the art side: “step, stand, step, stand at eight ticks each, which is the bob everyone remembers.”²²

Faster gaits keep the drawings and shorten the hold. GoFast holds each drawing four frames (a 16-frame cycle), GoFaster two (8 frames), GoFastest one (4 frames).¹ The run has drawings of its own, held unevenly: sAnim_RunSouth is (12, 5), (9, 3), (13, 5), (9, 3), a 16-frame cycle.¹⁹

Put the two tables side by side and the design shows. The walk’s 32-frame cycle covers two cells of 16 frames; the run’s 16-frame cycle covers two cells of 8; the Mach Bike’s 8-frame GoFaster cycle covers two cells of 4.¹⁹ At every speed, one footfall lands per 16 pixels.¹ These are two clocks, not one counter. The drawing advances when animDelayCounter, loaded from each frame’s duration in sprite.c, runs out; the step advances when NpcTakeStep indexes the speed’s table with the sprite’s sTimer, one entry a frame; and SetStepAnimHandleAlternation picks the gait’s animation when each step begins.⁹² What keeps them together is that both are counted in the same frames and the durations were chosen to agree, gait by gait. On my reading, that is the thing to copy: the drawings’ cadence cannot drift away from the movement, because each step’s drawings last exactly as many frames as the step does. Nothing in these tables or in my model measures where a planted foot sits against the ground, so I do not claim more than that.

Turning, bumping and when input is read

A step, once begun, finishes; the pad is read when it completes, so a held direction chains steps with no gap and a change of direction while walking costs nothing.¹⁰ From standing, it is different. CheckMovementInputNotOnBike returns TURN_DIRECTION only when the new direction differs from the facing and the player is not already moving, and PlayerTurnInPlace plays the fast walk-in-place, which InitMoveInPlace gives a duration of 8 frames: 134 milliseconds of turning on the spot.¹⁰¹ That is the mechanic that lets a player face a sign or a person without stepping toward them. Walking into a wall plays the slow walk-in-place instead, 32 frames, 536 milliseconds, with a bump sound: a refused step is shown, not swallowed.¹¹⁰ The normal and faster walk-in-place actions are 16 frames (268 milliseconds) and 4 (67).¹

On my reading, those four numbers are most of what “responsive” means in a grid game. The world never moves a fraction of a cell, so the player’s intent is expressed in whole steps, and the only latency is the remainder of the step in progress: at most 268 milliseconds walking, 134 running.¹ The turn from standing is not latency but a separate action with its own visible result.

2. Emerald’s camera, doors, fades and shakes

The camera has no lag and no lead

Emerald’s camera is an invisible sprite that follows the player. CameraObject_UpdateMove copies the followed sprite’s x and y and stores the difference from the last frame in sCamera_MoveX and sCamera_MoveY; CameraUpdateCallback hands that difference to CameraUpdate, which scrolls the map by exactly that many pixels.²¹² The overworld loop runs RunTasks(); AnimateSprites(); CameraUpdate(); UpdateCameraPanning(); in that order every frame, and because AnimateSprites runs sprite callbacks in slot order and the camera object is created after the player (InitPlayerAvatar, then InitCameraUpdateCallback(gPlayerAvatar.spriteId)), the camera reads the position the player reached on that same frame.³ I traced that order through the code rather than running it, so it is a reading, not a measurement; but the result it implies is simple. The player’s move and the scroll land on the same frame, by the same pixels. On screen, the player never moves at all while the world slides under them.

Itay Keren’s name for this, in his GDC 2015 talk on side-scroller cameras, is position-locking: the camera stays on the player, “keeping the car in focus at all times and the camera motion completely predictable.”²³ Emerald adds one thing his definition leaves open, which is what happens at the edge of the map. It never stops. Cells outside a map’s layout are read through GetBorderBlockAt, which returns the layout’s 2-by-2 border metatiles repeated and marked MAPGRID_IMPASSABLE, so the view keeps the player in the same screen position and fills the outside with border trees or water.¹¹ Keren’s edge-snapping, the alternative, “simply snaps the camera to the edge of the level, allowing the character to move away from its anchor point.”²³ Emerald drew its way out of needing it.

The camera Game Freak wrote and switched off

field_camera.c contains a finished look-ahead for the bike. CameraPanningCB_PanAhead shifts the vertical pan by 2 pixels per update, from its resting value of 32 toward 72 or toward minus 8 depending on the direction of travel, which is 40 pixels either way: a camera that leads the player into where they are going.¹² It runs only if gUnusedBikeCameraAheadPanback is true, the variable is only ever set to FALSE (in bike.c), and the branch carries the comment “this code is never reached.”¹²²⁰ In Keren’s vocabulary it is a dual-forward-focus or target-focus, the camera that follows his rule “When you walk left, you want to see more to the left.”²³ Whatever the reason it was left off, the shipped game kept the camera locked even at the Mach Bike’s 4 pixels a frame.¹

A door opens in twenty frames, not sixteen

The door table in field_door.c reads as if each drawing takes four frames: sDoorOpenAnimFrames is {4, -1}, {4, 0}, {4, 0x100}, {4, 0x200}, closed plus three open drawings.²⁴ But AnimateDoorFrame draws when its counter is 0 and advances when the counter equals the entry’s time, so each drawing is held for five updates: 84 milliseconds a drawing, 335 for the four.²⁴¹ This series’ structures post gave the same figure, five updates and about 84 milliseconds.¹³ The research notes that post was written from had it wrong, “4 ticks each (16 frames, about 0.27 s at 59.7 Hz),” and so does a comment in the app’s own door code, which says it opens “at about Emerald’s four ticks a frame” and then holds the first drawing 70 milliseconds; both are corrected here and in the brief.¹⁴¹⁷

The entry itself, Task_DoDoorWarp, is five states with nothing skippable: freeze the other objects, play the door sound and open the door above the player; force a MOVEMENT_ACTION_WALK_NORMAL_UP step into the doorway; when the player stands still, close the door and hide the player; when the door task ends, fade the music and the screen; load the map.²⁵ Leaving runs the ceremony backwards: Task_ExitDoor shows the door already open, waits for the fade-in, forces one WALK_NORMAL_DOWN step, closes the door, and only then gives the controls back.²⁵

Added up from the counts above and the fade’s trace below, the door opens in 20 frames, the step takes 16 and the door closes in 20; the fade that follows makes its last blend on its 17th frame, so the screen is fully dark after at least 73 frames, 1.22 seconds. The map cannot begin to load until the fade has gone inactive, on its 22nd frame, and Task_WarpAndLoadMap has seen that and moved on: at least 79 frames, 1.32 seconds.⁵²⁵ The state changes between the door’s phases and the wait for the music to stop can only add frames, so both are lower bounds.⁵

Emerald’s entry is a lower bound from its frame counts; Kiradex’s row is read from the app’s door code, not timed on a phone.¹⁵¹⁷²¹

A fade is nine levels

A warp fade in Emerald is not a smooth ramp. BeginNormalPaletteFade sets a step of 2 on a blend coefficient that runs from 0 to 16, UpdateNormalPaletteFade blends the background palettes on one call and the sprite palettes on the next and then steps the coefficient, and IsSoftwarePaletteFadeFinishing adds five calls at the end.²⁶ Which frame each call lands on depends on who calls it. The door’s task starts the fade from inside RunTasks, and BeginNormalPaletteFade runs one update itself, copies the result to palette memory at once and clears the flag that would otherwise make the next update wait for the vertical blank; later in the same frame, OverworldBasic calls UpdatePaletteFade again.²⁵²⁶³ So the first frame gets two updates, both at level 0, and every later frame one. A Python port of palette.c with that schedule, counting the task’s frame as 0, gives nine levels, 0, 2, 4 and so on to 16: the background palettes reach level 2 on frame 1 and level 16 on frame 15, the sprite palettes a frame behind each time, the last blend on frame 16 (285 milliseconds counting frame 0), and the fade inactive on frame 21 (368 milliseconds).⁵ A blend computed on a frame reaches the screen at the vertical blank that ends it. The port assumes no fade was running before and the normal overworld update; with rain, snow, fog, shade or drought active, the fade out runs the same way from the weather-tinted colors (FadeScreen copies the tinted buffer first and then calls the same BeginNormalPaletteFade), but the fade in is run by the weather code, and that path was not simulated.⁵

Nine levels two sixteenths apart, background and sprites a frame apart: the ramp the brief adapts to one veil.⁵²¹

Warps fade to black, with one family of exceptions, and the exception has a direction. WarpFadeOutScreen asks GetMapPairFadeToType about the pair of map types, WarpFadeInScreen asks GetMapPairFadeFromType, and each calls FadeScreen with white when the answer is true and black otherwise.²⁵ Both look the pair up in sTransitionTypes, whose 16 rows are every map type into and out of MAP_TYPE_UNDERGROUND; the first returns a row’s enter flag and the second its exit flag, which are true only on the rows into a cave and only on the rows out of one.²⁷ So going into a cave the screen fades out to white and back in from black, and coming out of one it fades out to black and back in from white. Each row also names a cave transition routine of its own, which I did not trace.²⁷ A slower white fade, FadeInFromWhite with a delay of 8, goes inactive after 86 or 87 frames, 1.44 to 1.46 seconds; it is started from the map-load callback, whose first frame I did not trace, and the port gives both cases.⁵²⁵

Shake is a scripted pan

Screen shake in Emerald is a script command, not a physics effect. ShakeCamera reads a vertical pan, a horizontal pan, a number of shakes and the frames between shakes from four script variables and negates the pan on each shake.²⁸ Across the game’s scripts there are 24 calls in 9 files, and a script counted all of them:²⁹

Source: measure_gen3_shake.py across data/**/*.inc.²⁹

Ten of the 24 are the same shake: one pixel each way, eight flips, five frames apart, 670 milliseconds.²⁹ The largest is 3 pixels horizontal; the longest is 100 frames, 1.67 seconds.²⁹ The elevator’s shake, which the structures post covered (a shake every three frames for a count that grows with the floors traveled), is a separate routine and not in this count.¹³ On my reading, the restraint is the lesson: a shake in Emerald is a pixel or two, used for an event the script has decided matters, never for a footstep or a door.

3. Red and Crystal: the same step at 30 updates a second

Red moves two pixels every second frame

Pokémon Red has no step tables. Its overworld loop, OverworldLoop, calls DelayFrame and falls into OverworldLoopLessDelay, which calls it again, so the world updates once every two frames.³⁰ A step sets wWalkCounter to 8, and each pass AdvancePlayerSprite decrements it and scrolls the background registers hSCX and hSCY by the step vector shifted left once: 2 pixels.³⁰ Eight passes of 2 pixels is 16 pixels in 16 frames, the same 268 milliseconds and 3.73 cells a second as Emerald, in 2-pixel jumps at 30 updates a second.⁴³⁰ The bike is a second advance per pass: DoBikeSpeedup calls AdvancePlayerSprite again (except on Cycling Road while up, left or right is held), so a step takes 8 frames.⁴³⁰

Red’s walk drawings change every four passes, eight frames, through a cycle of four images, stand, step, stand and the step flipped, so it too shows one stride drawing per step.³¹²² UpdatePlayerSprite increments the intra-animation counter each pass and advances the drawing when it reaches 4.³¹²²

Red turns in one loop pass, two frames: a new direction from standing writes the facing and returns to the loop without stepping.³⁰ Its 180-degree turn has an intermediate facing in the code that, by the source’s own comment, nobody sees: “It is unlikely for it to ever be visible because DelayFrame is called at the start of OverworldLoop.”³⁰ I read that from the code and did not run it in an emulator.

The warp is a sound and a fade with no door drawn. PlayMapChangeSound plays SFX_GO_INSIDE when the tile is a door (tile $0b) and SFX_GO_OUTSIDE otherwise, then GBFadeOutToBlack writes four palettes, holding each for eight frames: 32 frames, 536 milliseconds.⁴³² I did not trace Red’s fade back in.

Crystal updates every second frame too

Crystal keeps Red’s cadence with a different mechanism. MaxOverworldDelay is db 2, and the VBlank handler counts wOverworldDelay down, so map objects update every second frame.³³ StepVectors gives the walk eight updates of 2 pixels and the bike four updates of 4: 16 frames and 8 frames a cell, the same as Red and Emerald.⁴ The slow step is sixteen updates of 1 pixel, 32 frames, 1.87 cells a second.⁴³³

Crystal’s doors fade to white, and fast. MapSetupScript_Door begins with FadeOutToWhite and MapSetupScript_Warp ends with FadeInFromWhite; each is four palette steps two frames apart, 8 frames, 134 milliseconds each way.⁴³⁴ Its turn is a four-part step function, StepFunction_Turn, and the parts fall through into each other. On the first update, .init1 sets an OBJECT_STEP_DURATION of 2 and falls into .step1, which counts it down to 1; on the second, .step1 counts it to 0 and falls through .init2, which writes the new facing and sets 2 again, into .step2, which counts it to 1; on the third, .step2 reaches 0 and hands the object back to STEP_TYPE_FROM_MOVEMENT.³³ Replayed instruction by instruction, the routine takes three updates, six frames at two frames an update, with the new facing written on the second. That is the routine alone, read from the code; I did not trace the time from the button press to the routine’s start.³³

Three generations, three fades

Sources: the counts in sections 1 to 3;¹⁴⁵²⁵ Red’s forced step out of a door, PlayerStepOutFromDoor, is from the structures post.¹³

The rows that agree across all three are the ones worth keeping: a fade between maps, a forced step that carries the player over the threshold, and no input during the ceremony. The fade lengths differ by a factor of four, so on my reading the length is a design choice rather than a canon. Emerald’s nine-level fade is the one built around drawn doors, and Kiradex draws its doors,¹³ so it is the one the brief takes.

Red, Crystal and Emerald, one game from each of the three generations on the Game Boy and the Game Boy Advance, two different machines, settled on the same contract: a step is 16 pixels, takes 16 frames at about 59.73 hertz, and cannot be interrupted once begun.¹⁴ Red gets there in 2-pixel jumps because its loop waits two frames a pass; Crystal by the same two-frame delay with 2-pixel vectors; Emerald at the full frame rate with 1-pixel moves. Running, surfing and the bike are the same contract at 8 or 4 frames.¹⁴ When people say these games feel “on rails,” I think this is the rail: the step, the drawing and the camera are all counted in the same frames, with durations chosen to agree, so they cannot drift apart.

4. The modern references: Celeste’s camera, Keren’s vocabulary, and the phone ports

When a camera should smooth, and when it should not

Emerald’s locked camera is one answer in a vocabulary that Itay Keren set out in “Scroll Back: The Theory and Practice of Cameras in Side-Scrollers,” a modified version of his talk at the Independent Games Summit at GDC 2015, published on Game Developer on May 11, 2015.²³ The terms I use in this post are his. Position-locking fixes the camera on the player. Edge-snapping stops it at the level’s edge. A camera-window moves the camera only when the player pushes the window’s edge. Lerp-smoothing eases the camera toward its target, and he calls it “a standard tool in reducing jarring camera speeds, particularly jumps.” Target-focus and dual-forward-focus lead the player into the direction of travel. He also names platform-snapping, region-focus and cue attractors, which a grid walker has no use for.²³

He gives the reason camera motion matters at all: “conflicting sensory signals (Visual vs. Vestibular) may lead to discomfort and nausea, and though it’s worse in 3D (especially VR), it is still very much in effect in 2D games.” And he gives the case where the plainest scheme is right: position-locking, for “a crafting adventure game like Terraria, with a small character relative to the screen with pretty small jumps, it works very well.”²³ A top-down town with a 30-pixel collector, the figure this series’ characters post moved to at build 34, is that case with the jumps taken out.³⁵

Celeste is the modern reference for the other choice. Its developers published the Player class “as a learning resource and for general interest,” with the MIT license covering that code only, and the camera is a few lines in it: level.Camera.Position = from + (target - from) * (1f - (float)Math.Pow(0.01f / multiplier, Engine.DeltaTime)), under the comment “Camera (lerp by distance using delta-time)”.³⁶³⁷ With a multiplier of 1 and a target that holds still, that closes 99 percent of the gap every second whatever the frame rate; Celeste’s target does not hold still, since it is recomputed from the player’s position and state every frame, so that figure describes the easing, not where the camera ends up.³⁶ The target is the player centered in the game’s view (X - Celeste.GameWidth / 2), clamped to the room’s bounds, with offsets for a few states: 48 pixels ahead in the direction of the StRedDash dash, 64 up for the summit launch.³⁶ The first post in this series noted that Celeste renders its world at 320 by 180 and multiplies by six.²²

The two are not in conflict, on my reading. Celeste smooths because a platformer’s jumps would drag the view up and down with every leap; Keren’s own definition of lerp-smoothing is about jumps. A grid walker moves at a constant speed in straight lines, so a lock produces no jolt to smooth away, and a smoothed camera only adds a trail behind a motion that was already even. Section 7 shows what that trail measures to in Kiradex’s model.

What the other games tell us about speed

Stardew Valley states its player speed as a unitless stat: “2 when walking,” “5 when running,” “6.6 when riding a Horse (7 if the horse was fed a carrot that day),” never below 1.³⁸ The wiki does not say what one unit is in pixels per tick, so no tiles-a-second figure is given here for Stardew.

I also looked for a primary source on the cameras of Sea of Stars, Eastward and CrossCode, and found none: interviews about traversal and lighting, nothing on the camera, and Sea of Stars’ “Pixel Perfect” option described only by guides and forums. No Maddy Thorson camera talk or article turned up either, which is why Celeste is cited from its code.³⁹

On a phone: tap to walk, with an escape hatch

Stardew Valley’s mobile version ships nine control schemes, and its default is “Tap-to-move & Auto-Attack”: “Tap anywhere on screen and the farmer will walk to where you tapped.”⁴⁰ Keeping a finger down “will cause the character to follow the touch,” and the wiki warns that follow mode “is very literal, moving directly towards the finger without routing around blocking objects.” The invisible-joystick scheme takes “the left half of the screen” with its center wherever you touch. And the wiki is honest about the default’s limit: some tasks that need careful positioning “can not be completed using the default controls; temporarily switching to a control style with a movement joystick is necessary in such cases.”⁴⁰ The schemes arrived in an update TouchArcade reported on November 1, 2018, with a toggle that drops back to “the default tap-to-move and auto-attack controls.”⁴¹

Square Enix’s Pixel Remaster of the first Final Fantasy on iOS added a walk-or-run default in its version 1.2.0, dated March 11, 2025 in the app’s App Store history (the series ships as separate apps, and only this one was read): “In tap based movement mode the character controlled will always run as the default speed when moving.”⁴² Controller support had come to the mobile versions in an update TouchArcade covered on January 30, 2024.⁴³ I could not find the exact touch movement scheme documented anywhere beyond those notes, nor a description of Terraria’s mobile movement on the wiki page I fetched.³⁹

Apple’s Human Interface Guidelines say the same thing from the platform’s side. For touch games: “consider letting players tap objects to select them instead of adding a virtual selection button”; “For movement control, opt to show a virtual thumbstick wherever the player lands their thumb instead of a static thumbstick position”; “Make sure frequently used controls are a minimum size of 44x44 pt”; “Always include visible and tactile press states”; and for walking and sprinting, “consider combining the actions into a single control.” The page’s change log dates those touch-control practices to June 9, 2025.⁴⁴ At WWDC25, Apple’s session on touch controls put the premise plainly: “the vast majority of players won’t have a controller available.”⁴⁵

None of these sources says tap to walk is the rule for phone games, and I do not claim it. What I take from them, as my recommendation for Kiradex rather than a finding, is the scheme Kiradex already half follows: tap to walk as the default, as Stardew’s mobile version ships it; a thumbstick that appears where the thumb lands, as the HIG advises, for precision; and no fixed on-screen d-pad.⁴⁰⁴⁴

5. The craft, as rules with numbers

These are the rules the brief in section 7 is written against, each traced to a measurement above. “Tick” means one simulation step of 1/60 of a second, which is how a 59.73-hertz frame becomes something an iPhone can hold to; at 16 ticks a cell, the walk is 3.75 cells a second instead of 3.73.¹¹⁹

Sources for the table: Emerald’s walk, animation and door counts;¹ its separate drawing and step timers;⁹² its camera;¹²³ its fade and shakes;⁵²⁹ Red and Crystal;⁴³³ Keren and Celeste;²³³⁶ Apple’s frame pacing, RealityKit and haptics guidance;⁷⁸⁴⁶ the input references.⁴⁰⁴²⁴⁴

Two of those rules need a sentence each. The walk-cycle rule is the one that is easiest to get wrong in a modern engine, because an animation system counts its own seconds while a walk counts the world’s distance. The handhelds kept the two together by counting both in the same frames with lengths chosen to agree; on a phone, where the frame time varies, my proposal is to read the drawing from the distance walked, which gives the same result without a second clock to keep in step. And the frame-rate rule is not a lack of ambition. A world that moves one whole pixel per tick has nothing to show between ticks, so a faster display can only repeat the same picture, and section 6 shows that this is exactly what it does.

6. The Apple way: frame pacing, RealityKit’s clock, and haptics

The first post in this series set out the engine Kiradex’s world runs on: a RealityKit scene used as a 2D renderer, an orthographic camera, the ground as one mesh of textured quads, walkers as quads, and every sprite’s position rounded to whole world units each frame.²² This section is the part of Apple’s documentation that decides how that world moves in time. Every page below was read as Apple publishes it on October 4, 2026, and the availability given is the one each page states.

Frame pacing on ProMotion

CADisplayLink.preferredFrameRateRange (iOS 15.0, iPadOS 15.0, Mac Catalyst 15.0, visionOS 1.0) is a request, not a setting.¹⁵ The page’s advice is “Choose a frame rate range that your app can consistently maintain,” and it describes what the system does with the request: “The system typically provides a consistent frame rate by choosing one that’s a factor of the display’s maximum refresh rate.” By default the range equals the display’s maximum.¹⁵ The range itself is a CAFrameRateRange (iOS 15.0) of a minimum, a maximum and a preferred rate.⁴⁷

Apple’s article on ProMotion gives the numbers. ProMotion displays switch between 24 and 120 hertz on iPad Pro and between 10 and 120 on supported iPhones, and the iPhone’s rates are twelve steps: 120, 80, 60, 48, 40, 30, 24, 20, 16, 15, 12 and 10 hertz; the iPad Pro’s are five of them.⁷ The device list now names iPhone Air and “iPhone 17 and later” alongside “iPhone 13 Pro and later.”⁷ On iPhone, nothing above 60 happens unless the app’s Info.plist sets CADisableMinimumFrameDurationOnPhone (iOS 15.0) to true: “If you don’t enable this support, Core Animation won’t access higher frame rates (above 60Hz).”⁷¹⁶ Two sentences in the article matter more to a game than the rest. One: “In iOS 15 and later, the system provides games with special priority to 30Hz and 60Hz refresh rates to ensure optimal performance,” reached with CAFrameRateRange(minimum: 30, maximum: 60, preferred: 60).⁷ The other: “Prepare your app to operate at any refresh rate, not just those it requests.”⁷ And for anything that animates: “Always use targetTimestamp to drive any animation, physics, or other time-related content provided in your CADisplayLink callback” (targetTimestamp is iOS 10.0).⁷⁴⁸

The WWDC21 session “Optimize for variable refresh rate displays” covers both ProMotion on iPad Pro and Adaptive-Sync displays on the Mac.⁴⁹ For the Mac’s Adaptive-Sync displays it changes Apple’s earlier guidance: on a fixed-rate display, “we’ve previously recommended that you slow down your rendering to hit the next factor of the display’s fastest refresh rate”; on Adaptive-Sync, “You should instead attempt to present frames at the highest rate your app can do so evenly.”⁴⁹ The word I take from it for a phone is evenly.

RealityKit’s clock

Kiradex’s world does not own a display link. It ticks on RealityKit’s per-frame event, SceneEvents.Update (iOS 13.0), “An event invoked once per frame interval,” whose deltaTime is “The elapsed time since the last update.”⁵⁰⁵¹ RealityView (iOS 18.0) documents exactly that route for per-frame work, “you can use a System or directly subscribe to the engine’s SceneEvents.Update,” and offers no frame-rate setting of its own.⁵² Apple’s RealityKit performance article says what rate to expect: “RealityKit typically limits the refresh rate,” which it defines as the rate at which the framework renders updates for the screen, “to 60 frames per second (fps).”⁸ Whether RealityView on an iPhone 18 Pro Max or an iPhone Duo actually renders at 60 or 120 is not something I have measured, and section 7 makes that measurement the brief’s first check.

Why 120 hertz does nothing for a whole-pixel walk

Here is the arithmetic, from the same model script that section 7 uses for the app’s current code, applied to the proposal instead: a world that steps on a fixed 60-hertz tick, one pixel a tick, with the display showing whatever the latest tick produced. On a 60-hertz display, every world pixel is shown for exactly one refresh.⁶ On a 120-hertz display, over one second, 59 of the 61 positions are held for exactly two refreshes and two for one.⁶ On an 80-hertz display the holds alternate between one and two refreshes, 42 positions held once and 19 twice.⁶ On my reading, the 120-hertz case is the 60-hertz case drawn twice, and the 80-hertz case is uneven pacing: a pixel that sometimes stays for 12.5 milliseconds and sometimes for 25.

So the question for a grid world on an iPhone is not 120 hertz but even pacing at 60: a fixed 60-hertz simulation tick, integer moves per tick, animations counted in ticks, and the renderer showing the latest tick. That is also what makes the motion independent of whatever rate RealityKit picks. The WWDC21 session makes the related point about time deltas. When a slow frame makes the display link skip a callback, the delta to advance by is “not 8ms, but rather 16ms”; the session then says that an app which “uses time delta to advance the state of your custom drawing” will “slow down your custom drawing by one frame” every time a callback is skipped, which I read as an app that advances by the expected 8 milliseconds rather than the time actually elapsed, and it says you “can instead keep track of a previous targetTimestamp so that you can advance the state correctly.”⁴⁹

Haptics

Core Haptics (iOS 13.0, iPadOS 13.0, Mac Catalyst 13.0, visionOS 1.0) builds a CHHapticPattern, “An object representing a haptic waveform,” from dictionaries, from arrays of CHHapticEvent objects, or from an AHAP file.⁵³ Events are of two haptic types, hapticTransient and hapticContinuous; transient ones are “brief impulses that occur at a specific point in time.”⁵⁴ Each takes the parameters hapticIntensity, hapticSharpness, attackTime, decayTime, releaseTime and sustained.⁵⁵ A CHHapticEngine plays them, and capabilitiesForHardware() says whether the device can.⁵⁶

The simpler route is UIImpactFeedbackGenerator (iOS 10.0), “A concrete feedback generator subclass that creates haptics to simulate physical impacts,” whose styles describe “The mass of the objects in the collision” (light, medium, heavy, soft, rigid); impactOccurred(intensity:) is iOS 13.0, and the page lists init(style:view:) under “Initializing the feedback generator” and init(style:) under Deprecated.⁵⁷⁵⁸⁵⁹ prepare() lowers latency only with time to work: “Calling prepare() and then immediately triggering feedback (without any time in between) does not improve latency,” and the engine returns to idle after “A short period of time passes (typically seconds).”⁶⁰ In SwiftUI, sensoryFeedback(_:trigger:) (iOS 17.0) “Plays the specified feedback when the provided trigger value changes,” including .impact(weight:intensity:).⁶¹

The HIG’s page on playing haptics is the design half. “Avoid overusing haptics,”⁴⁶ with the reason: “Often, the best haptic experience is one that people may not be conscious of, but miss when it’s turned off.” “Make haptics optional.” Match “the intensity and sharpness of a haptic with the intensity and sharpness of the animation it accompanies.”⁴⁶ Sharpness can convey an experience “that’s soft, rounded, or organic, or one that’s crisp, precise, or mechanical.”⁴⁶ And custom haptics can make “a collision or a hit” feel very different “from subtle experiences like the approach of footsteps or a looming danger.”⁴⁶ A walk of 3.75 steps a second for minutes at a time is the case the first rule is about.¹

Input

The touch-control APIs are in section 4’s terms. Touch Controller (iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0, visionOS 26.0) is summed up on its page as “Integrate onscreen touch controls into your Metal-based games”: buttons, direction pads, thumbsticks, throttles and touchpads, surfaced through a GCController.⁶² Its TCDirectionPad (iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0) can be configured “to behave as either a composite direction pad” or “as four separate buttons.”⁶²⁶³ The older GCVirtualController (iOS 15.0) is “A software emulation of a real controller that you configure specifically for your game.”⁶⁴ One address I tried, developer.apple.com/documentation/touchcontrols, returned a 404; the framework’s page is touchcontroller.³⁹

What it costs

Nothing in this section has been timed on a phone. The world’s frame time on device, the cost of a 60-hertz accumulator, and the cost of a haptic engine kept running while the world is on screen are all unmeasured; the brief’s checks in section 7 are written to measure the first two.

7. The brief: what Kiradex builds and the checks it must pass

Where the walk stands today

I read the world’s walking, camera and transition code in the Kiradex repository on October 4, 2026, without changing it, and wrote a frame-by-frame model of it. Everything in this subsection is either read from that code or computed by the model, and it says which. The model does each of the code’s Float operations in 32 bits, in the code’s order, with Swift’s rounding, at an exact 1/60 or 1/120 of a second per frame, and leaves out the map’s edges, the fold of the iPhone Duo and the feet offset, none of which change a straight walk in the middle of the map. It is a model of the code. It is not a capture, and no phone has been measured.¹⁷⁶

What the code does, read from it:

• Input is tap to walk, and only that. The stage turns a tap into a world point, then taps a collector, the kiosk, or calls walk(to:). There is no drag, no d-pad, and no haptic call anywhere in the app’s target: a search for UIImpactFeedbackGenerator, sensoryFeedback and CHHaptic finds nothing.¹⁷
• The path is an eight-way shortest-path search, ordered by the cost walked so far with no estimate of the distance left, which makes it Dijkstra’s search rather than A*; diagonals cost √2 and never cut a wall’s corner. A diagonal step faces sideways and divides its progress by √2 after the run’s 1.6 is applied, so in the model a diagonal step takes 22 frames walking and 14 running at 60 hertz, against 15 and 10 for a straight one.¹⁷⁶
• Speed is time. tilesPerSecond is 4, which is 64 pixels a second, and the walk becomes a run at 1.6 times that when the path is 6 steps or more, so a walk in the app is 1 to 5 tiles and anything longer is run. Each frame adds dt × speed / length to a step’s progress, and when progress reaches 1 the walker snaps to the next tile and progress goes back to 0, discarding the overshoot.¹⁷
• The walk drawing is chosen by time. The column is cycle[Int(walker.clock * framesPerSecond) % count], with framesPerSecond 8 and the forge’s six-drawing walk and run cycles. This series’ characters post reported the same cadence, “the walk at eight frames a second,” and that describes the code accurately.¹⁷³⁵
• The camera eases, then rounds. Each frame it moves (target - current) * min(1, dt * 6) toward the player and then rounds both axes to whole units; it is clamped to the map when the map is larger than the view. The first post’s sentence, that every sprite and the camera “are rounded to whole world units each frame, after easing,” is also accurate.¹⁷²²
• Doors and warps. The door shows the sheet’s half-open drawing at once and the open one after 70 milliseconds, and removes the door 1.4 seconds later; the step onto the warp waits 220 milliseconds and then changes place. The structures post described this as a known gap.¹⁷¹³
• Transitions are navigation pushes with their default animation; a floor change swaps the stage by identity with no fade; leaving calls dismiss(). The only veil in the app is the card viewer’s black overlay, animated with .easeOut(duration: 0.25).¹⁷
• No frame-rate request. No CADisplayLink, preferredFrameRateRange or CADisableMinimumFrameDurationOnPhone in the app or its project file; the world ticks on SceneEvents.Update with the event’s deltaTime.¹⁷

What the model says that code does on screen, at a steady frame time:

• A two-pixel hitch once a tile at 60 hertz. At 60 hertz a walk takes 15 frames a tile, 4.00 tiles a second, and each tile’s 16 pixels come as 14 frames of 1 pixel and one frame of 2: one 2-pixel jump per tile, five in a five-tile walk. Emerald moves exactly 1 pixel on every frame.⁶¹
• Irregular 0s and 1s at 120 hertz. At 120 hertz the walk takes 30 frames a tile and each tile’s 16 pixels come as 16 frames of 1 pixel and 14 of none, irregularly interleaved.⁶
• The run is slower than its constant. At 60 hertz the run takes 10 frames a tile, 6.00 tiles a second, where 4 times 1.6 would be 6.4, because each tile’s overshoot is thrown away; each tile’s 16 pixels come as 4 frames of 1 pixel and 6 of 2. At 120 hertz it takes 19 frames a tile, 6.32 tiles a second, so the run’s speed depends on the frame rate.⁶
• A trailing camera that never arrives. While walking at 60 hertz the camera falls about a pixel further behind with each tile, from 5 pixels at the end of the first tile to 9 at the end of the fifth, the longest walk the app makes, and the player’s position on screen changes on 8 of the walk’s 73 frames after the first. On a run, which is every path of 6 tiles or more, it trails by 13 from the second tile on. At 120 hertz it reaches 9 within the first tile, walking or running, and then holds. When the player stops, the camera comes to rest 4 pixels off the player at 60 hertz and 9 at 120, and stays there: once the gap times min(1, dt × 6) is under half a pixel, rounding returns the same position every frame. Which side it rests on depends on the direction of the last walk. Emerald’s trail and rest offset are both zero.⁶
• The drawings keep their own clock. The six-drawing cycle at 8 a second lasts 0.75 seconds. Measured from the model’s positions between the starts of successive cycles at 60 hertz, it covers 3.00 tiles walking and 4.50 running (4.80 at the run’s nominal 6.4 tiles a second, which the dropped overshoot never lets it reach); Emerald’s cycle of two footfalls covers 2.00 tiles. On my reading, a cycle that covers half again as much ground as its footfalls shows as feet sliding, but the model does not measure where a foot sits on the ground. The drawing also sits on a knife edge every 15th frame, at 60 and at 120 hertz, where the clock times 8 lands exactly on a whole number, the boundary between two drawings: keeping the clock in 32 bits, as the app does, rather than 64 changes which drawing shows on 9 of the 11 such frames in 12 tiles of walking at 60 hertz and 14 of 23 at 120.⁶
• A second tap mid-step snaps the walker back. This one is read from the code, not modeled or captured: walk(to:) sets the progress to 0 while the walker’s tile is still the step’s origin, so the next frame draws the walker up to 15 pixels behind where it was; other collectors’ moves from the server do the same.¹⁷

Pixels per displayed frame: the canon is even, today’s code (a model, not a capture) is not, and a fixed tick is even at 120 too.⁶²¹

The eased, rounded camera, as modeled: it trails while walking or running and stops short when the walk ends.⁶²¹

None of this is a judgment on how it feels in the hand, because no phone has been measured. Real frame times jitter, which will change the exact pattern of 1s and 2s. The trail and the resting offset depend on the frame time too, because the easing step min(1, dt × 6) does, which is why the model gives 4 pixels at rest at 60 hertz and 9 at 120. On my reading, jitter within the range a phone normally shows will change their size, not remove them; the condition is that frames stay shorter than 1/6 of a second, about 167 milliseconds, because at that length the easing factor reaches 1 and the camera lands on the player in one frame, so a long enough hitch closes the gap on that frame.¹⁷⁶ The mismatch between the drawings and the walk does not depend on the frame rate: a drawing clock of 8 a second against a walk of 4 tiles a second gives 3.00 tiles a cycle at 60 hertz and about the same at 120. The run’s does, 4.50 tiles a cycle at 60 hertz and 4.75 at 120, because the overshoot it drops at each tile does.⁶

The brief

Each item is a change to Kiradex/World/, the reason for it, and a check that a log line, a script or a capture can verify. No asset, name or sound from any of the games is proposed: the numbers are mechanics, and the art, sounds and words are Kiradex’s own.

1. Walk on a tick, not a clock.

Change. Add a 60-hertz accumulator to the rig’s update. Each callback adds its dt; if the accumulator then holds more than 8 ticks of time (133 milliseconds), the excess is dropped and written to the motion log as a dropped line with its milliseconds; then every whole tick in the accumulator runs, each subtracting one tick. The accumulator counts time in whole integer units (nanoseconds, or the model’s 1/60,000,000 of a second), never in a floating-point second: with a Double or Float accumulator the 600th tick of a ten-second test lands one rounding short of its boundary at some rates and the count comes out 599. That is the backlog rule: up to 8 ticks of lateness is made up on the next callback, and anything beyond is treated as a suspension, so the world resumes where it stopped rather than racing to catch up. Eight is chosen to cover every rate on Apple’s list for ProMotion iPhones, down to 10 hertz, which needs 6 ticks a callback.⁷ In the model, ten seconds of callbacks at each of the twelve rates runs exactly 600 ticks and drops nothing, where a cap of 4 ticks a callback would run 480 at 12 hertz and 400 at 10.⁶ After a one-second hitch at 60 hertz, the rule runs 8 ticks on the next callback and 1 on each after it, and logs 866.7 milliseconds dropped; the same hitch with the backlog kept under a cap of 4 runs 4 ticks on 19 callbacks in a row, the fast-forward the rule exists to prevent.⁶ Each walker keeps a step tick count instead of a fractional progress, and its drawn offset is that count times its pixels per tick: exact integers, so walkers no longer need rounding. The walk is 1 pixel a tick, 16 ticks a tile; the run is 2 pixels a tick, 8 ticks, keeping today’s rule that a path of 6 steps or more is a run. Diagonal steps, which the path search allows, keep the √2 the code already intends and its order, the run’s pace applied before the division by √2: a walking diagonal takes 23 ticks (16√2 is about 22.6, rounded up) and a running diagonal 12 (8√2 is about 11.3, rounded up), each moving 16 pixels on each axis on the ticks where floor(16 × t / 23) or floor(16 × t / 12) changes.¹⁷ Walking, that is 1 pixel on 16 of the 23 ticks and none on the other 7; running, 1 pixel on 8 of the 12 ticks and 2 on 4, the one uneven gait in the brief, as the Acro Bike’s is the one uneven gait in Emerald.¹ There is no overshoot to discard.

Why. The rules for walk and run in section 5; and the model’s 2-pixel hitch per tile at 60 hertz and irregular 0s and 1s at 120.⁶¹

Checks. A -motionLog launch argument logs the tick and the player’s x, y on every tick, and every dropped line. On the existing facing demo, which walks one tile each way, a script asserts that every walking tick moves exactly 1 pixel, each tile takes 16 ticks, and no tick moves 2. A diagonal demo, one walking and one running diagonal step each way, asserts 23 ticks and 12, 16 pixels on each axis per step, per-axis moves of 0 or 1 pixel walking and 1 or 2 running, and a running diagonal faster than a walking one. Unit tests feed the accumulator made-up dt sequences as exact integer units: ten seconds at each of the twelve iPhone rates from 120 down to 10 hertz runs 600 ticks with nothing dropped, and a one-second gap at 60 hertz runs 8 ticks on the next callback, then 1 a callback, with 866.7 milliseconds logged as dropped. The same motion log on an iPhone 18 Pro Max and on the inner display of an iPhone Duo gives the same ticks per tile: the display’s rate must not change the walk.

2. Choose the walk drawing by distance.

Change. This item is my proposal, not a copy: Emerald times its drawings in frames, matched to its steps, and does not read them from distance.⁹² While walking, choose the column from the walk’s progress counted in steps, the steps completed since the walk began plus the current step’s ticks over its length: walkCycle[floor(steps × walkCycle.count / 2) % walkCycle.count], two footfalls per two steps, and the same for the run. On a straight step that is the distance walked over 32 pixels, floor(distancePx × 6 / 32) mod 6. On a diagonal it counts the step rather than its √2 length, so a footfall still lands at the start of every step with a longer stride, my choice for drawings made for straight strides. Show the standing drawing when the walk ends, as Emerald does. Keep the idle, blink and emote clocks as they are. A tick-timed cycle could match the steps too, as Emerald’s does, but six drawings over 32 ticks would need uneven holds of 5 and 6 ticks; counting progress needs no second table and holds for any gait the app adds.

Why. One footfall per 16 pixels at every speed, and a cadence that cannot drift away from the movement; today’s cycle covers 3.00 tiles walking and 4.50 running in the model.¹⁶ This also settles the characters post’s “eight frames a second”: at 1 pixel a tick, six drawings over 32 pixels change every 5.33 pixels, which is 11.25 drawings a second, not 8.³⁵

Check. From the motion log plus the column shown: the two contact drawings (walk_a and walk_d in the forge’s cycle) appear at 0 and 16 pixels, give or take one, of every 32, at 60 and at 120 hertz; on the diagonal demo they appear on the first tick of each step.

3. Finish the step; keep the tap; add a floating stick.

Change. A tap mid-step plans from the tile being walked to, not from the origin, and the current step finishes first; the step count is never reset. Other collectors’ server moves get the same rule. From standing, a tap whose first step changes facing turns for 8 ticks before moving. A tap on a blocked cell next to the player, or on the tile in front of one, turns to face it and plays a 32-tick bump with the refusal haptic of item 6. Holding a finger down follows it, as Stardew’s default does, but routed by the existing path search each time the finger crosses a tile, since Stardew’s follow does not route around obstacles and ours can. A floating thumbstick, four-way, off by default, appears where the thumb lands, built on a SwiftUI drag gesture over the world; anything drawn is at least 44 by 44 points. Touch Controller’s thumbstick (iOS 26) replaces the drag only if a test build shows it drawing over the RealityView: Apple describes the framework as for “Metal-based games,” its WWDC25 session says it “integrates directly with Metal,” and Kiradex’s world is drawn by RealityView with no render pass of its own.⁴⁵⁶²

Why. The step, turn, refused-step and input rules of section 5.^14044624517

Checks. A UI test taps a tile 6 east, then 120 milliseconds later a tile 6 north; the motion log shows no tick on which the player’s x decreases, and the first step’s tile is completed before the turn. A UI test taps the wall beside the house; the log shows a facing change and a 32-tick bump and no change of position. With the stick on, a drag held right for 60 ticks from the first tick of movement completes three tiles by tick 48, starts a fourth while the stick is still held, and finishes it on tick 64 after the release: the log shows the player 4 tiles east, on a whole tile, with the step in progress at the release completed and no stop between tiles.

4. Lock the camera.

Change. Replace the easing with a camera set in the same tick as the player moves, from whole world pixels only: camera = clamp(player + foldOffset, low, high). Each term is kept whole, because today only the final rounding makes the camera whole: the bounds and the fold offset are fractional. The player’s position is whole by item 1. The fold offset, which follow computes in points times displayScale / pixelScale, is rounded to whole world pixels once, when the fold changes. The clamp’s bounds are rounded inward, the lower up and the upper down, because the view’s half-size in world pixels need not be whole: fit divides the view’s screen pixels by a whole number of screen pixels a texel, so an illustrative 393-by-852-point view at 3x gets 7, a view 168.43 world pixels wide and a half-width of 84.21, and the camera’s bounds become 85 and the map’s width minus 85, so no frame shows past the map’s edge.¹⁷⁶ When the map is smaller than the view the bounds swap, as today’s clamp allows, and the same inward rounding keeps the whole map in view. Keep the clamp to the map; the section 5 rule allows clamping or drawing the outside, and Kiradex’s camera goes past the map’s edge into the woods only when the Duo is half open, by a margin of whole tiles.¹⁷ Treat the fold offset as fixed until the fold changes; when it changes from a to b, step it through a + round((b − a) × i / 8) for i from 0 to 8, one level every 2 ticks, the fade’s cadence, so every position on the way is a whole pixel; a change from 0 to minus 37, for example, passes 0, −5, −9, −14, −19, −23, −28, −32 and −37.⁶ Keep the woods’ parallax, computed from the locked camera and rounded as today. No look-ahead toward the tapped destination: Game Freak built one and left it off, and a tap-to-walk destination is already on screen.¹²

Why. The camera rule of section 5, and the model’s trail, which grows through a walk to 9 pixels by its fifth tile and is 13 on a run, its changes of the player’s place on the screen, and its 4 and 9 pixel resting offsets.⁶

Checks. From the motion log, the camera minus the player is constant on every tick of a walk in the open plaza (zero, or the fold offset) and the same after the player stops, and every camera value is a whole number. A unit test calls fit with the 393-by-852-point view at 3x, walks the player to both edges of a map, and asserts whole camera positions that stop at 85 and at the map’s width minus 85; the same test then changes the fold and asserts that the camera reaches the new offset through 9 whole-pixel positions, 2 ticks apart, and that no tick in between leaves the bounds. For a capture, the walk drawings will not do as a marker, because the feet change shape from drawing to drawing; a debug build draws a one-texel marker, in a color used nowhere else, at the player entity’s position, and a script finds it in every frame of a 6-tile walk in the open plaza: the same screen pixel in every frame. Near the map’s edge the marker moves and the camera does not, by whole pixels only.

5. The door, the step and the fade, in Kiradex’s own art.

Change. Entering a door, which is a warp with a door sheet. Today the door opens after the walker has landed on the door cell: the step’s onStep finds the warp at that tile and calls openDoor there.¹⁷ Emerald never lets the player stand in a closed door: TryDoorWarp fires only when the player, on the cell below, pushes north into a door, and Task_DoDoorWarp opens the door one cell up and then forces the step onto it.⁶⁵²⁵ The brief moves the trigger back one cell to match:

1. When the path’s next step is onto a door warp, the walk stops on the cell before it, and the entry starts there, on tick 0. Freeze input and play the door’s sound, a Kiradex sound.
2. Open the door in four slots of 5 ticks, Emerald’s four drawings at its five frames each (83 milliseconds a slot at 60 ticks a second, where Emerald’s five frames are 84; 20 ticks in all), in place of today’s half-open drawing at once and open at 70 milliseconds: closed, half, open, open. Kiradex’s door sheet has three drawings, closed, half open and open (the forge’s door_sheet() draws three, and the app loads it with SpriteSheet.bundled(name, columns: 3, rows: 1)), where Emerald’s door is closed plus three, so the open drawing holds through the fourth slot. A fourth drawing from the forge, between half and open, would fill that slot instead; it is optional art, not a requirement. Fix the comment that says “four ticks.”²⁴¹⁷
3. Walk the player one forced step from that cell onto the door cell, 16 ticks. The town’s doors sit in a building’s bottom row with the building’s cells on both sides and above, and the path never cuts a wall’s corner, so this step is always up from the cell below, as Emerald’s is.¹⁷
4. Hide the walker and close the door, the slots backwards (open, open, half, closed), 20 ticks.
5. Fade a black veil over the world in 9 stepped opacity levels (0, 2/16 and so on to 16/16), level i on the fade’s tick 2i, so the last level lands on tick 16 and holds through tick 17: 18 ticks. That is an adaptation, chosen, not Emerald’s timing. Emerald’s sprite palettes reach each level on the same even frames as this veil, its background palettes a frame earlier, and after the last blend on frame 16 it runs five finishing updates before going inactive on frame 21; one veil has no second layer to lag and nothing to finish.⁵ Never animate the opacity of the view that holds the RealityView itself; the card viewer taught the first post that lesson.²²
6. Push the destination with animations disabled, and fade the veil back out in the same 9 levels.
7. Arrive on the inside mat facing up. Leaving reverses it: arrive on the door cell with the door open, a forced step down of 16 ticks, the door closes, then input.

Floors, which today swap the stage with no fade, take the same veil with no door and no forced step. Leaving a room, which today calls dismiss(), takes the veil and the forced step out.

Why. The door, fade and ceremony rules of section 5; today the place changes 220 milliseconds after the step, the door shows two drawings 70 milliseconds apart, and the screen slides sideways.¹⁵¹⁷

Checks. The motion log counts ticks from the one on which the walk stops below the door. It shows the player still on that cell, and the door’s slots at ticks 0, 5, 10 and 15 (closed, half, open, open); the forced step on ticks 20 to 35, 1 pixel a tick, reaching the door cell on tick 35 and never before; the closing slots at ticks 36, 41, 46 and 51; the veil’s first level at tick 56; and the push no earlier than tick 74. A walk that ends on a door cell without this sequence fails the check. The motion log also records the veil’s opacity on every tick: 9 distinct values, each held 2 ticks, on ticks 56 to 73 on the way out, and the same 9 on the way in. A screen recording confirms it on a part of the picture that holds still: the whole frame will not do, because the ground’s water, on a map that has it, changes drawing 4 times a second and other collectors may walk, so a script samples a patch of building wall chosen in advance, with no animated tile and no walker over it in the recording, and counts 9 distinct levels on the way out and 9 on the way in, each held 2 frames, give or take one at 60 hertz.¹⁷ In a screen recording of a warp, the world never translates horizontally: no navigation slide.

6. Haptics: three events, and a switch.

Change. One CHHapticEngine owned by the world, started when it appears and stopped when it disappears, with a Haptics switch in settings that is on by default and respects the system’s haptics setting. The patterns, kept as AHAP files in the bundle:

The intensity and sharpness values are my starting points, not measurements, and they are for tuning on a device. UIImpactFeedbackGenerator(style: .soft, view:), with prepare() called when a walk starts, is the fallback where capabilitiesForHardware() says Core Haptics is unavailable.

Why. The haptics rule; Apple’s guidance quoted in section 6.^46565760

Check. A -hapticLog argument logs each event. A scripted door entry logs exactly 2 door events, at ticks 5 and 10 of item 5’s count, and none per step; with the switch off, none at all.

7. Frame rate: 60, evenly.

Change. None to the Info.plist: do not add CADisableMinimumFrameDurationOnPhone, because the world gains nothing from 120. Keep the RealityView; the tick of item 1 makes the motion independent of whatever rate it renders at. If a display link is ever added, set CAFrameRateRange(minimum: 30, maximum: 60, preferred: 60) for Apple’s game priority.⁷⁶

Checks. Log a histogram of SceneEvents.Update.deltaTime over a 60-second walk on an iPhone 18 Pro Max and on an iPhone Duo, outer and inner displays. The brief assumes the mode is 16.7 milliseconds; if it is 8.3, item 1’s accumulator still holds the walk at 16 ticks a tile, and the log proves it. The motion log’s dropped lines: none in a normal walk, at either rate.

8. Shake, for one moment only.

Change. A camera shake of whole texels, 1 texel, 8 flips, 5 ticks apart, used for one event that earns it, for example a rare card’s reveal in the plaza, with the card-raised haptic. Not for doors, steps or arrivals.

Why. The commonest of Emerald’s 24 shakes, and their restraint.²⁹

Check. The motion log shows the camera offset alternating plus and minus 1 texel at ticks 0, 5 and so on to 35, and back to 0 at tick 40.

Not in this brief

• Camera smoothing or look-ahead on the grid. There are no jumps to smooth, and Game Freak shipped its look-ahead switched off.¹²²³
• 120 hertz for the world. Even pacing at 60 is the goal; 120 shows each pixel twice.⁶
• Haptics per step by default.⁴⁶
• A fixed on-screen d-pad. My recommendation is tap to walk plus an optional floating stick.⁴⁴
• Any of the games’ door or warp sounds or jingles. Sounds are expression, and Kiradex needs its own.
• Bikes, surfing, ice and currents. The app’s walkers walk and run and nothing else, and the speeds above are recorded for when that changes.¹⁷

The open question: timing on a device

Every model number in this section assumes a steady 1/60 or 1/120 of a second between frames. Whether RealityView on an iPhone 18 Pro Max or an iPhone Duo renders at 60 or 120, and how much its deltaTime jitters, is unmeasured; item 7’s histogram is the first thing to run, and item 1 is written so that the answer changes nothing about the walk at any rate on Apple’s iPhone list.⁶⁸⁷

Key Takeaways

If you draw the art

• Draw the walk for a distance. Emerald’s walk is two strides and two stands over 32 pixels, held in frames that match its steps, and faster gaits reuse the drawings with shorter holds rather than adding frames, so one footfall lands per 16 pixels at every speed.¹⁹²
• A six-drawing cycle is fine, provided the engine plays it over a fixed distance; played at a fixed rate against a walk timed separately, its cadence drifts from the movement, 3.00 tiles a cycle walking and 4.50 running in the model of ours.⁶
• Emerald’s door is closed plus three drawings, each on screen for 84 milliseconds. A sheet of three, closed, half and open, as Kiradex’s is, fills the four slots by holding the open drawing for two of them, or the forge draws a fourth; either way, draw the open state as something worth seeing.¹²⁴¹⁷

If you build the engine

• Step the world on a fixed tick with whole-pixel moves that divide the tile, read input at the tile, and let the renderer show the latest tick. Say what happens to a backlog: ours makes up to 8 ticks and drops the rest, logged. Emerald’s step tables are the model: every one sums to 16.²¹⁶
• Lock the camera to the player in the same tick, with whole-pixel bounds and offsets, so nothing needs rounding afterward. Easing then rounding trails a walking player and, in the model of our code, stops 4 to 9 pixels short until the next walk.³⁶
• On iPhone, do not ask for 120 hertz for pixel motion. Apple prioritizes 30 and 60 for games, RealityKit typically renders at 60, and a whole-pixel walk at 120 only holds each pixel for two refreshes.⁷⁸⁶
• Fade in steps, not a smooth ramp. Emerald’s door fade is nine levels two sixteenths apart, its last blend on the 17th frame and the fade finished on the 22nd; our 18-tick veil is an adaptation of that ramp, not a copy.⁵
• Never animate the opacity of the SwiftUI view that holds a RealityView; put a veil over it.²²

If you design the loop

• A door entry is a ceremony of at least 1.32 seconds in Emerald with no input, and the forced step over the threshold is what makes it read as walking in.⁵²⁵
• Turning in place for 8 frames lets a player face something without moving; a 32-frame bump tells them a step was refused.¹
• On a phone, my recommendation: tap to walk as the default, as Stardew’s mobile version ships it, a floating stick as the precision fallback, as the HIG advises, and no fixed d-pad.⁴⁰⁴⁴
• Haptics confirm events, not footsteps, and come with a switch.⁴⁶

FAQ

How fast does the player walk in Pokémon?

In Red, Crystal and Emerald, a walking step covers one 16-pixel cell in 16 frames at 59.7275 frames a second: 268 milliseconds a cell, 3.73 cells a second. Emerald moves 1 pixel every frame; Red and Crystal move 2 pixels every second frame. Running and surfing in Emerald, and the bikes in Red and Crystal, take 8 frames a cell, 7.47 cells a second.¹⁴¹⁹

How many frames is a walk cycle in Pokémon Emerald?

Four entries over 32 frames: a stride drawing for 8 frames, the standing drawing for 8, the other stride for 8, standing for 8. That is two cells of walking, so each step shows one stride and one stand, and the legs alternate step by step. The run is a 16-frame cycle over two 8-frame cells.¹⁹²

Does the camera in Pokémon Emerald lag behind the player?

No. Emerald’s camera copies the player’s position and scrolls the map by the same pixels on the same frame, so the player stays fixed on screen while the world moves. It does not stop at a map’s edge either: the outside is drawn from the layout’s border tiles. A look-ahead camera for the bike exists in the code but is never switched on.²³¹¹¹²

How long is the door and fade transition in Pokémon Emerald?

The door opens in four drawings of five frames (335 milliseconds), the player takes one forced 16-frame step in, the door closes in 20 frames, and the screen fades in nine levels, the last blend on the fade’s 17th frame and the fade finished on its 22nd: at least 79 frames, 1.32 seconds, before the next map can begin to load. Going into a cave, the screen fades out to white instead of black, and coming out of one, it fades back in from white.¹⁵²⁵²⁷

Should a pixel-art game run at 120 Hz on a ProMotion iPhone?

Not for whole-pixel motion. A world that moves one pixel per 60-hertz tick only shows each pixel for two refreshes at 120 hertz, and uneven holds at 80. Apple’s ProMotion article says games get “special priority to 30Hz and 60Hz,” an iPhone app must set CADisableMinimumFrameDurationOnPhone to go above 60, and RealityKit typically renders at 60. Simulate on a fixed 60-hertz tick and let the display be whatever it is.⁶⁷¹⁶⁸

Why do my sprite’s feet slide when it walks?

Usually because the walk drawings run on one clock and the movement on another, with lengths that do not agree. Kiradex’s current code plays a six-drawing cycle at 8 drawings a second while walking 4 tiles a second, so one cycle covers 3 tiles instead of 2, as a model of the code shows. The handhelds count both in frames and make each step’s drawings last as long as the step; choosing the drawing from the distance walked, which is what I propose for Kiradex, gets the same agreement without a second clock. Either way the cadence cannot drift away from the movement; whether a foot stays planted also depends on the drawings themselves.⁶¹⁹

Should a mobile pixel game use a virtual d-pad?

Not as the default, on my reading of the sources. Stardew Valley’s mobile default is tap to move, with an invisible joystick among its other schemes for precise tasks; Apple’s HIG recommends tapping objects directly and a thumbstick that appears “wherever the player lands their thumb instead of a static thumbstick position.”⁴⁰⁴⁴

Related on this site: Pixel-Art Worlds on iPhone is the first guide in this series, with Emerald’s step-and-stand walk, the RealityKit recipe this world runs on and the card viewer’s opacity lesson; Pixel-Art People: Characters and a Creator on iPhone is the second, with the six-drawing walk whose timing this post moves from a clock to a distance; Pixel-Art Structures: Houses, Halls and Interiors on iPhone is the third, with the doors, warps and floors whose timing section 2 measures; iPhone Duo for Developers and Prepare Your App for iPhone Duo cover the two displays and the fold the brief’s camera keeps clear of; RealityKit’s Spatial Mental Model explains the entity and system model behind SceneEvents.Update.

Sources