Maximum Scroll Speeds

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Maximum Scroll Speeds

Post by darryl.revok »

What have you all used as maximum scroll speeds in the past, and does anyone have thoughts on breaking up tile and attribute updates into different frames?

In the past, I've programmed my scrolling routines to allow for a maximum of 8 pixels per frame and I usually just let tiles and attribute updates happen on the same frames as they shared some setup work anyway.

If I limit scroll speed to 4 pixels per frame in one direction though, I can stagger tiles and attribute updates to save cycles. If I further limited it to 2.6 pixels then I could split it into reading from the map, converting metatile numbers into tiles, and then converting metatile numbers into attributes, all in different frames.

For a Zelda-inspired game, a scroll speed of even 2 pixels per frame feels excessive.

Is there any reason I'm missing for why this wouldn't be a good idea? There's the possibility, "What if you want it to scroll faster in a cutscene?" So, in that case I could make an option that just bypasses the limiting portions. I guess the conditions would be that I could stop and change a setting to allow for 8-pixel scrolling in a special setting, but this wouldn't be available during typical gameplay. Could this somehow come back to bite me or it just really common?
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Maximum Scroll Speeds

Post by dougeff »

I think horizontally 2 pixels per frame is probably enough.

Vertically, I frequently have characters jumping and falling faster than 2 pixels per frame.

You could have characters that move faster than the camera, and only enforce the 2 pixel limit once you bump into the camera edges.
nesdoug.com -- blog/tutorial on programming for the NES
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Maximum Scroll Speeds

Post by tepples »

The theoretical limit, given the length of a vblank on an NTSC NES and the rate of the fastest practical update buffering scheme, is about 4 rows or columns of nametable (plus their associated attributes) in a single vblank. This means 32 pixels per frame in 2-way scrolling or 16 pixels per frame for 8-way. Incidentally, Sonic the Hedgehog 2 for Genesis is limited to 16 pixels per frame.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: Maximum Scroll Speeds

Post by Kasumi »

I offset attributes by four pixels because it hides the color errors better, so at least horizontally attribute updates and tile updates are unlikely to happen on the same frame.

My games will only scroll 8 pixels in both directions in one frame. If the character travels faster than this, they will eventually outrun the camera.

Edit: So I guess, basically, my engine does both. It can split the updates across frames, but it can also update both in one frame.

Duck Tales uses a limit smaller than this to avoid drawing an entire row in one update (check it out in a nametable viewer in a debugging emulator), and this takes away some of the CPU burden of the updates. But if you're doing rows at a time, there's not much benefit to having a hard limit of less than 8.

I have written a 32 pixel per frame scrolling ROM, but it's not a very practical thing to do. (The player can't react to things.)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Maximum Scroll Speeds

Post by tokumaru »

My scrolling engines can normally do 16 pixels per frame in both axes. That barely fits in regular vblank time though, so except for the OAM DMA, there's no time to do any other video updates when the name tables are updated horizontally and vertically in the same frame.

The benefits of updating larger name table areas go beyond just scrolling, since you can reuse the same logic for drawing entire screens (possibly making screen transitions faster), or to redraw visible parts of the screen (such as when revealing obscured areas, or doing other kinds of effects). In fact, that's also a good reason to avoid staggered updates that result in brief attribute inconsistencies, as you wouldn't be able to reuse that logic to for visible NT updates.

Also, I think that really low speeds of less than 4 pixels per frame are very restrictive, because even if your characters don't move that fast, objects that are falling or being thrown can accelerate quite a bit, and you don't want the camera to take forever to catch up.

Ultimately, there's nothing preventing the NES from scrolling as fast as Sonic 1 and 2 on the Genesis do, as 16 pixels per frame is perfectly possible in regular vblank time as long as the camera doesn't need to move perfectly diagonally for several consecutive frames. If you keep your vblank handler flexible, you can sustain moderate amounts of NT/AT updates most of the time, while also being able to handle the occasional more demanding moments.
Last edited by tokumaru on Sat Mar 09, 2019 1:38 pm, edited 1 time in total.
User avatar
gravelstudios
Posts: 159
Joined: Mon Mar 13, 2017 5:21 pm
Contact:

Re: Maximum Scroll Speeds

Post by gravelstudios »

The engine I've made for my current project has a maximum of 8 pixels per frame. It only scrolls horizontally. I check every frame to see if the seam is on a new tile column (8 pixels) or metatile column (16 pixels). Then I only update whatever needs to be updated on that frame. I update the whole 32 pixel attribute column when the seam is on a new metatile, which I know is a little redundant, but It seems fast enough for me. Frames in which everything needs to be updated are more likely to lag, but if it's only one frame here and there I don't mind. I suppose it wouldn't be hard to stretch it out to 16 pixels, but I like having the wiggle room to update other background tiles if necessary for things like breakable blocks. Scrolling is locked to the player character, and I will never need the player to move that fast.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Maximum Scroll Speeds

Post by rainwarrior »

Karnov limited it to 1 pixel and 1 direction per frame, and somehow it was actually wonderful. ;)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Maximum Scroll Speeds

Post by tokumaru »

Even games that don't scroll at all can be wonderful! I'm not saying you need fast scrolling to make a good game, but your engine will be more versatile that way.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Maximum Scroll Speeds

Post by Dwedit »

I got it working up to 8 pixels per frame.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Maximum Scroll Speeds

Post by rainwarrior »

tokumaru wrote:Even games that don't scroll at all can be wonderful! I'm not saying you need fast scrolling to make a good game, but your engine will be more versatile that way.
I was kinda joking about Karnov, but kinda not. At face value it seems really shoddy, but once you get used to it, it is sort of accidentally really fun to manipulate.

Some have described it as the perfect casual speedrun game for that reason, because waiting around for scrolling gives you a lot of time to prepare for your next move, and manipulating the scroll becomes very strategic.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Maximum Scroll Speeds

Post by Banshaku »

offtopic..cannot...resist...title... sounds like a message from the Crysis suit :lol:

edit:

In my current engine, there is no maximum scroll speed per say but I guess it would limited to the decoding of the background to some degree. The player acceleration alternate between 1~2 per frame based on a decimal increment, which makes it looks more dynamic.
User avatar
gravelstudios
Posts: 159
Joined: Mon Mar 13, 2017 5:21 pm
Contact:

Re: Maximum Scroll Speeds

Post by gravelstudios »

Banshaku wrote:In my current engine, there is no maximum scroll speed per say but I guess it would limited to the decoding of the background to some degree.
There isn't anything in my engine that limits the scroll speed to a particular value. theoretically it could scroll at any speed. The issue is that it can only upload 1 column of tiles to the PPU per v-blank, and/or copy one column of 16*16 metatiles from the level data to the RAM shadow nametable. (under normal circumstances). if it scrolls faster than 8 pixels per frame, then occasionally it will skip a column of tiles, although because background collision is checked against the shadow nametables it would be a visual glitch only. if it scrolled faster than 16 pixels per frame then it would occasionally skip over a metatile column, and that would cause real problems.
Post Reply