This is something I often notice whenever I see a first-generation Pokémon game being played on a Game Boy emulator. It might be present on real hardware as well, but I don’t have that to test.

When the player moves around so that the map has to scroll, and there are also NPC sprites present on the map, the other sprites tend to lag a few pixels behind the scrolling motion; it takes a couple more frames for the sprites to move into their correct position. Here’s a demonstration in Pokémon Yellow, recorded in mGBA:

The player character walks horizontally, then vertically on the ground floor of his house in Pallet Town. An NPC sprite is noticeably lagging behind.

And here’s Pokémon Crystal for comparison (targetting the Game Boy Color), where there is no such effect:

The player character walks horizontally, then vertically on the ground floor of his house in New Bark Town. There are two NPC sprites, but no lagging.

I have a number of hypotheses why this might happen:

  • This is an inaccuracy in the emulator. Given that I remember seeing this in probably every emulator in which I tried, I regard this explanation as rather improbable.
  • This is a limitation of Game Boy’s hardware sprite support, which emulators dutifully replicate, and it was fixed in Game Boy Color.
  • This is a bug in the scrolling subroutine, fixed in Generation II games, and in principle it should be possible to backport the fix; the issue just wasn’t considered significant at the time.
  • This is a deliberately inserted artefact meant to compensate for LCD ghosting or a similar effect, which was rendered unnecessary in Generation II thanks to Game Boy Color’s improved display.

Which one of these is the closest to truth?


Well, there's a fifth one: A sequence issue not really considered relevant when first published.

The underlaying issue is that sprites are not moved during scrolling the background, prior to (re)drawing the screen. While this is rather obvious with large sharp screens, it will be perceived less of an issue on original Game Boy hardware due the small screen and it's less than great display quality with moving images.

Sprites are positioned in screen coordinates, not relative to a background. Thus, sprites that should move with the background, like the people sat at the table, need to be repositioned in a second, separate step. Here this the developers may have skiped it at all, only updated internal coordinates, so the next 'normal' drawing cycle will reposition them anyway.

The player sprite in contrast does not move at all. He stays always at screen center. That non-moving (in terms of screen coordinates) makes it seem to 'move' flawless (in terms of perceived movement).

In total this looks quite like a sequence issue.

When the player moves, then the program sequence looks like:

  1. Reposition (scroll) background against direction of movement
  2. Draw picture
  3. Reposition 'non-moving' sprites

When the movement ends another redraw is done. That's a 'solution' often found in games to clean up any artefacts that may be left over from complex animations like effects and movement. With high frame rates (like on TV), the effects are next to invisible.

As an LCD based game, screen redraw is only needed with changing content, so way less often, making the effect visible on a good display - which the Game Boy didn't feature :))

By flipping step 2 and 3 the 'lag' will vanish and that seems to be what happened with later versions.

Bottom line: One might call it in hindsight a sequence error, but at the time it was within expectations (state of the art), as it doesn't get as anoying with the Game Boy hardware.

  • 4
    With the slow update of the LCD, I wouldn't be surprised if the lagging actually improved the appearance slightly by enhancing the visual separation between the foreground and background objects.
    – supercat
    Feb 28 at 5:01
  • @supercat yes. I skipped that argument, as I wanted to avoid useless side threads that usually end in heated opinions. So, yes, as you mention,many effects don't translate well between different media - much like CGA colours look crappy on a dedicated screen but (comparable) great on a TV. Here it's about the low contrast (resolution) and sluggish of the original game boy vs crisp clear and quite sharp displays of modern emulation.
    – Raffzahn
    Feb 28 at 16:44

Lacking meaningful research avenues, I started surveying YouTube videos, and I think I managed to mine some insights even from that scant evidence. Here is what I found out:

  • The issue is apparently just barely visible, if at all, on the original Game Boy; it probably cannot be noticed on a real handheld unless one is specifically looking for it, as LCD motion smearing masks the issue to the point of imperceptibility. Take this video: it’s hardly perfect for this investigation, as the handheld isn’t exactly still in the frame. Nevertheless, around 3:05 you may take a close look at the guard standing next to the house, or around 6:10 at the NPC sprite on the right. When I watch those moments frame by frame, I do notice some familiar-looking, if only slight, wobbling of the sprite against the map. But I am not even entirely sure if I am actually seeing it, or just imagining it because I know it should be there.

    Either way though, the NPC sprites don’t seem to be any more sharp when in motion either (compared to the map), so this seems to count against the ‘deliberate kludge’ explanation. Then though, the aforementioned shaking, and the fact that the video was recorded at 30 frames per second might have, well, distorted the picture somewhat.

  • The scroll drag is just as pronounced on a Super Game Boy (a Game Boy cartridge adapter for the SNES) and on the Game Boy Player (an analogous adapter for the GameCube) as it is on emulators. Both are official Nintendo products containing original Game Boy hardware, and as such may be considered alternative, equally legitimate implementations of the Game Boy ‘platform’.

    This weakly counts against the emulators being at fault; or at least it means that whatever pitfalls the emulators fell into, Nintendo themselves couldn’t help but do the same.

    The first Pokémon games were released two years after the Super Game Boy became available, and do contain some SGB-specific features (like a customised border, and SGB colour support); clearly, the game must have been tested on this hardware. It is therefore somewhat surprising that this issue slipped through.

  • Not so many people are aware that the original second-generation games (Pokémon Gold and Silver) are actually playable on the monochrome Game Boy, even though they weren’t particularly optimised for it. Having recalled this, I decided to emulate Pokémon Gold in Game Boy mode to see how it behaves. When I did, the lagging effect was absent, unlike with first-generation games, but very much like running in Game Boy Color mode:

    Pokémon Gold, played on an emulated Game Boy in grayscale. The player character walks horizontally, then vertically on the ground floor of his house in New Bark Town. There is an NPC sprite, but no lagging.

    This seems to rule out the ‘hardware limitation’ explanation (one that I much doubted anyway), and to count in favour of the ‘problem with the game’ hypothesis.

Verdict: By elimination, it seems this is a defect in the game itself, one that has either slipped through unnoticed entirely, or was neglected before Generation II. My guess is that it was probably fixed more for the sake of the Super Game Boy than the handhelds themselves.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.