This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

4 way scrolling + status bar?

4 way scrolling + status bar?
by on (#62712)
I'm now thinking how to do a good scrolling engine and I've come with the doubt, is there any game with a status bar that scrolls 4 ways AND has more than 2 screens of height?
Super Mario bros 3 And Kyrby mess with nametable bits at $2000 to show the statusbar via irq I think, but that way you cant have more than 2 screens + statusbar of height.
Any ideas?
Re: 4 way scrolling + status bar?
by on (#62713)
Wave wrote:
I'm now thinking how to do a good scrolling engine and I've come with the doubt, is there any game with a status bar that scrolls 4 ways AND has more than 2 screens of height?

The Legend of Zelda. RC Pro-Am.

Quote:
Super Mario bros 3 And Kyrby mess with nametable bits at $2000 to show the statusbar via irq I think, but that way you cant have more than 2 screens + statusbar of height.

Kirby writes two identical copies of the visible map to VRAM, and then once the camera has risen entirely into the top copy, it switches to the bottom copy to ascend further.

Crystalis and Gauntlet II use an MMC3 interrupt to rewrite scroll to skip the status bar.

by on (#62715)
There are a few ways to implement this.

A common solution is to use single screen mirroring, so that one screen is used for the level map and the other for the status bar. The only problem is that there will be horizontal scrolling glitches at the sides of the screen (but this already happens with popular games such as SMB3 and Kirby's Adventure). You can hide such glitches though, with the trick used in Felix the Cat and Alfred Chicken (using a column of 8x16 sprites to cover the right side of the screen).

The other option is to use IRQs to skip over the status bar, like Crystalis does. I'm not a big fan of this solution, because it requires a mapper with IRQs.

by on (#62717)
Clash at Demonhead also uses the right column of sprites trick.

by on (#62718)
Mmm, I really don't understand RC Pro-Am. It only seems to use one screen from the two, maybe disables screen and draws statusbar at midframe?
Single table seems to be the best way, the IRQ version is a bit tricky

by on (#62719)
Wave wrote:
Mmm, I really don't understand RC Pro-Am. It only seems to use one screen from the two, maybe disables screen and draws statusbar at midframe?

It uses single screen mirroring. One of the name tables is used for gameplay, and the other for the status bar (which is selected when rendering reaches the bottom part of the screen).

But if you didn't mind a few empty scanlines at the top of the status bar you sure could draw it wherever you wanted every frame.

by on (#62720)
I'd strongly recommend using single screen mirroring.

Though if you ABSOLUTELY want to use a mapper that don't allow it, there is 2 way to do it :
- Keep two copies of the playfield (Kirby's Adventure, Gargoyle's Quest). Only works if the size of your status bar is constant
- Keep relocating the status bar as you scroll vertically (Conquest of the Crystal Palace, Radia Senki, Double Dragon series, Gradius II, Jungle Book).

Then it is also possible to do it like Cristallis or Krusty's fun house, which uses an IRQ to simulate one-screen mirroring. I personally would recommand that only at a very last ressort : (if my memory is good) if you have scanline IRQs, then you have either a one-screen mirroring capable mapper, or the MMC3, which becomes capable to do 1-screen mirroring if you turn it into mapper 118 TLSROM/TKSROM.
So only do that if you have prolems by the first 2 methods (for example if the extra VRAM transfers when scrolling is a real problem or if you change the size of your status bar (or hide it completely) during gameplay). In my opinion the overhead of having an extra IRQ at a VARIABLE scanline is the most annoying, especially when that IRQ comes close to a screen borer or the status bar. It probably kills the possibility of any other scan-line effect you could do during gameplay.

by on (#62739)
The most common way I see this done is by mirroring your writes to both nametables, while using horizontal mirroring. On the bottom-most nametable, you write your status bar, and then you just be sure not to overwrite it when you mirror your nametable updates.

Then, using an IRQ (like with MMC3), you split the screen to display the status bar.

The reason this works is because you'll be simulating single-screen mirroring, and your IRQ (which displays your status bar) will cover up the part of the nametable where the statusbar would scroll onscreen, should you scroll low enough.

If you want some "true" single-screen mirroring, I think MMC1 accomplishes this (one nametable will be your playfield, and the other nametable is the status bar). You just simply keep the status bar at the top of the screen, and use sprite #0 to split the screen to the playfield.

by on (#62772)
When you say "The other option is to use IRQs to skip over the status bar, like Crystalis does." is that changing verticall scrolling midframe?
Wasn't that not possible?
Or only changing the nametable bits?

by on (#62773)
It's possible to force the PPU to fetch from a new nametable offset by writing that offset to $2006 (effectively changing the horizontal or vertical scrolling).
Crystalis reset the offset to (0, X) when the screen reaches (30, X) manually to simulate 1-screen mirroring, but then it have to do it at ANY screen position.

PS : Read this if you're interested in more details : http://jonathan.microclub.ch/NES_raster/

by on (#62776)
Changing the "nametable bits" with $2000 does not affect vertical scrolling at all, except for writes that take place before prerender scanline clock 304, when the ppu does V=T.

by on (#62777)
Wave wrote:
When you say "The other option is to use IRQs to skip over the status bar, like Crystalis does." is that changing verticall scrolling midframe?
Wasn't that not possible?

Like it's been said, it's possible to redefine the scroll to any position you want midframe if you use some $2006/$2005 trickery (as explained in Loopy's scrolling doc).

Crystalis uses horizontal mirroring, meaning that the name tables are arranged one on top of the other, forming a 256x480-pixel map. However it uses the top name table for the map, and the bottom one for the status bar (like a game using single-screen mirroring would).

But since mirroring is set to horizontal, when the end of the name table with the map is reached during rendering the name table with the status bar would be displayed next, so the game sets up an IRQ for the scanline where this happens and resets the scroll back to the top of the screen at that point, forcing a scroll wrap (that would happen naturally with single-screen mirroring).

So yeah, it's basically simulating 1-screen mirroring. If you are just starting your project and haven't picked a mapper yet, I suggest you use a simple one that supports 1-screen mirroring (like AxROM), unless you absolutely need the other functions of mappers like the MMC3, such as CHR bankswitching, IRQs for purposes other than simulating 1-screen mirroring, and so on.