It is currently Tue Sep 17, 2019 4:04 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: Maximum Scroll Speeds
PostPosted: Fri Mar 08, 2019 11:14 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 520
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?


Top
 Profile  
 
PostPosted: Sat Mar 09, 2019 6:37 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2560
Location: DIGDUG
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


Top
 Profile  
 
PostPosted: Sat Mar 09, 2019 6:49 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21591
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sat Mar 09, 2019 7:04 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1289
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.)

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Sat Mar 09, 2019 8:45 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11412
Location: Rio de Janeiro - Brazil
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.

Top
 Profile  
 
PostPosted: Sat Mar 09, 2019 1:23 pm 
Offline
User avatar

Joined: Mon Mar 13, 2017 5:21 pm
Posts: 67
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.


Top
 Profile  
 
PostPosted: Sat Mar 09, 2019 4:03 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
Karnov limited it to 1 pixel and 1 direction per frame, and somehow it was actually wonderful. ;)


Top
 Profile  
 
PostPosted: Sat Mar 09, 2019 4:35 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11412
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Mar 10, 2019 7:48 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4211
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!


Top
 Profile  
 
PostPosted: Sun Mar 10, 2019 4:26 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sun Mar 10, 2019 5:43 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2312
Location: Fukuoka, Japan
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.


Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 6:10 pm 
Offline
User avatar

Joined: Mon Mar 13, 2017 5:21 pm
Posts: 67
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group