nesdev.org

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.

DementedPurple wrote:What's sprite zero hit?

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.

gauauu wrote: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.

That StackOverflow answer is a gem. Thanks for sharing.

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

DementedPurple wrote: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 it work if I...

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.

dougeff wrote: it sets a bit in a memory address.

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

DementedPurple wrote:Would it work if I just used a sprite-zero-hit?

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.

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.

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.