Background issues

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
-tokumaru-

Background issues

Post by -tokumaru- »

Hey!

I seem to be having a LOT of trouble to login, so I'll just post as a guest...

I have a couple of questions for the more experienced ones (although this are just basic questions, I want to clarify the matter):

I have a 4-way scroller on the way and I expect to find some problems with the scrolling background. Mirroring is set to vertical, so scrolling horizontally is no problem, but scrolling vertically may introduce some artifacts (wrong tiles and wrong colors) at the top and bottom of the screen, right? How should I handle this? Should I use a scanline counter to enable/disable background rendering at the top and/or at the bottom? Should I do nothing and expect the TV set to cover most of the rows with garbage in them?

Any advices? Thanks for the help!

-tokumaru-

PS: I'd like to stick with the 2 screens built in the NES, but if you think a 4 screen cart is the best solution, please say so.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

You should be able to rely on the top and bottom 8 pixels being cut off on nearly every NTSC display. Commercial games such as Super C rely on this.

Or are you targeting PAL as well? In that case, whenever you scroll vertically, make whatever row of tiles straddles the screen edge blank. Then you can guarantee that the other row in the same attribute row is drawn with the correct attributes.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

I tend to have NTSC in mind... here in Brazil the standard is PAL-M, wich inspite of the name is much more like NTSC. PAL-M has the same resolution and fps as NTSC, the only difference is the color scheme, I guess. All newer TV's, VCR's, etc. support NTSC in here, so I guess that's what I'm always going to use.

So, using NTSC, I can count on the fact that top and bottom 8 pixels don't show... So, 2 spare/buffer rows is enough to draw a row of 16x16 pixel blocks without worrying about glitches.

Well, I guess the whole process could be like this: at the beginning of the game/level I set the y scroll to 8; then, start drawing the level from the third row in the nametable to the end; now, if the player goes up or down I can draw the appropriate row and scroll the screen;

This way I start with 8 pixels of nothing on top and bottom, and can move to wherever I need. Do you think this is going to work ok?
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch »

chopping off the top rows is a bit more trouble than it's worth -- since scroll values are automatically loaded after VBlank (Loopy_T -> Loopy_V) if the screen is on. If you're leaving rendering off for the first few lines you'll have to set Loopy_V manually by clever $2006 writes then turn on the screen -- and you'll have to time it consistently -- you miss the right scanline on a frame here and there and the screen will shake. And you'll have to time it without the aid of Sprite 0, or MMC3 IRQs -- making it quite troublesome.

Also, setting the Y scroll to 8 will just chop 8 more lines off the top (is that what you want to do?) -- effectively making the top 16 scanlines invisible to the player -- along with shifting the entire screen up 8 pixels (unless you don't turn on the screen until scanline 8 -- if that's what you meant disregard this paragraph)

No real reason to do anything fancy -- I mean just center the player on the screen or whatever and do scrolling normally. If a tiny bit of tile wrapping occurs, it probably won't be visible.

Although -- cutting the screen off early and turning off the PPU for the bottom scanlines can be advantageous, since you can use those extra scanlines for more VBlank time.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

What I meant by setting the y scroll to 8 is having 1 empty row at the top and one at the bottom AND have them share the same attributes AND not draw to this space until the screen moves (so it works like a buffer...). This way, when the level starts the player will see a screen made up of complete 16x16 pixel blocks. If I simply draw the 1st block at the very top of the nametable, (and y scroll set to 0) this block will have the top half cut off.

Now that I think about it, I seems a bit stupid to worry about this... I guess I could just draw the whole thing and change it 2 rows at a time as the player moves... a TV would mask it off anyway... no need to set up anything special at the beginning, right?

Thanks for the replies on this!
Post Reply