[justin3009]

Kind of hard to shorten the title but I think the basic idea of it is there.

What I'm trying to do now is implement a HUD in Super Mario Brothers 2 similar to SMW.  Not really similar per se, but at LEAST have an HUD on screen that can display score, current lives, etc.. without having to use the pause menu for that.

Obviously the only available BG for that kind of data is BG3.  The problem with that is that BG3 is used quite consistently throughout the whole game and it moves around quite a bit so I'm not sure how to go about this.

I've been told before, awhile back I believe, that Super Mario World uses BG3 for the HUD and background stuff as well but the HUD is 'locked' in place.  I'm not entirely sure how to do that or how to go about making that work in all honesty.  All I know is having an HUD would be greatly beneficial and I'm just not sure how to go about adding it in without it deciding to scroll off screen.  There's also the issue of having it appear ABOVE both Layer 1 AND 2.

[Nightcrawler]

It won't be easy, but you could use HDMA to lock scrolling for a small top section of screen on that background. You can also point BG3 temporarily to another VRAM area and/or tilemap via HDMA too if you need to. That way, you'd have a completely independent HUD that wouldn't interfere with BG3. BG3 would appear clipped at the top there your HUD is.

The second option is to continue the way the game does it already and use sprites. I haven't looked into how much trickery you'd need to add some more static sprites, but where there is a will, there is usually a way.

[justin3009]

I'm trying to avoid using as many sprites as possible due to it causing slow down as more appear.  It shouldn't be THAT much of a problem now since I've made it into FastROM but I'd prefer to go the less sprite route if possible.  It'd free up a few more chunks of the OAM table as well and allow for a lot more customization

The 'ole HDMA method again, darn it.  I still haven't wrapped my head around that when I was pursuing such a method in Breath of Fire 2.  Might be easier to try it on this game since it's far less complex I suppose!
November 19, 2016, 05:30:58 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Double post, it'll probably merge.  Okay, you mentioned the HDMA thing but now I'm extremely confused.

I'm looking at SMB3 which uses ALL background layers including HDMA for the 'Pause' screen.  The HUD is Layer 1 along with a good majority of the background yet the HUD NEVER moves.  There is NO HDMA present on screen unless the pause screen is up.  How is this managed?

[Nightcrawler]

SMB3 doesn't work like SMB2. SMB2 scrolls the BG layers using the hardware registers while SMB3 always keeps BG1 fixed in hardware. So all 'scrolling' in SMB3 on that layer is done via regular tilemap/tiledata updates, which you can see via DMA. The HUD is placed once on the BG and the BG never moves, so the HUD remains static. You can't really apply what SMB3 does to SMB2 because the game engines are fundamentally different in those areas. To simulate that approach, you would have to use HDMA to isolate a portion of the visible screen to work differently then the regular BG handling.

 

[AWJ]

SMB3 doesn't work like SMB2. SMB2 scrolls the BG layers using the hardware registers while SMB3 always keeps BG1 fixed in hardware. So all 'scrolling' in SMB3 on that layer is done via regular tilemap/tiledata updates

Err, what? SNES SMB3 certainly does use the scroll registers. Simulating scrolling by redrawing the entire screen pixelwise every frame would be impossible without a coprocessor.

As for how the HUD is fixed in place in SMB3, it's done with an IRQ that rewrites the BG1 scroll registers on scanline 192... probably because that's how the NES version did it.

OP, are you trying to create a transparent HUD like SMB1 and SMW, or a fully opaque one like SMB3? If you want it to be transparent, you're probably going to have no choice but to use sprites. The thing is that SMB1 doesn't scroll vertically at all, and SMW only uses BG3 for graphics that don't scroll vertically, like the clouds outside the Ghost Houses, so in those games the HUD and the clouds never have to coexist on the same horizontal line. SMB2, on the other hand, uses BG3 for clouds everywhere, including the many areas that do scroll vertically. So if you put a HUD on BG3 it won't be able to coexist with the clouds. The clouds will just have to abruptly disappear at the top or bottom of the screen (whichever side you put the HUD on) which kinda spoils the whole "transparency" effect.

[Nightcrawler]

Err, what? SNES SMB3 certainly does use the scroll registers. Simulating scrolling by redrawing the entire screen pixelwise every frame would be impossible without a coprocessor.

I misspoke. That sentence was intended to refer to the software LEVEL scrolling (which is in tiles) rather than the hardware background scrolling. I was pointing out SMB3 and SMB2 utilize the hardware background layers differently (and in a different manner in relation to their level scrolling). Thus, the same approach won't work. I just made an incorrect jumble pile of words for what I was trying to say. Once more haste makes for waste! Thanks for clarifying and saving poor Justin a brain explosion.

[justin3009]

If I wanted to use the BG I'd probably have to go with the HUD on the bottom and shift everything on screen upwards a bit if I decide to go that route.  I wouldn't mind a sprite route but could become a huge issue down the road especially with the OAM table and such.  I could probably work something out but I feel like the less sprites, the better considering how much is often on screen at once.