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.
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.
Sik wrote:
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).
I hope I didn't come off as being serious!
Further amusingly, the ring drop in Sonic 2 often led to a good amount of slowdown.
Back on topic, Doki Doki Yuuenchi's roller-coaster level might be described as marginally fast. I remember part of Akumajou Special: Boku Dracula-Kun having a pretty fast platform-on-rails bit as well.
mikejmoffitt wrote:
Further amusingly, the ring drop in Sonic 2 often led to a good amount of slowdown.
I always thought that particular slowdown was intentional, in much the same way that
Street Fighter II runs at half speed from when a character loses all his hit points to when he lands.
tepples wrote:
mikejmoffitt wrote:
Further amusingly, the ring drop in Sonic 2 often led to a good amount of slowdown.
I always thought that particular slowdown was intentional, in much the same way that
Street Fighter II runs at half speed from when a character loses all his hit points to when he lands.
Nope - it doesn't always happen, especially not when you have a lower amount of rings.
The only reason tepples thought it was intentional is that he's such a master, that durring the few times he does get hit, he has well over 32 rings.
Anyway though, how do developers generally go about "intentional slowdown"? Do they just bombard the system with instrutions in a loop, like if there where 32 NOPs or something that kept getting looped?
Why wouldn't you just write code to automatically wait an extra frame?
Espozo wrote:
Anyway though, how do developers generally go about "intentional slowdown"?
Gradius has a bottom status bar on a mapper with no interval timer. It has to estimate the execution time of each object's handler and wait a frame if the next object handler is unlikely to finish before the sprite 0 hit.
Pokemon Puzzle League counts the tiles that are flashing and inserts vblank waits over a certain amount, in order to simulate the slowdown of
Panel de Pon for Super Famicom. Bullet hell shoot-em-ups do likewise, which not only makes play speed manageable during high object load but also adds a
dramatic overcrank.
rainwarrior wrote:
Why wouldn't you just write code to automatically wait an extra frame?
Oh, yeah...
Quote:
fazed through loops
phased
mikejmoffitt wrote:
Back on topic, Doki Doki Yuuenchi's roller-coaster level might be described as marginally fast. I remember part of Akumajou Special: Boku Dracula-Kun having a pretty fast platform-on-rails bit as well.
Boku Dracula-Kun's rollercoaster certainly looks fast, and the music helps it look fast.
Zanac's Area 12 goes pretty fast... Of course, when comparable to tile size, scroll speed will generate an optical illusion.
361341*20 lines of vblank(NTSC) /3 dots per CPU cycle /6 CPU cycles per long-write (LDA #imm + STA $aaaa), min ~ 380 bytes...so, 2 bytes scroll, 2 bytes address, 128 bytes of 4 NT lines, 2 bytes address, 8 bytes of AT for the printed scroll lines...138 bytes, +2 to update scroll...if you force-blank the pre-render line, you can do that three times, so 12 lines(96px) scrolling vertically? Less, of course, if one writes OAM; still 8 lines (64px) without forceblank.
(Horizontal scrolling requires a lot more address writes, as the PPU doesn't have an 8-address-increment mode to go vertically through an AT.)
One doesn't need to write each individually, though, so some address writes can be dropped (though wrapping will mean a second is likely to be needed). Mapper-assistance can, well, just get you whole screens, so we're ignoring it for this exercise.In any case, one can scroll faster on the NES than is likely to be necessary/useful to the viewer, with a bit of effort.
e: mixed up a number
tepples wrote:
mikejmoffitt wrote:
Further amusingly, the ring drop in Sonic 2 often led to a good amount of slowdown.
I always thought that particular slowdown was intentional, in much the same way that
Street Fighter II runs at half speed from when a character loses all his hit points to when he lands.
Sonic 2 is the most sloppy of all the games in terms of programming (there's a reason they redid the entire object manager for Sonic 3).
Amusingly one of the places where slow down happens is when the water rises in Chemical Plant 2, if the water manages to catch up with you the game slows down... right when you need your actions to be as accurate as possible. I swear when I was a kid I used to think it was done on purpose.
I would have thought they would have just recycled the majority of the code from Sonic 1. Did they really need to remake the game engine just to add tails and incorporate the spin dash?
Espozo wrote:
I would have thought they would have just recycled the majority of the code from Sonic 1.
They did, which is why things got messy.
Quote:
Did they really need to remake the game engine just to add tails and incorporate the spin dash?
They didn't remake the engine for Sonic 2, they redid parts of it for Sonic 3.
What tokumaru said.
To be more specific: Sonic 1's levels are pretty much mostly horizontal, so the object manager just spawns objects based on their horizontal position, which makes things simpler. Sonic 2 has more stuff going on vertically so it has to spawn more objects (on top of new code having been rushed which didn't help matters). Sonic 3 has so much stuff that they rewrote it to take into account both the horizontal and vertical position of the objects.
That reminds me of a question I had for a long time. Why does Sonic & Knuckles work for Sonic 2 & 3, but not Sonic 1?
Conventional wisdom is that Sega engineers couldn't figure out how to squeeze the palette in.
More likely answer: cartridge cost. The Sonic 2 part is crammed into its own 256KB ROM, I'd imagine supporting Sonic 1 would have required an even larger ROM for that. The cartridge would have been just way too costly to convince people to buy it.
Was the Sonic 2 cart actually used during gameplay?
Yes. The S2K ROM in the S&K cart read level data from the Sonic 2 cart.
Sonic 2 is 1MB, the ROM I mentioned is 256KB. Take a guess.
I guess the biggest problem is Knuckles requiring a whole new set of sprites since the palette is different (this is the exact same problem Sonic 1 has as well). Also I think it just uses its own copy of the engine, in part to implement Knuckles' skills and in part because the original engine really wasn't made for extensibility like that. Also it adds some objects around where Knuckles can reach but Sonic couldn't, so I suppose it has its own object layouts (the same way it patches Sonic 3's), although not its own map layouts and such.