nesdev.org

Which NES or Famicom game has the fastest scroll speed? I know that many games regulate how fast a character can move to account for the preparation of upcoming nametable tiles. I'm thinking there may be games where the nametables don't need to be updated all that much and maybe it could be possible to scroll very fast.

If there isn't just one game, I'll take a few games. I'm mostly curious as to the type of game for which fast scrolling would work.

There are some fairly fast scrolling sequences in Recca (video), area 4 (at 13:03) in particular.

The two games that come to mind for me, are The Guardian Legend (first level), and Bio Force Ape.

I think the NES can update the nametables as fast as any reasonable game design would require, it's probably safe to say it's rarely (if ever) a limitation. Scrolling 32 pixels requires writing a little over 128 bytes per vblank, which is well within reason. Technically, I'm a little more impressed when games do pattern table animation in CHR-RAM (updating just one 16x16 background tile is 64 bytes).

Bio Force Ape scrolls at around 6-7 pixels per frame at its highest speeds, which is pretty damn fast. A game would usually need to be specially programmed to handle speeds higher than 8 pixels per frame.
In MC Kids, when you hit the object that takes you back the leftmost part of the level, it scrolls at 8 pixels per frame.

Sometimes people use the scrolling speed as some sort of performance indicator (something that may have started around the time Sonic was created), but the truth is that scrolling at high speeds isn't particularly hard or CPU intensive, it's just not done that often because it's hard for players to keep up with the action.

As long as the level maps can be efficiently decoded (which depends on how they're stored), an NES game simply needs a well designed VBlank handler that can transfer a few more bytes to VRAM than a naive/straightforward handler would.

Memblers wrote:The two games that come to mind for me, are The Guardian Legend (first level), and Bio Force Ape.

I think the NES can update the nametables as fast as any reasonable game design would require, it's probably safe to say it's rarely (if ever) a limitation. Scrolling 32 pixels requires writing a little over 128 bytes per vblank, which is well within reason. Technically, I'm a little more impressed when games do pattern table animation in CHR-RAM (updating just one 16x16 background tile is 64 bytes).

I was actually doing experiments regarding that in the last few days. The max amount of tiles I could update in CHR RAM was 8 (128 bytes) at a time, as you can see here. - https://www.youtube.com/watch?v=qUNyw1V_UHs (This one has 7 tiles, but it's in the same game)
Maybe with a more simple buffer, you could do more at a time, but I definitely agree that pattern table magic is way more impressive than fast scrolling.
With that said, there are games that achieve such animation with CHR-ROM, such as Metal Storm and Sword Master, which also make nice effects with animated pattern tables (At the expense of CHR-ROM space)[

The cart riding section in Bucky O'Hare always felt extraordinarily fast to me. It's probably not the fastest on the NES, but it's a fast one at least.
https://www.youtube.com/watch?v=g2BxMv0NalI#t=5m17s

It seemed to be a common trend for fast scrolling games to make use of the infamous Flintstones technique, where the background is obviously repeated in a short period of time. Bio Force Ape is especially guilty of this. Was that purely a design choice, or a limitation of the console?

And speaking of, Sonic didn't seem especially interesting as a tech demo, as neither the NES or SNES were incapable of scrolling quickly. If anything, the SNES would've made Sonic better if only due to the Chaos Emerald stages actually rotating (thanks to Mode7) instead of being redrawn. Though many people did wonder what the point of those loop de loops is. I figured it was to show off the Genesis' superior VRAM (those things are made up of a lot of tiles), as well as the impressive physic engine that Yuji Naka programmed.

I think in Bio Force Ape the repetition is just the level layout, not anything to do with the scrolling. On the NES usually you're going to write the whole column/row of tiles whether or not some of them are redundant, because of the serial access mechanism. You have to budget your vblank for the worst case (all) so writing extra logic to break it into dirty segments doesn't really help much. You're probably either doing no scrolling updates (i.e. a repeating 1 or 2 screen loop with no variation), or you can do arbitrary ones, I don't think there's much middle ground there. (On a different system without a GPU that continually redraws the screen, you might have a framebuffer that you have to update with the CPU, and in this case doing partial updates could save a lot.)

A lot of games use repetitive design to save data space, a technique I usually call "rubber-stamping", where you can place many instances of the same shape (often a whole screen) and just add little customizations on top. Metroid or Metal Gear are pretty prominent examples.

How about Micro Mike?

https://www.youtube.com/watch?v=2Vl3u7VuhTI

OneCrudeDude wrote:...show off the Genesis' superior VRAM

How is the Genesis' 64K VRAM superior to the SNES' 64K VRAM?

ccovell wrote:

OneCrudeDude wrote:...show off the Genesis' superior VRAM

How is the Genesis' 64K VRAM superior to the SNES' 64K VRAM?

*profuse sweating begins*
muh blast processing

Blast Processing was a thing with Sonic 2, not 1. The point of the loops is to show that Sonic was so fast that he could go through them. Nothing to do with superior hardware, just with the character. Dropping all the rings when getting hit however was meant to showcase the console's power (although only up to 32 rings may get spawned from that in practice).

Amusingly, if there's a case of a game where scrolling can go so fast that the system literally can't keep up, it's Sonic (remember it has a 16 pixels per frame cap because otherwise the engine can't redraw the background in time, and while fixable that'd make the redrawing code more complex and much harder to maintain).

Sik wrote:Amusingly, if there's a case of a game where scrolling can go so fast that the system literally can't keep up, it's Sonic (remember it has a 16 pixels per frame cap because otherwise the engine can't redraw the background in time, and while fixable that'd make the redrawing code more complex and much harder to maintain).

What do you mean? I've had it to where I've fazed through loops and into the floor in Chemical Plant Zone, if that's what you mean. I guess it jumped straight through the collision area in one frame.

Go fast enough and the camera lags behind to give time to the engine to draw the background as it moves.