Street Fighter 2010 Scrolling?

[CrowleyBluegrass]

I'm going to keep this question as open ended as possible. Partly to facilitate free discussion and debate (you guys seem to love scrolling debates) and partly because I've only just started out and have very little idea what I'm talking about

Street Fighter 2010, in the first level, employs four way scrolling in a way that I think would work well for my game. The playfield is limited in the sense that it's neither particularly high or wide, but it does allow scrolling in all directions. Furthermore, due to the nature of the level (the boss is there from the start and follows you around the playfield) the boss must be kept track of even when offscreen, otherwise if you scrolled him out of view he'd never "find" you or be able to follow you, if that makes sense. It also keeps track of breakable object too so if you break them, they stay that way.

Can anyone shed some light on how this is done and the implications? Things like mirroring, mapper, does it scroll in the way you'd expect? There seems to be a small amount of glitchyness at the bottom center of the screen, and a significant amount on the right edge of the screen. Feel free to discuss concepts and code that fly right over my head.

I'm nowhere near the point at which I'd be implementing stuff like this in my own projects. Still, this sort of gameplay (the first level anyway) is just what I had in mind when I first contemplated writing a game for the NES. Of course I now realize that this isn't really something the nes is particularly suited to. Certaily possible, but not without headache. I still plan on writing something like this in the near future, so any information here will (hopefully!) be put to good use by me if not someone else.

Thanks a bunch

Quick edit - If somebody thinks this would be better suited to another section of the forum, move away. I just put it here because I'm a newbie.

[qbradq]

Having a quick look at the NES Cart DB Page for the US cart it uses an MMC3 revision B mapper, almost identical to what SMB3 uses. Without having the ROM in front of me to look into it, and only having the AVGN episode to go by, I'd guess it uses SMB3's faux four-way scrolling, which I will describe below.

SMB3 uses horizontal mirroring / vertical arrangement, such that the name tables are arranged as such:

Code: Select all

1 1
2 2

The game area is 1 and 7/8ths of a screen tall, and the bottom 1/8th of the bottom screen is the status bar. When moving horizontally, the entire ~2-screen area of the level is updated vertically, which is why you see the artifacts on the right of the screen. When the display is scrolled vertically, the MMC3's scanline interrupt is used to reset the vertical scroll register at the appropriate time so that the status bar is always visible.

This may be the easiest way to do a four-way scroll with status bar, but is limited in height. It works very well though. I've played SMB3 for countless hundreds of hours and never once thought "these levels are kinda short". It wasn't until I started reading these forums that I understood what was going on. Kinda blew my mind hole

[tokumaru]

Can anyone shed some light on how this is done and the implications?

The simplest way to implement confined 4-way scrolling would be to include extra RAM for name tables in the cart (i.e. 4-screen), so you'd have a 512x480-pixel area to play in without having to update the name tables during gameplay. This game in particular doesn't seem to do this though, since there are some glitches resulting from scrolling horizontally. It most likely is stacking the 2 name tables on top of each other (i.e. horizontal mirroring) and updating columns of tiles at the sides in order to scroll horizontally, much like SMB3 does.

I'm not sure whether the game has other levels larger than this, but if it does, there would be no reason for it to use a different scrolling engine in some rooms just because they're smaller... if they have a more versatile engine that can handle long levels, that's what they'll use for the smaller ones as well.

Boss tracking you: there's no rule saying that offscreen objects can't be active. Collision shouldn't be dependent of what's onscreen, that would be bad programming. Most engines deactivate objects when they're a certain distance away from the screen only to save CPU cycles, because in a large level you will run across several objects, and if you don't give priority to those that are onscreen there won't be enough time to process them all and the game will lag. But in a confined space with a controlled number of active objects, you can safely leave a boss always "on".

Breakable objects: this varies depending on the amount of breakable objects. If huge parts of the level can be modified, it would make sense to have the whole level in RAM. On the NES, this usually means extra RAM on the cart, because the 2KB of built-in RAM aren't enough to hold much. If you have a moderate amount of breakable objects, you can find ways to map them to individual bits in RAM (128 bytes are enough to remember the state of 1024 objects): 0 means an object was destroyed, and shouldn't be drawn when the location where it was is rendered to the screen.

There seems to be a small amount of glitchyness at the bottom center of the screen

That's because of a badly timed scroll split for the status bar.

Of course I now realize that this isn't really something the nes is particularly suited to. Certaily possible, but not without headache.

Not at all. It may seem hard at first, but it's pure math. You must know when to make changes to the name tables and find the correct formulas to calculate the correct source and target addresses for the tiles. It's not voodoo, if you think about the process carefully and plan everything out, you can find a working solution without pain. However, if you jump straight to coding hoping to solve it all with a handful of instructions without any actual planning, you'll surely fail. Pen and paper are a programmer's best friends.

[CrowleyBluegrass]

faux four-way scrolling

Rolls off the tongue nicely
Thank you kindly for the info qbradq. That sheds a lot of light on things.

It may seem hard at first, but it's pure math.

Erm, I guess now is a good time to mention math isn't one of my strong suits? haha. Don't worry, if anything I'm less productivity minded (in terms of actual code writing) and more planning oriented. I'm up to Nerdy Nights tutorial 4 (one lesson a day) so all of this is "conceptual research" for the future. I don't plan to tackle a game any time soon


A question, albeit an uninformed one:
Looking at the wiki page on scrolling
http://wiki.nesdev.com/w/index.php/PPU_scrolling

The page assumes vertical mirroring for the "common case" section, right? So using the method described by qbradq above (the SM3 method) with horizontal mirroring, once you scroll the "camera" past the first screen boundary, it would enter the mirrored portion at $2C00/256 and therefore, you would need to "figure out what columns or rows of the nametable are just coming into view, and you write that to VRAM before you set the scroll,"
Whereas with vertical mirroring, only once the camera had passed the second screen boundary at $2400 would you have to start doing this, is that correct? Hope this makes sense.

Thanks again. Oh, one more thing...

formulas

It's formulae, you damn Americans!!
Just kidding!

[Dwedit]

Thanks again. Oh, one more thing...

formulas

It's formulae, you damn Americans!!
Just kidding!

Tokumaru is Brazilian you know

[tepples]

There are about a brazillion Brazilians like tokumaru, all of them (South) Americans.

Anyway, SMB3 scrolling (unlimited width, 2 screens tall, usually some attribute artifacts on the right side) looks like a good guess.

[qbradq]

If you wanted to get higher than ~2 screens using this setup and retain the scroll bar things start getting very complicated. In a nutshell, you start scrolling vertically but never overwrite the status bar. Then you have to calculate at what scanlines you need to adjust the VScroll value to both skip the status bar mid-frame, and make the status bar appear at the bottom of the screen. An example of this sort of thing can be seen in Crystalis, but I think it uses single-screen mirroring. Either way it has to do these same frame calculations.

Again it's all just math, and not very complex math at that. Just a bit of algebra. Now implementing that algebra in 6502 assembly... that can mess with your mind a bit.

[CrowleyBluegrass]

What I meant was, with vertical mirroring it's like this
AB
AB
So when you scroll past A, you just have to move the camera (set the scroll) because the other half of your background is already there in B.

On the other hand, with horizontal mirroring
AA
BB
Once you scroll past B, you end up with B again due to mirroring. Therefore, to get the other half of your background, you have to figure out when you reach the mirrored section, and then write the new background columns into vram before setting the scroll. Of course this would also replace the same columns in your unmirrored B but they're all the way back at the beginning of the level, and you can just do the reverse (load the tiles to the left of the camera) when going backwards.

Does this sound right?

[qbradq]

Yes

[tokumaru]

Does this sound right?

Yes. There's no optimal mirroring (except for 4-screen, which is the lack of mirroring) to use when implementing 4/8-way scrolling on the NES, both horizontal and vertical will result in glitches somewhere. Of course, there are a multitude of tricks to hide these glitches... To hide glitches at the sides of the screen, a few games have the PPU mask the left side while placing a column of sprites on the right side (Alfred Chicken, Felix the Cat). To hide glitches at the top/bottom, some games use blank tiles and bankswitching (Jurassic Park), others enable rendering late (Super Cars) or disable rendering early (Big Nose Freaks Out).

Some games simply left the glitches there, even big games like SMB3 and Kirby's Adventure. When implementing a 4/8-way scrolling engine you have to pick the method you're most comfortable with, and decide whether you'll bother hiding the glitches.

If you wanted to get higher than ~2 screens using this setup and retain the scroll bar things start getting very complicated. In a nutshell, you start scrolling vertically but never overwrite the status bar. Then you have to calculate at what scanlines you need to adjust the VScroll value to both skip the status bar mid-frame, and make the status bar appear at the bottom of the screen. An example of this sort of thing can be seen in Crystalis, but I think it uses single-screen mirroring.

Another solution, which doesn't require IRQs, is to dynamically draw a new status bar on the other name table when you are about to overwrite the one you're currently using. You don't even have to draw it all at once, you can do it progressively as the screen approaches the status bar that's currently in use.

Yet another solution (which also doesn't need IRQs) is to put the status bar in only one of the name tables, but draw all your metatiles to both name tables, so that when the screen is about to enter status bar you can switch to the other name table, which has a 1:1 copy of the one you're in and doesn't have a status bar. I believe Kirby's Adventure does this.

[MottZilla]

I was going to suggest what tokumaru did. You draw the status bar at a different location in nametables depending on the vertical scroll. I know of atleast one game that uses this method of Horizontal Mirroring and redrawing the status bar to another point when scrolling updates are going to overwrite the status bar.

Another game, Wolverine, appears to always have the status bar at the same place in name tables but still scrolls vertically more than 2 screens. It appears that it may infact use an IRQ to skip over the status bar from being rendered.