nesdev.org

I'm pretty new to NES development, so I'm not sure it this is possible, but I figure I'll take a shot and ask anyway...

Basically, I would like my game to use parallax scrolling in the background. Doing some research, I found out about the MMC3's scanline counter and how to use it to create a neat scrolling effect. I completely understand how I can use it, but I've come to a roadblock in terms of one thing.
I would like my game's levels to have varying heights (extending onto the background), and if I were to use the MMC3 scanline counter, the technical "foreground" of the game would scroll with my background.
Is there any way around this, or am I going to have to keep my level below the background?

Thanks in advance, and I hope that I've explained everything well enough to the best of my ability.

EDIT: Fixed the title to be better worded

The most comprehensive demo of this that I've seen is this tech demo (2, 3)

That's about as good as you can get without Special or Extremely Special hardware.

Yeah, parallax layers can't overlap vertically. You can fake small structures using sprites, but the restrictions are very severe due to the low sprites-per-scanline limit and the small number of palettes.

Another option is to not use actual raster splits (i.e. no IRQs or scroll changes) and fake the parallax with animated textures (pre-computed rotations of graphics), which you can change by bankswitching CHR-ROM. Take a look at the game Sword Master for a good example of this. Overlapping layers become possible, as long as the front layer is mostly rectangular. The main drawback with this technique is that the parallax areas have to be fairly small and repetitive, since you need to store many versions of them in the ROM.

To save space, would using CHR-RAM to do something like that be more viable?
I know it'd take up time for game logic, but it'd most likely save a lot more space in the cartridge (right?).

Your CHR-RAM bandwidth is extremely limited. You shouldn't expect to be able to upload much more than 100 bytes per vblank—not really enough for any significant amount of tile compositing. And that bandwidth has to be shared across all the different things you'd want to do (tilemap updates, &c)

(Pedantically, truly herculean efforts could let you transfer a lot more, but preparing the data to be transfered will take a lot of time)

Alright. I got it.
Thanks guys!

You can have parts of the level that have half/one third of the screen as the playfield and use the rest of the screen for parallax scrolling (Like Shatterhand's Area B and Vice: Project Doom's Level 1-2 do). Perfectly good way of doing it IMO, especially since both games I mentioned are some of the best on the system

TheStoneBanana wrote:To save space, would using CHR-RAM to do something like that be more viable?
I know it'd take up time for game logic, but it'd most likely save a lot more space in the cartridge (right?).

Battletoads did it on level 2 for the walls.

However, Battletoads is one of the more impressive pieces of programming for the system. They did a lot of things that most beginners won't, (and probably shouldn't) attempt.