Sprite Zero Detection for HUD at bottom of screen [4.1]

After watching the video tutorials I understand a bit better how sprite zero detection works, but I don't think it is intended for the way I designed my HUD.

My HUD is at the very bottom of the screen, below the play area. I think the sprite zero detection assumes that HUD is at the top and play area underneath. It seems like my play area flashes/updates very rapidly and causes lag.
Is there any way to swap the order?
 

Kasumi

New member
I'll start with the short version: Sprite 0 and HUDs at the bottom aren't a very good fit for each other.

Longer: The NES' Picture Processing Unit (its graphics processor) renders pixels from left to right, top to bottom while the CPU runs in parallel. As you've probably learned from the video, when an opaque pixel of sprite 0 overlaps an opaque pixel of the background, the PPU sets a bit the CPU can detect, so the scroll position can be changed in the middle of a frame. However, due to the order the PPU renders in, the further down the screen this occurs, the longer the CPU has to wait. And while the CPU is waiting, it can't really do much else. (Like run logic for the gameplay.) So the lower down your HUD is, the less time you have for gameplay. That probably explains the lag.

Some cartridge types allow for detecting the PPU at a specific point in a way that doesn't require waiting, so lower HUDs would not steal time from gameplay. Mapper 30 does not have anything like this. There's another way to do something similar to what you get on cartridges that can detect what the PPU is doing, but I've never fully understood how it works enough to actually do it.

Changing what the PPU is doing mid screen usually requires really, really specific timing. There are four writes to change the scroll midscreen (at least, in the super fine way), and the last two must fall in a very specific time period in between rendering horizontal rows of pixels. (The horizontal blank, or hblank period.) If they don't, lots of weird stuff can happen. (Flashes.) And you may wonder how the writes could be mistimed only sometimes if the sprite 0 hits at the same time every time. The answer is because the PPU runs faster than the CPU, and margins between the bit getting set and the CPU actually being able to recognize it are finicky. NES Maker may not actually do the four write version, but still midscreen PPU updates are usually finicky business.
 

Mugi

Member
you could try and put together a sprite hud.
Jorotroid made an awesome sprite hud for 4.0.11 that displayed HP and i believe what he used as weapon energy meter (think bullets.) but im pretty sure more could be added to it with some extra code.
I made a variation of the sprite HUD for HP that counts up to 8HP (smaller code, simple logic) and implemented it yesterday on 4.1.0.
it doesnt rely on sprite zero and works quite well with scrolling.

here's what mine looks like: (HP only, my game doesnt use anything else.)
https://www.youtube.com/watch?v=V1cc1yXip3s
 

Jacotomo

Member
I put my hud on the bottom, and had the same problem. I also noticed that whenever I tried to enter the screen above, I would end up somewhere totally different.

Thankfully, this isn't a big deal (for me, anyways), and can be fixed just by moving it to the top.
 
Top Bottom