Walk around the overworld (the trees make it easy to see).
Actual
The screen flickers whenever the player moves. It is most visible on the trees.
Expected (original game)
Stable graphics while walking. Trees and other background tiles do not flicker.
Still to confirm (not known yet)
Which map(s): New Bark Town, Route 29, Cherrygrove, or all of them.
Browser and version, the monitor's refresh rate, and whether the browser window is scaled or zoomed.
Whether it also happens in other browsers.
A short screen recording would help; none is attached yet.
Notes
Rendering issue seen by the QA tester; cause not investigated.
Likely front end (canvas drawing and scaling), assignment left open.
**Reported by QA (PestoRosso)**
**Steps**
1. `npm run dev`, load the ROM.
2. Walk around the overworld (the trees make it easy to see).
**Actual**
The screen flickers whenever the player moves. It is most visible on the trees.
**Expected (original game)**
Stable graphics while walking. Trees and other background tiles do not flicker.
**Still to confirm (not known yet)**
- Which map(s): New Bark Town, Route 29, Cherrygrove, or all of them.
- Browser and version, the monitor's refresh rate, and whether the browser window is scaled or zoomed.
- Whether it also happens in other browsers.
- A short screen recording would help; none is attached yet.
**Notes**
- Rendering issue seen by the QA tester; cause not investigated.
- Likely front end (canvas drawing and scaling), assignment left open.
Investigation notes (no code changed). Tested in headless Chromium with the local ROM, walking right in New Bark Town (the pokedex fixture world), at 1280x900, 1440x900 and 1920x1080:
The drawn frames are stable. Compared consecutive frames after aligning the scroll (2 px per tick): the only differences are the walking sprites, the animated water, and the strip of newly revealed tiles. The trees and other static tiles do not change between frames.
The canvas is not resized while walking. The drawing buffer is set once at start (for example 326x213 at 1280x900) and never reassigned, so there is no cleared frame.
Scaling is nearly integer. The canvas is displayed at 3.00 to 3.005 times the buffer size, so at most one source row or column is drawn one pixel larger.
So the flicker is not in what the game draws. It is probably in how the browser presents it. The screenshots show Firefox on a retina Mac, and I could not test that here.
To narrow it down, still needed from the tester: which maps, whether it also happens in Chrome or Safari, the browser zoom level, and a short screen recording.
Ideas to try if it is browser-specific: size the canvas to an exact multiple of its buffer, avoid per-tick DOM updates (position text and aria-label change on every step), or draw through a different canvas path.
Investigation notes (no code changed). Tested in headless Chromium with the local ROM, walking right in New Bark Town (the pokedex fixture world), at 1280x900, 1440x900 and 1920x1080:
- **The drawn frames are stable.** Compared consecutive frames after aligning the scroll (2 px per tick): the only differences are the walking sprites, the animated water, and the strip of newly revealed tiles. The trees and other static tiles do not change between frames.
- **The canvas is not resized while walking.** The drawing buffer is set once at start (for example 326x213 at 1280x900) and never reassigned, so there is no cleared frame.
- **Scaling is nearly integer.** The canvas is displayed at 3.00 to 3.005 times the buffer size, so at most one source row or column is drawn one pixel larger.
So the flicker is not in what the game draws. It is probably in how the browser presents it. The screenshots show Firefox on a retina Mac, and I could not test that here.
To narrow it down, still needed from the tester: which maps, whether it also happens in Chrome or Safari, the browser zoom level, and a short screen recording.
Ideas to try if it is browser-specific: size the canvas to an exact multiple of its buffer, avoid per-tick DOM updates (position text and aria-label change on every step), or draw through a different canvas path.
Analysis of the QA recording (Screen Recording 2026-10-04 at 19.16.14.mov, New Bark Town at night, 2700x1752, about 31 frames per second). No code changed.
The picture is stable between frames. Aligning each frame to the next by the scroll (12 device pixels, which is 2 game pixels), only 0.0 to 0.2% of the tree area differs. Brightness does not change either (mean 56 to 66 on every frame). Only the walking sprite differs.
The minimap overlay does not flash. Its brightness is constant across the whole clip.
The recording cannot show a 60 Hz effect. Frames arrive every 33.3 ms (30 fps), while the game steps its scroll every 33.5 ms (29.86 ticks a second) on a display refreshing at up to 120 Hz.
A likely cause, not yet proven: the trees are drawn with a fine 1-pixel dither, and the view jumps 2 game pixels per tick. A 2-pixel jump on a 1-pixel dither can make it strobe, which would read as flicker. A real Game Boy Color screen blends successive frames (LCD ghosting), which hides that.
Next step for the tester: walk beside trees in the reference emulator (/reference.html) and compare. If the original also strobes, the app is faithful and the fix would be an optional frame blend. If the original does not, the difference is in our rendering and needs deeper investigation.
Analysis of the QA recording (`Screen Recording 2026-10-04 at 19.16.14.mov`, New Bark Town at night, 2700x1752, about 31 frames per second). No code changed.
- **The picture is stable between frames.** Aligning each frame to the next by the scroll (12 device pixels, which is 2 game pixels), only 0.0 to 0.2% of the tree area differs. Brightness does not change either (mean 56 to 66 on every frame). Only the walking sprite differs.
- **The minimap overlay does not flash.** Its brightness is constant across the whole clip.
- **The recording cannot show a 60 Hz effect.** Frames arrive every 33.3 ms (30 fps), while the game steps its scroll every 33.5 ms (29.86 ticks a second) on a display refreshing at up to 120 Hz.
A likely cause, not yet proven: the trees are drawn with a fine 1-pixel dither, and the view jumps 2 game pixels per tick. A 2-pixel jump on a 1-pixel dither can make it strobe, which would read as flicker. A real Game Boy Color screen blends successive frames (LCD ghosting), which hides that.
Next step for the tester: walk beside trees in the reference emulator (`/reference.html`) and compare. If the original also strobes, the app is faithful and the fix would be an optional frame blend. If the original does not, the difference is in our rendering and needs deeper investigation.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Reported by QA (PestoRosso)
Steps
npm run dev, load the ROM.Actual
The screen flickers whenever the player moves. It is most visible on the trees.
Expected (original game)
Stable graphics while walking. Trees and other background tiles do not flicker.
Still to confirm (not known yet)
Notes
Investigation notes (no code changed). Tested in headless Chromium with the local ROM, walking right in New Bark Town (the pokedex fixture world), at 1280x900, 1440x900 and 1920x1080:
So the flicker is not in what the game draws. It is probably in how the browser presents it. The screenshots show Firefox on a retina Mac, and I could not test that here.
To narrow it down, still needed from the tester: which maps, whether it also happens in Chrome or Safari, the browser zoom level, and a short screen recording.
Ideas to try if it is browser-specific: size the canvas to an exact multiple of its buffer, avoid per-tick DOM updates (position text and aria-label change on every step), or draw through a different canvas path.
Analysis of the QA recording (
Screen Recording 2026-10-04 at 19.16.14.mov, New Bark Town at night, 2700x1752, about 31 frames per second). No code changed.A likely cause, not yet proven: the trees are drawn with a fine 1-pixel dither, and the view jumps 2 game pixels per tick. A 2-pixel jump on a 1-pixel dither can make it strobe, which would read as flicker. A real Game Boy Color screen blends successive frames (LCD ghosting), which hides that.
Next step for the tester: walk beside trees in the reference emulator (
/reference.html) and compare. If the original also strobes, the app is faithful and the fix would be an optional frame blend. If the original does not, the difference is in our rendering and needs deeper investigation.