How did the score bar in Super Mario Bros. not scroll?

So yeah, How would the scorebar not scroll with the camera? I know that It's in the nametable, because you wouldn't be able to fit that many sprites in a row. So then how does it not scroll? It can't move with the camera because while it can scroll smoothly, the nametable can only fit in one 8x8 box, so if they did this, it would slack behind a back before jumping back into place. I'm confused.

Sprite 0 is the bottom of the coin in the status bar. In NMI, it leaves the scroll set to (0,0), waits for sprite0 hit, waits a precise amount of time to get to hblank, and then sets the scroll value for the rest of the playfield.

The PPU draws the screen line by line from the top, using the scroll registers to help it decide which pixels to draw.

The top of the screen, the scroll is set to 0,0. It waits until just the scoreboard is drawn on the screen, then changes the x scroll. From there on down, the PPU is getting pixels from further to the right.

Changing the x scroll mid-screen is easy, and can be done many times.

What's sprite zero hit? Did they just have to time the code in allingment with the TV?

SMB 1's split scroll is the standard example for how NES split scrolling works. If you google, you'll find lots of answers, which might be preferable to asking it bit-by-bit here. Here's a long and detailed explanation.

Instead of asking this question, you could have googled the term:
http://lmgtfy.com/?q=nes+sprite+zero+hit

The first link leads you to the definition of these words and explains what this does on the NES.

The NES can render 64 sprite tiles in one frame, named sprite 0 to sprite 63. The PPU can also detect when any non-transparent pixels of sprite 0 overlap any non-background-color pixels of the background. The moment a pixel is drawn on screen which contains both a sprite 0 pixel and a bg pixel overlapping, the PPU sets a flag in a register. Games will often wait in a loop, checking the register over and over, and once the register finally shows that flag being set, the game will change the scrolling registers. The effect is that the top of the screen is scrolled one way (in SMB's case, fixed at [0,0]), and the bottom of the screen is scrolled a different way (scrolled with the "camera"), with the "split" occuring at the location of sprite 0 on the screen.

As hinted, this is called a "screen split", and using sprite 0 like this is called the "sprite 0 hit", but you usually just need to say "sprite 0" and we'll know what you mean.

That StackOverflow answer is a gem. Thanks for sharing.

How would that work? Wouldn't writing to the PPU outside of vblank cause corruption?

Well, changing the scroll mid-screen can be seen as a form of corruption, since you are tearing the screen after all, but it's a predictable corruption that can be used to your advantage. If you don't do it at the correct times and places, you may get visual glitches, though.

If you understand how the PPU works and the consequences of accessing each of its registers, you can get away with some PPU manipulations outside of vblank, but since these techniques can be difficult to pull off, even for experienced coders, it's simpler for beginners to assume most of the PPU is off limits during rendering.

Some PPU parameters can be safely changed at any time though, such as the sprite height, pattern table addresses, color emphasis, grayscale mode and background and sprite masking in the leftmost 8 pixels, without screwing up the PPU's rendering process. If you time such changes correctly (usually you'd want them to happen during hblank), you can pull off some interesting effects without any fear of messing up the display.

Would it work if I just used a sprite-zero-hit? Speaking of sprite-zero-hit, it doesn't mention anywhere in the wiki how I would access it. It doesn't say anything about any memory addresses.

My 2016 compo entry used sprite 0 to implement its hud, and the source is on github. Check out https://github.com/dustmop/filthy-kitch ... isplay.asm

The function HudSplitAssign sets the position of sprite 0, and HudSplitWait waits for the hit to happen. You should try playing the game in FCEUX and seeing how the nametable viewer looks.

Would what work?

If the PPU detects sprite #0 over the BG, it sets a bit in a memory address.

The program will have to look for the bit, and decide what to do.

The program also has to set the location of the sprite, which determines when the bit is set...and how far down you want to time an event.

That's really vague, the NES has a lot of memory addresses. Does it depend on what sprite I'm using?

The sprite 0 hit by itself doesn't do anything, its purpose is to let the program know when a specific portion of the image is being drawn, so you can create effects that affect the correct part of the image.


The sprite 0 hit flag is part of the PPU status register, as documented in the wiki. You have to position the very first sprite (i.e. OAM entry 0) in a way that one of its solid pixels overlaps (or underlaps, depending on the state of the priority bit) a solid background pixel. When the PPU renders that pixel, the sprite 0 hit flag will be set, and the game code can detect that by polling the PPU status register ($2002) repeatedly.

Could I have it so that during Vblank, I could put Sprite Zero at the top corner so that I could use Sprite Zero Hit to know when the Vblank is over, and then once it's over, move sprite zero to where I need it to change scroll mid-screen?

No, because once the sprite 0 hit flag is set, it stays that way until the end of the frame (that and changing the OAM mid frame is far from trivial). The good news is that you can still use it to detect the end of vblank, because it gets cleared near the end of vblank (at beginning of the pre-render scanline), along with the sprite overflow flag and the vblank flag (if it hasn't been manually cleared by a $2002 read). So, as long as there was a sprite 0 hit in the previous frame, you can wait for it to be cleared in order to detect the end of vblank. Normally you'd only need that if you had raster effects near the top of the screen, though.

Yes, of course it does. From the link I was pointing you to:




Is there a specific reason why you want to know when vblank is over?
What operations do you want to do that need to be done exactly after vblank?

Usually, you set the scrolling position to 0,0 during vblank for the status bar and then you set it to the actual value when sprite 0 hits.

If you want a second scanline split, you can use the sprite overflow bit for the first split (simply put nine empty sprites at the desired location) and sprite 0 for the second one.
Sprite overflow has some issues though that you need to pay attention to.

I suppose 'memory address' was wrong. The tech docs says it's an 'internal memory'...'control register' on the PPU chip (2C02), which is accessible from the CPU through the $2002 'PPU STATUS' register.

Also, in case you are confused. You can't write to OAM (sprite memory) during rendering. Only during V-blank. And, you SHOULD write to the OAM every frame (during V-blank), as OAM memory is volatile, and corrupts very quickly, if it is not written to. (Most emulators don't do this, but the real NES does).