nesdev.org

ok, muchas gracias por la respuesta tokumaru.

another question is:

any people says that super mario bros uses horizontal mirroring.

i see in ines header readers of emulators that super mario bros is vertical mirroring.. it's correct???

Because, I agree that smb is vertical mirroring. smb is vertical because if smb was horizontal, all graphics behind (left) of super mario bros would get messed up on left side when super mario is walking to right side!!! because of the mirroring, no??

SMB uses vertical mirroring...

you probably had 'horizontal scrolling' mixed up with mirroring.

Another reason for the mixup: Does Nintendo's terminology for the mirroring solder pads on NROM boards match the homebrew community's terminology?

tepples wrote:Does Nintendo's terminology for the mirroring solder pads on NROM boards match the homebrew community's terminology?

No, it does not - Nintendo-made NES cart PCBs all label their mirroring pads "H" for Horizontal Scrolling (i.e. Vertical Mirroring) and "V" for Vertical Scrolling (i.e. Horizontal Mirroring).

lord of chile wrote:ok, muchas gracias por la respuesta tokumaru.

You're welcome.

Because, I agree that smb is vertical mirroring. smb is vertical because if smb was horizontal, all graphics behind (left) of super mario bros would get messed up on left side when super mario is walking to right side!!! because of the mirroring, no??

For a horizontal scroller, you'd want to use vertical mirroring to avoid glitches at the sides of the screen, that's right. However, many official games seem to use horizontal mirroring when scrolling horizontally, such as SMB3 and Kirby's Adventure. And the glitches do show a lot.

SMB3 and Kirby's Adventure also do a heck of a lot of vertical scrolling and free 2D scrolling, and you can't easily do that and have a status bar if you use vertical mirroring.

About textboxes, I have several info for you.
Do you want to build a RPG for the NES later ? You already asked questions about batteries, so this definitely becomes "suspicious" hehe. Good luck.
Because the NES has only one BG layer, most games writes the textboxes "above" the background. They do need to write 2 or 4 rows at time to have no attribute glitches (because the box won't have the same color bits as the background behind).
Then, when the window closes, you'll also have to rewrite the map data that is behind the box to the name table, and the map's color to the attribute table.
The "easy" way to do it is to read the old nametable and attribute table via $2007 and store it to RAM, to be restored later. This is lazy, waste RAM abd VBlank time for hardcore vblanktimesavers, but works well.
It is not so hard to read the map cordinates and rewrite it to the screen. I do that in my current game when the menu closes, and it is actually very easy to do, just some math is involved.
About writing text, each game has its own engine. Final Fantasy works pretty lazy, they write the whole string of text one row at time, wait to the player push A and shows what's next. Dragon Quest games have a better text phraser, that write letters after letters, and have a blinking cursor to wait the player to press A. It's up to you to determine what is the most confortable for the player.
Final Fantasy I is doing a special trick : It does write the window in the alternate nametable. Because it uses vertical mirroring, the engine still couldn't allow to scroll while a textbox is open, but it allow a cool effect when they pop up that isn't there in Final Fantasy II and III.
To allow scrolling when a textbox is open, you'll have to use one-screen mirroring (or maybe horizontal, but needs to be tricky, especially on a PAL system that doesn't hide the top and bottom 8 scanlines).
I do have no RPG that does that in mind, but I was thinking doing that in Ecological Evolution (not sure yet).

Hey, I have a suggestion for the text boxes. Let me show a picture of the idea first:
Now, this represents the 2 name tables, in vertical mirroring mode. The dotted red line is splitting the 2 name tables. The green parts are the map that was previously rendered to the name tables. The light part is where the camera is (the red spot represents the scroll values). The gray part is where you would draw the text box if you were to draw it in place (I'm assuming the text box stays at the bottom of the screen). But if instead you draw it in the yellow part, you can have it appear with the "sliding" effect (by splitting the screen). The background wouldn't be overwritten, so, when the text box goes away you just keep scrolling normally. And you could have all of that using vertical mirroring, the best for scrolling without any visible glitches. Of course, you woudn't be able to scroll when the text box is active.

I don't usually play RPG's, but I'd guess at least some have already done it like this.

That's just what FF1 does. It also copies the tiles of the border of the screen to the second name table to not have the text box take the full screen.
This wasn't maintened in FF2 and FF3.

Bregalad wrote:Because it uses vertical mirroring, the engine still couldn't allow to scroll while a textbox is open

Sorry. For some reason I missed the "vertical" part and assumed it used horizontal mirroring. I guess it's because you said "alternate name table", and it sounded like it used only one name table for the text box, but it usually spans across the 2 of them, at the parts not currently showing.

i like rpgs, some day i am going to make a rpg game of my life..

just im very creative, i dont like final fantasy 19, no..

just it will be "Luis's hidden life crystals" or another.. and just nesdev guys are going to appears in my game =o).. and i dream with a sequel for snes and n64... some day... more later..

im fanatic of terranigma in spanish for snes.

i play super mario bros 3, i think that it uses horizontal mirroring because it's more easy to designers get mario going to left and going to right using horizontal M..

it's because smb3 can go around all the stage for left and right..

smb1 only was walking into right then it uses vertical, but smb3 walking into two directions is good use horizontal mirroring here..

are correct my conclusions??

yeah, the glitch is very notorious in smb3, horizontal scrolling with horizontal mirroring.. but i think that programmers take control of this because this glitch without control is ultra notorious and would messed up very much part of screen.. there is control of this glitch on smb3 no??

and another is: what is the official megaman 3 bug???
i dont see bugs in megaman 3

lord_Chile wrote:i think that it uses horizontal mirroring because it's more easy to designers get mario going to left and going to right using horizontal M..

it's actually related to the fact that SMB3 can move up and down. And it has a status bar. If you scroll up and down using vertical mirroring, there is no way you can have an area in the name tables reserved for a status bar, it would be overwritten all the time. The solution used in SMB3 was to use horizontal mirroring, with the status bar fixed at the very bottom of the second screen.

smb1 only was walking into right then it uses vertical, but smb3 walking into two directions is good use horizontal mirroring here..

SMB1 has the limitation of not scrolling to the left because of the way the levels are decompressed, it has nothing to do with mirroring.

yeah, the glitch is very notorious in smb3, horizontal scrolling with horizontal mirroring.. but i think that programmers take control of this because this glitch without control is ultra notorious and would messed up very much part of screen.. there is control of this glitch on smb3 no??

Well, the programmers know the glitches are there, and there is no way to get rid of them in that situation (horizontal mirroring + side scrolling). It happens because when using horizontal mirroring, you get a drawing space that's 256 pixels wide and 480 pixels tall. 256 is exactly the ammount of pixels displayed in a line on the TV, so if you scroll even a little bit to the right, what will show on the right is exactly what was just left behind, on the left.

You don't get any extra space to use as a drawing buffer, hidden from the player. The NES has the option to hide the leftmost 8 pixels. This way you get a hidden place to draw things, but it's only wide enough to avoid glitches related to patterns (since you can draw columns of tiles that are 8 pixels wide, just as the buffer) but not the ones related to color, since the color resolution in the NES is 16 pixels, not 8.

So, in SMB3 you'll often see that the colors are wrong in the righmost column. The colors will be the ones that belonged to the blocks that are disappearing at the left.

Question about nametables.. i understand pattern tbl, name tbl, because im programming a graphic decoder in php. But my problem is with attribute table.. am i calculating correctly????

see it, each (*) is representing one tile.:

********************************
********************************
********************************
********************************

fig 1.0 (showing 4 rows of tiles and cols of 32 tiles) (representing 8 bytes for attr table)

For each 4 rows of tiles=8 bytes in attribute table

groups of 4x4 tiles (each group=1 byte) in attribute table.

1-4 row of tiles 8 bytes
5-8 row of tiles 16 bytes
9-12 row of tiles 24 bytes
13-16 row of tiles 32 bytes
17-20 row of tiles 40 bytes
21-24 row of tiles 48 bytes
25-28 row of tiles 56 bytes
29-32 row of tiles 64 bytes

but if nametable is 32 cols x 30 rows of tiles......

30 rows of tiles doesnt match with my calculations, because the byte number 64 in attribute table contains high color bits for 31-32 row of tiles, too. This area is unused?????

I think it would be 4 bytes unused, am i calculating correctly????

On a past post, Disch wrote:

"The bottom 2 rows of the attribute table are used when the attribute table is used as nametable data."

what mean, "when attribute table is used as nametable data??", when it is?

lord_Chile wrote:what mean, "when attribute table is used as nametable data??", when it is?

If I understand correctly, this is how it normally works:
- The nametable is located from $000 to $3BF in its "page" (so nametable 0 is in $2000-$23BF), it's only 30 tiles tall, leaving the space from $3C0-$3FF for attributes
- The PPU is smart enough to skip over the attribute bytes and go directly back to the top of the nametable after drawing the bottom tiles

The PPU only skips the attribute bytes when it gets there on its own. If you set the vertical scroll between 240 and 255, it will start in the attribute area instead of the nametable area. Since it never hit the line 240 boundary, the PPU will mistakenly read the attribute bytes and use them as nametable bytes. When this happens, it also uses the (normally useless) last few attribute bits to select colors for the tiles.

Is this correct / did it make sense?