Regarding SNES' object limitations

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Locked
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

iNCEPTIONAL wrote: Tue Jul 05, 2022 4:26 pmdoes the forced blanking used to do this type of multiplexing on SNES have to be in between the multiplexed sets of sprites
Of course. There's no way to buffer this; sprites are drawn on every scanline based on what's in OAM at that moment. If you want to multiplex a sprite, you have to overwrite its OAM entry after the PPU has drawn the sprite with the old parameters but before it's drawn the same sprite with the new parameters. This also means that the updated sprite must have a Y-coordinate further down the screen than the old one, otherwise the updated sprite simply won't show up because the PPU will assume it already drew it.
iNCEPTIONAL wrote: Tue Jul 05, 2022 4:30 pmIs there a reason you need to do a full reload vs a partial reload?
Yeah, you need a full reload if you want to change every sprite entry, including the packed data in HiOAM. That's 544 bytes. If you can get away with less, the black bar can be thinner; this depends on the game design.
dougeff wrote: Tue Jul 05, 2022 4:30 pm Do you realize that what you are describing is lots of stripes across the screen where no pixels can display?
Of course. That's why I was talking about forced blanking during HBlank, so as to squeeze a few sprite updates in without having to blank any visible pixels. Obviously this kills or glitches sprite display on the subsequent line, so you'd have to be sure there weren't any.

It's also why I want to try an advanced DMA redirection approach, because it wouldn't be limited in this way. I don't think it's likely to succeed (if it requires half-dot alignment to work, it will at best only be reliable on certain models of SNES), but I don't know for a fact that it won't...
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

Well, it's one stripe in Super Mario Kart
It's 8 pixels tall. Possibly, it could be done in 7 scanlines.
totally acceptable, no?
I would accept just about any SNES homebrew game, as long as it isn't full of swastikas and n-words (as some ROM hacks are)
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

93143 wrote: Tue Jul 05, 2022 4:39 pm Of course. That's why I was talking about forced blanking during HBlank, so as to squeeze a few sprite updates in without having to blank any visible pixels. Obviously this kills or glitches sprite display on the subsequent line, so you'd have to be sure there weren't any.

It's also why I want to try an advanced DMA redirection approach, because it wouldn't be limited in this way. I don't think it's likely to succeed (if it requires half-dot alignment to work, it will at best only be reliable on certain models of SNES), but I don't know for a fact that it won't...
So, if it worked that way and you could actually do it during HBlank, could you use it for drawing say some snowflakes, maybe a just a few on one line (one even), then leave a big enough gap and draw another few (or one), and then a big enough gap again and then another few (or one), achieving ultimately the same general result as seen in Stone Protectors on Genesis for the snow using apparently only three sprites for all the snow you see: https://rasterscroll.com/mdgraphics/gra ... r-effects/

"Here we can see that no two snowflakes are ever on the same horizontal line. More specifically, they are vertically spaced about eight lines."

This being kinda exactly what would be very useful to use in my own game for a bit of falling snow in the iceberg level using very few sprites indeed:
Stone-Protectors-Snow-Isolated-02.png
Stone-Protectors-Snow-Isolated-02.png (7.62 KiB) Viewed 660 times
Last edited by iNCEPTIONAL on Tue Jul 05, 2022 4:59 pm, edited 1 time in total.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

forced blanking during HBlank,
I think I read somewhere that you shouldn't do that. Might corrupt sprite graphics on the next scanline, or something. ??
Last edited by dougeff on Tue Jul 05, 2022 5:28 pm, edited 2 times in total.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: Regarding SNES' object limitations

Post by TmEE »

As far as the multiplexing goes, I perfer to use the recycling instead, I find it more descriptive of the actual process that is generally meant by it. Reusing a sprite that has been rendered by moving it to a new place on the current frame, to get something show up in the new spot.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

TmEE wrote: Tue Jul 05, 2022 4:57 pm As far as the multiplexing goes, I perfer to use the recycling instead, I find it more descriptive of the actual process that is generally meant by it. Reusing a sprite that has been rendered by moving it to a new place on the current frame, to get something show up in the new spot.
Well that's basically what I was talking about. Is that possible on SNES? Is that different to what I mentioned previously, or is it what I said and it's basically either impossible or very difficult on SNES without having the blank scanlines?
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

dougeff wrote: Tue Jul 05, 2022 4:56 pm
forced blanking during HBlank,
I think I read somewhere that you shouldn't do that. Corrupt sprite graphics, or something. ??
Because there's sprite related fetching/calculating going on during hblank, you'll corrupt what's shown on the next line for sprites. Of course, if nothing is supposed to be shown the next line.. is it fine(?) is the question. It doesn't make it that useful, but at least it's something. Though sorting/calculating to use that is going to be complex and convoluted.. I love it! hahah



I think if you can cut the force blanked lines down to 2, and get something like a 40% reload (that's predictable.. like the first 40% of the OAM is reloaded), that's still a viable trick. You can use that solid color line as some sort of transition period, like in a waterline.. such as Bloodlines lake mirror effect (or something more advanced). Still not as nice or as applicable as the Gen/MD multiplexing effect, but anything is better than nothing.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

Found this relevant thread, which mentions Uniracers writing to OAM somehow midframe.

viewtopic.php?f=12&t=15108
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

I mean, to be fair to SNES, let's say someone used that admittedly very cool multiplexing technique seen in Stone Protectors to add a bunch of additional snowflakes to the game, like this: https://youtu.be/XgnEovu2_HI?t=378

The SNES can still use its entire extra background 3 layer plus a handful of spare sprites to achieve this: https://youtu.be/PfkJctxcMBs?t=3190

So I guess it really is all about taking advantage of each system's strengths and weaknesses effectively.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

I think the Donkey Kong example is a better alternative. Use a BG layer for 95% of the snow, and a few sprites for 5% to give it some variety (when you see a larger snowflake fly across)
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

dougeff wrote: Tue Jul 05, 2022 5:17 pm Found this relevant thread, which mentions Uniracers writing to OAM somehow midframe.

viewtopic.php?f=12&t=15108
Well, I don't understand much at all of what they're saying but it sounds to me like the example I just gave regarding "multiplexing" one snowflake every bunch of scanlines for a simple show effect would indeed be possible, I think. So, that's interesting to me at least, if I got that right. It means I could take literally one object and have I think 28 snowflakes falling on top of the rest of my visuals (redrawing it every 8 scanlines so no crossover), at the cost of a single object. And then I could just use a few more sprites to have a handful of normally drawn snowflakes for extra effect. If even that can be done, that's significant success imo.
Last edited by iNCEPTIONAL on Tue Jul 05, 2022 5:37 pm, edited 1 time in total.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

dougeff wrote: Tue Jul 05, 2022 5:27 pm I think the Donkey Kong example is a better alternative. Use a BG layer for 95% of the snow, and a few sprites for 5% to give it some variety (when you see a larger snowflake fly across)
Well, yeah, totally. :D

Although, in my game, I'm already using all four layers for the other background elements in the game, so this would give me a simple "5th" layer of snowflakes too if possible (and even more parallax). I'd be well up for that. My current method is to simply waste maybe 32 8x8 sprites for the same simple snow layer effect, but, if this works, I could do the snow with a little multiplexing instead, and with less worry about managing not having too many sprites per scanlines too.

If possible, that would be a total win for me personally.

I mean, in reality I'll probably just use some sprites as even finding someone who could and/or would do this is likely nigh-impossible anyway, but it's at least interesting to consider potential possibilities.
Last edited by iNCEPTIONAL on Tue Jul 05, 2022 5:49 pm, edited 1 time in total.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

Uniracers writes to OAM in 2 player mode, and there is a black bar across the middle of the screen when force blank is used... for 2 scanlines... and it only does 1 write to OAM, and I'm not exactly sure why, because there aren't that many sprites on screen.

Looking at the sprite viewer in MESEN-S, it looks like it is writing to the hi table to flip the 9th X bit and swap 2 sprites OFF screen and 2 sprites ON screen.
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

By the way, total tangent but does anyone know how the dynamic divider line is being done here (just thought of it because of all the talk of forced blank between the sprite multiplexing): https://youtu.be/bNuZ43biKBM?t=531

It's just a rather cool effect, and looking at it in Mesen-S seems to suggest a whole part of one background layer is somehow reserved and used just to draw the pink dividing line or something?

I know it's basically using one background for each player's view (and lots of nice line/row scrolling), with the level perfectly duplicated on each of those backgrounds, and background 3 is used for the HUD as per usual, but beyond that I don't really understand how any of it is done. Although I do know the same effect looks a bit crap on Genesis, so the SNES is obviously doing something slightly different and maybe a little unique here.
Last edited by iNCEPTIONAL on Tue Jul 05, 2022 6:28 pm, edited 2 times in total.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

dougeff wrote: Tue Jul 05, 2022 4:42 pm I would accept just about any SNES homebrew game
I hear you on that.
Locked