back
9 comments
This article is really great. Thank you to the author for writing all this information up in a nice organized and clear way. Like the author, i've only seen most of this info scattered around various videos and articles hidden in with a bunch of other stuff and there's a ton of info i've never read before and all the examples from modern indie games are great.

The thing that taught me the most about scrolling was playing around with hacking metroid and super metroid. Scrolling in super metroid is fairly sophisticated, if still limited by hardware.

Learning to figure out the scrolling PLMs was a big part of figuring out how to make your rooms flow without breaking. In the vanilla super metroid, the scrolling system is used to pretty good effect to conceal secrets or build tension.

Up until doing some rom hacking, i'd never really appreciated scrolling before. I'd used modern engines that pretty much handled all that stuff for you, but it wasn't until peeking back at older games did it really become apparent just how big a deal scrolling is and how much effort is actually put into making good scrolling.

This article is astounding. I really appreciate the many examples. This also furthers my appreciation of the work that goes into some of the games that I've found really responsive or good in ways that I coulnd't express. I think in particular about the examples in Limbo and Geometry Wars given in the article.
I had the same reaction, and was pleased to see Never Alone featured in the article as well. I remember playing through it in one sitting constantly amazed at how well it handled scrolling across multiple characters.
Well done Itay on such extensive and graphical explanation of scrolling. It is interesting how wrong picture of scrolling I had before.
I have a nitpick however on one technical explanation: it is said that scrolling is sometimes avoided because it was expensive on old hardware. On all consoles, the background had an x/y scroll offset which allowed to scroll it with no effort. What cost in moving the camera was changing the sprites to be dragged while the camera moved to give the illusion they were not moving relatively to it.
It depends. Cycles are still needed to copy new data into sprite and VRAM which typically has to be done during vertical blank, esp. on older consoles.

16-bit platforms like SNES and Genesis/MegaDrive had a large enough VRAM to hold a background with enough area that you might be able to get away with reloading data into VRAM "between rooms".

NES has enough VRAM for 2 screens - either horizontal or vertical (it could do 4 screens if the catridge had extra VRAM on board which was rare) and VRAM can't be updated except during vblank. The game engine has to spend time copying new data ahead of the visible screen, and also must spend some cycles each frame letting a DMA process copy 256 bytes of data describing sprite positions to the video chip's object RAM.

Not as bad as the Commodore 64 where the scroll registers shift only up to 8 pixels and an engine has to recopy potentially a full 1k of screen and 1k of color RAM to move things (barring things like VSP which could corrupt RAM on certain C64's) - or the Atari 2600 that had no video RAM at all and required programming the video chip per scanline right before the TV is drawing it.

You're correct for console that handled that at the hardware level. I understood this section as referring to computer games, which didn't do that on the hardware.
This is amazing. Thank you!
A month or two ago, I binged some old episodes of Angry Videogame Nerd. Camera behavior in side scrollers is one of his big complaints in a lot of games. That and the behavior of the D-pad, A/B behaviors, navigating platforms, and control responsiveness. Tl;dr: make it like Mario.