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

I don't understand: vertical mapping

I don't understand: vertical mapping
by on (#161644)
I've been thinking about the limitations of the NES so as to properly emulate them, and there is something I simply don't understand. Vertical mapping. By which I mean, when the image map for the background is drawn to fill a vertical space. (If I have the term wrong please correct me.)
I want to avoid ever needing that so I don't have to worry about seeing the tiles on one side of the screen using the wrong palette. (Not just because it looks ugly but because I have no idea how to recreate that effect properly.) So I have been studying how various games work to understand how I can avoid the problem. And... I'm kind of at a loss as to why any game had this problem.

Most games can avoid this because the top and bottom edges are cut off on the NTSC NES, and so if the game has the map laid out horizontally, when/if the screen moves vertically those tiles that are the wrong palette are simply not seen. So to avoid seeing this problem, all I need to do is make sure my game is laying out the map horizontally.

Typically, a game that features vertical and horizontal scrolling and a status bar will have this problem. In that situation, the map has the status bar on the top or bottom of the map, and then draws a vertical chunk of the map, and since it has to write over the map to "scroll" to the left or right, an edge will get that palette-bleeding effect.

As I have been studying various games, it has become apparent to me that each scanline can draw the background from any desired co-ordinate in the map. So when it gets to the scanline where the status bar is, it just draws that portion of the map which contains the status bar. (And this is also how games fake parallax scrolling by having some scanlines more at a different rate across the map than others.)
But if this feature exists, why can't a game with a status bar still have vertical scrolling with a horizontal map? Couldn't the system (if it had to) split the screen to draw, say, the bottom portion of the map on the top portion of the screen, and the top portion of the map on the bottom portion of the screen? It wouldn't be too hard to compute the math for that, so I don't see why a game couldn't do that to avoid the palette-bleeding that would come from using a vertical map.
In fact, isn't this already happening in a couple games? Games that have vertical scrolling and a status bar. Some parts of Castlevania III and some maps in Super Mario Bros 3; they have vertical levels that clear are taller than the two screens worth of map the game can load. How do they handle this and not draw the status bar into the play area?

And then I see some games that use a vertical map, and I have no idea why. Mega Man 5 is a good example. Since the health bar is made of sprites, it could just have the map be horizontal, but it doesn't. And it just keeps a chunk of the level that can't even be seen in that spot. Why? It's not using that space; it's a terrible waste.
Re: I don't understand: vertical mapping
by on (#161647)
I have a preference for calling this "horizontal mirroring" rather than calling it a "vertical arrangement" (or you've said "mapping" here), mostly because it's used for so many different things, and as you've pointed out some games do vertical scrolling situations by other means. Mirroring describes instead what the hardware is doing, rather than what you might be using it for. (This is just my semantic preference though, you can call it what you like.)

The NES was really only designed to facilitate simple horizontal or vertical scrolling, but not both directions at once. Horizontal mirroring is great for games that scroll vertically, or that have a limited vertical space (i.e. under 2 screens high) plus a status bar. Super Mario 3 makes fantastic use of it (check out its nametables in a debugger), in a way that is very simple to implement.

Aside from the simple situations, I think the reasons for choosing a mirroring mode in most games had a lot more to do with ease of implementation, and their individual schemes for storing level maps. Even though all of the Mega Man games look like they should work with simple horizontal/vertical mirroring, it seems like they tried many different approaches across the various games. Most developers didn't seem concerned with eliminating the glitches at the edges very much, especially since TVs used to commonly have wide bezels covering the edge of the screen.
Re: I don't understand: vertical mapping
by on (#161658)
Most games did not use large maps with full horizontal and vertical scrolling, and a status bar at the same time, but a few did. It was easier to program if you had single-screen mirroring available, such as MMC1 or AxROM (Rare games), which lets you switch to the other nametable at a screen split. But with careful use of MMC3 interrupts, you could simulate single screen mirroring when the nametables are arranged vertically (horizontal mirroring) by using a screen split at the bottom of the map to make it wrap back to the top. Crystalis does this.
Re: I don't understand: vertical mapping
by on (#161676)
Marscaleb wrote:
Most games can avoid this because the top and bottom edges are cut off on the NTSC NES

In general, yes, but It's not like every TV cleanly cuts 8 scanlines at the top and 8 at the bottom, it varies a lot from TV to TV. The glitchy scanlines are present in the video signal after all, and many TVs will show at least a portion of them. And there's always PAL to consider.

Quote:
So to avoid seeing this problem, all I need to do is make sure my game is laying out the map horizontally.

In all honesty, you'd be better off using a 4-screen layout and not bothering about scrolling glitches. Adding extra name table memory to a cartridge is pretty trivial, so there aren't any actual reasons for you to avoid that, specially considering that you're only simulating the constraints of the NES and not actually dealing with them.

Even when using 4 screens, there's still the status bar problem, but you can either skip over it with IRQs and mid-screen scroll changes, or redraw the status bar somewhere else whenever the map data is about to overwrite it.

Quote:
As I have been studying various games, it has become apparent to me that each scanline can draw the background from any desired co-ordinate in the map.

Yes, but the CPU has to actively modify the scroll whenever you want to show a portion of the map other than the line that naturally follows the current one. And the CPU needs to be synced with the PPU to do this at the correct time, something that can be achieved with timed code or mapper IRQs.

Quote:
But if this feature exists, why can't a game with a status bar still have vertical scrolling with a horizontal map?

It can, the logistics are just more complicated. IIRC, "The Jungle Book" uses this setup. It moves the status bar up and down within the name table as necessary, and blanks some scanlines to effectively reduce the vertical resolution and gain some room for scroll updates. It could have used IRQs to skip over the status bar like Crystalis does, instead of duplicating the status bar.

Quote:
Some parts of Castlevania III and some maps in Super Mario Bros 3; they have vertical levels that clear are taller than the two screens worth of map the game can load.

I don't know much about Castlevania III, but IIRC, no level in SMB3 is taller than 2 screens minus the status bar. The game was intentionally designed that way to make the scrolling easier to code.

Quote:
Mega Man 5 is a good example.

Yeah, the Mega Man games are all over the place when it comes to scrolling. Each game does it in a different way, and I suspect it has to do with special effects that are used sporadically, such as spikes on the ceiling moving up and down, or large background bosses.
Re: I don't understand: vertical mapping
by on (#161684)
tokumaru wrote:
but IIRC, no level in SMB3 is taller than 2 screens minus the status bar.

SMB3 has a few vertical-only levels:
* Bonus room in second world 4 mini fortress
* World 5-2
* World 7-1
* World 7-6
Probably a few more too. Those levels use Vertical Mirroring, and have the status bar on the right nametable, leaving the entire left playfield as a single screen.
Re: I don't understand: vertical mapping
by on (#161691)
There's also this diagonally scrolling level: https://youtu.be/H1Ui3ZDX9MI?t=4195 (http://www.vgmaps.com/Atlas/NES/SuperMa ... rld5-9.png)

Probably these were handled as special cases in their game engine.
Re: I don't understand: vertical mapping
by on (#161694)
Checked out the diagonal level, appears to just be a regular H/V scrolling level, but every time the scroll reaches the top, and the screen is solid blue or white, it quickly wipes the nametables with the upcoming blocks (which match the screen so it doesn't look weird), then resets the scroll position to the bottom for new tiles to scroll in, until the scroll reaches the top again.
Re: I don't understand: vertical mapping
by on (#161697)
Kirby's Adventure and Little Nemo: The Dream Master use the same trick of duplicating the top nametable into the bottom one. It slows scrolling but can simplify the code, and with commercial time pressure to ship, that was often a good thing.
Re: I don't understand: vertical mapping
by on (#161707)
How does it wipe the entire name tables in one frame? Does it just selectively change tiles that aren't blank?
Re: I don't understand: vertical mapping
by on (#161712)
SMB3 doesn't wipe the nametables in one frame, it just updates the nametable as if you were scrolling horizontally very quickly. It takes 32 frames for the entire double-height nametable.
Re: I don't understand: vertical mapping
by on (#161718)
The diagonal level has a series of full-white or full-sky screens used at each camera transition. (I don't think the linked image map is accurate.)

When it reaches the transition point, the top screen is already full white, and then it just holds the camera at the top while it spends several frames covering the bottom screen with white (one row at a time). Then it jumps the camera back to the lower screen and resumes scrolling in the level background from there.
Re: I don't understand: vertical mapping
by on (#161720)
That's very clever. Does it continue scrolling horizontal even when it's not moving vertical?
Re: I don't understand: vertical mapping
by on (#161721)
psycopathicteen wrote:
That's very clever. Does it continue scrolling horizontal even when it's not moving vertical?

Not sure what you're asking. I'll describe it again.

At transition start, it has reached a full white top-screen.

The transition takes 64 frames, every second frame it writes another column of solid white. The actual scroll position remains against the edge of the written column (moving 4 pixels to the right every frame), but it's kind of irrelevant; anywhere on the top edge would look identical right now.

At the end of 64 frames, both the top and bottom screen are full-white, and the camera jumps down to the bottom screen. This is in the same horizontal position it started (has gone once around).

At this point it resumes sliding the window diagonally up and right like it was before, writing in new columns as they are reached.
Re: I don't understand: vertical mapping
by on (#161723)
Try using the Tanuki statue ability during the solid blue/white screens...
Re: I don't understand: vertical mapping
by on (#161725)
Why?

(I tried it. I don't see anything special happening.)
Re: I don't understand: vertical mapping
by on (#161731)
At the right times, every object will appear at the wrong position during the animation.
Re: I don't understand: vertical mapping
by on (#161737)
rainwarrior wrote:
psycopathicteen wrote:
That's very clever. Does it continue scrolling horizontal even when it's not moving vertical?

Not sure what you're asking. I'll describe it again.

At transition start, it has reached a full white top-screen.

The transition takes 64 frames, every second frame it writes another column of solid white. The actual scroll position remains against the edge of the written column (moving 4 pixels to the right every frame), but it's kind of irrelevant; anywhere on the top edge would look identical right now.

At the end of 64 frames, both the top and bottom screen are full-white, and the camera jumps down to the bottom screen. This is in the same horizontal position it started (has gone once around).

At this point it resumes sliding the window diagonally up and right like it was before, writing in new columns as they are reached.


So that means it does continue scrolling to the right throughout the transition, (but does it as a faster rate than the perceived scroll speed).

For the perceived scrolling speed, I'm guessing that every scrolling cycle is 256 perceived pixels long in both directions, and since a name table is only 240 pixels high, what would be perceived as scrolling up for the remaining 16 pixels, is actually when the name table wipe happens?
Re: I don't understand: vertical mapping
by on (#161757)
tokumaru wrote:
so there aren't any actual reasons for you to avoid that, specially considering that you're only simulating the constraints of the NES and not actually dealing with them.

Yeah, but at this point I'm trying to achieve 100% faithful NES recreation. No point in going this far just to back down now.
I want that to be a selling point that I can honestly claim about this game. I want to be able to state exactly what hardware is in the cartridge.

There are a lot of ways to avoid the palette-bleeding, but I just need to make sure that I'm using one that is accurate to the system.
My original plan was to use a sprite-based health bar, so I can use four-way scrolling. But as I've been thinking about it, it sounds like having a formal status bar might be possible, so I'm looking into the possibility.

tokumaru wrote:
In all honesty, you'd be better off using a 4-screen layout and not bothering about scrolling glitches. Adding extra name table memory to a cartridge is pretty trivial, so there aren't any actual reasons for you to avoid that,


Wait wait wait, that was something the NES could actually do?
What games did this? Did it need a special chip? Or a special mapper, or what?
Re: I don't understand: vertical mapping
by on (#161764)
Marscaleb wrote:
tokumaru wrote:
so there aren't any actual reasons for you to avoid that, specially considering that you're only simulating the constraints of the NES and not actually dealing with them.

Yeah, but at this point I'm trying to achieve 100% faithful NES recreation. No point in going this far just to back down now.
I want that to be a selling point that I can honestly claim about this game. I want to be able to state exactly what hardware is in the cartridge.

If you really want to go for 100% faithful recreation (as far as graphics goes -- it's hard to claim faithfulness when it comes to how much processing power is used, unless you actually write an NES game), why not write a simple PPU emulator? That'd force you to go by the limitations. Basically you'd have to emulate the nametables, CHR data, sprites and scrolling (with possibly some sort of midscreen changes). None of the low level timing details would have to be emulated.

In principle it's not a hard thing to make, but of course it might be challenging/error prone if you don't have full grasp of the NES architecture yet.
Re: I don't understand: vertical mapping
by on (#161767)
Marscaleb wrote:
tokumaru wrote:
In all honesty, you'd be better off using a 4-screen layout and not bothering about scrolling glitches. Adding extra name table memory to a cartridge is pretty trivial, so there aren't any actual reasons for you to avoid that,


Wait wait wait, that was something the NES could actually do?
What games did this? Did it need a special chip? Or a special mapper, or what?


Three games did it: Napoleon Senki, Rad Racer II, and Gauntlet. Several others too, but Bootgod's site doesn't list them.

The NES cartridge is responsible for mapping the nametable memory. Some games have a hardwired nametable arrangement, where the H or V pad is bridged together for Horizontal Arrangement or Vertical Arrangement. Other games route the pins so the mapper do nametable mirroring.

Gauntlet used it to make it easier to program a four-screen sized playfield, and Rad Racer II used it for scrolling effects.
Re: I don't understand: vertical mapping
by on (#161768)
Marscaleb wrote:
Wait wait wait, that was something the NES could actually do?
What games did this? Did it need a special chip? Or a special mapper, or what?

See: Mirroring#4-Screen.

A very small selection of games did it, they're listed there.

It requires extra RAM in the cartridge (for the other 2 nametables), and a small amount of logic. It's not very complicated to build, it's just that almost nobody wanted to do it in the NES commercial era. As I mentioned before, there are plenty of ways to get it done with only 2 nametables, and most developers didn't really seem to care about the attribute clash at the edges of the screen.

These days it's easier to find 32k SRAM than 8k, and the other components like PCB and plastics are more expensive for homebrewers than they were for mass production. The cost of everything is different now, and it'd be pretty reasonable to build a 4-screen mirroring + CHR-RAM cart, really. Or if you're emulating, it's free, of course (provided the emulator supports it).

Since only a couple of games actually did it, the technique is very atypical of the NES. If you're going for "authentic NES", it might seem outside the realm of what was normal for NES, depending on your point of view. Also, emulator support for 4-screen varies, since some emulators are implemented with the idea that 4-screen has to be built into the mapper, rather than something that could be added to almost any mapper. (It's a annoying point of view thing, but it is a compatibility issue when you start doing atypical stuff.)
Re: I don't understand: vertical mapping
by on (#161770)
thefox wrote:
If you really want to go for 100% faithful recreation (as far as graphics goes -- it's hard to claim faithfulness when it comes to how much processing power is used, unless you actually write an NES game), why not write a simple PPU emulator? That'd force you to go by the limitations. Basically you'd have to emulate the nametables, CHR data, sprites and scrolling (with possibly some sort of midscreen changes). None of the low level timing details would have to be emulated.

In principle it's not a hard thing to make, but of course it might be challenging/error prone if you don't have full grasp of the NES architecture yet.

I have been honestly wanting to do this, but strictly speaking it is a lower priority. I want to get the basic game set up first. But it is on my to-do list. Not only will it help me constrain myself to the limitations, but I want a command to open up a PPU viewer so the players can see proof that I am matching the requirements. Plus somewhere in my mind I can imagine this opening up some NES-accurate glitches where the player sees the wrong graphics if they find a way to break out of the map or something. I mean, I gotta avoid letting that happen, but still, I want to see it happen. ;)

I've already set up a test to have the game render to simulated curved CRT screen, which adjusts the pixel aspect ratio correctly. In the final version I may have some shaders set up to blur that render to match CRT screen distortion, and have an option to switch to a flat screen or a 1:1 pixel ratio.

I've also researched how I can get the palette-swapping effects to work the way I need them, and I've given thought to how I can have the music drop parts to play sound effects, how I can have the sprites flicker if there are too many on a scanline, and I'm leaving room in the code to make sure blank screens between level transitions are timed correctly... But Honestly, it all comes later. Gotta make sure the actual game is fun first.
But as I work, I'm keeping myself aware of what limitiations I will have to face.

I'm still early in this too. I'm going to see how long it takes me to get my proof-of-concept running before I commit to this. Otherwise it's just going to be a side project I'll work on from time to time.
Re: I don't understand: vertical mapping
by on (#161935)
Marscaleb wrote:
[...] how I can have the sprites flicker if there are too many on a scanline [...]


This was not a hardware feature, but had to be coded. The hardware has eight sprite registers. When rendering a scanline, it goes through the sprite table to find if a sprite line has to be rendered. When it finds a suitable sprite, information is written to the curent register. When all 8 registers are filled, no more sprites can be stored so every subsequent sprite in the table which happens to be in the same line just won't be shown.

If you don't provide a solution, sprites just disappear. In order to make them flicker, there are several methods. One of those, which I've used myself, is about sending the sprites to the sprite table in a different order each frame. That way, when more than 8 are in the same line, the 9th and subsequent sprites to be rendered are always different ones, thus the flickering happens (in each frame, different sprites are disappearing, so the overall impression is that they are flickering).
Re: I don't understand: vertical mapping
by on (#161942)
One thing I've noticed about CRT simulators is that many don't support distortion of the display based on how light/dark the colors are.

For example, look at a game where the background color flashes between a dark color and a light color, such as beating a level in the arcade version of Pac-Man. Notice how the entire screen moves around due to beam deflection, even though all the pixels are in the same place.
Re: I don't understand: vertical mapping
by on (#161944)
Related pages imply that it's related to power supply regulation:

I guess that makes a feature request for 240p test suite's linearity and grid tests: Add background brightness selection to see how well a tube's PSU compensates for brightness change.