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.
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:49 pmSo, 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/
Only if the lines with no snowflakes on them also have no sprites that are not snowflakes. Which in that game doesn't seem to be the case.

The only way that could work is if the advanced technique I haven't tried yet turns out to be viable, which I don't expect it to.

turboxray wrote: Tue Jul 05, 2022 5:08 pmforce blanked
solid color line
Forced blank on SNES isn't simply "solid color"; it's black.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

93143 wrote: Tue Jul 05, 2022 7:16 pm
iNCEPTIONAL wrote: Tue Jul 05, 2022 4:49 pmSo, 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/
Only if the lines with no snowflakes on them also have no sprites that are not snowflakes. Which in that game doesn't seem to be the case.

The only way that could work is if the advanced technique I haven't tried yet turns out to be viable, which I don't expect it to.

turboxray wrote: Tue Jul 05, 2022 5:08 pmforce blanked
solid color line
Forced blank on SNES isn't simply "solid color"; it's black.
It's not color #0 of sprite 0, like on the PCE?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Regarding SNES' object limitations

Post by rainwarrior »

turboxray wrote: Tue Jul 05, 2022 8:03 pmIt's not color #0 of sprite 0, like on the PCE?
The NTSC NES had a palette #0 blanking colour, but when they made the PAL version it seems they didn't want the large visible overscan area to have varying colour, which might have been distracting in the many games that change it. Instead they made at least the overcan consistently black. I think that line of reasoning carried forward to the SNES, but to all blanking and not just overscan.
crabking
Posts: 7
Joined: Thu Jun 30, 2022 5:13 am

Re: Regarding SNES' object limitations

Post by crabking »

kulor wrote: Tue Jul 05, 2022 9:45 am
iNCEPTIONAL wrote: Thu Jun 30, 2022 11:51 pm 128 64x64 >>> 80 32x32
I think you might be underestimating how useful sprite multiplexing can be on the Genesis: https://rasterscroll.com/mdgraphics/gra ... r-effects/
It works entirely because the Genesis reads the sprite table from a location in VRAM, instead of having dedicated RAM for it like the SNES. I've seen it suggested that the Genesis can feasibly use this "hack" to actually display more sprites than the SNES, in a perfectly viable and flexible way.

I think this game use the same trick in this scene for the falling foliage.

Image
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

crabking wrote: Wed Jul 06, 2022 7:28 am
kulor wrote: Tue Jul 05, 2022 9:45 am
iNCEPTIONAL wrote: Thu Jun 30, 2022 11:51 pm 128 64x64 >>> 80 32x32
I think you might be underestimating how useful sprite multiplexing can be on the Genesis: https://rasterscroll.com/mdgraphics/gra ... r-effects/
It works entirely because the Genesis reads the sprite table from a location in VRAM, instead of having dedicated RAM for it like the SNES. I've seen it suggested that the Genesis can feasibly use this "hack" to actually display more sprites than the SNES, in a perfectly viable and flexible way.

I think this game use the same trick in this scene for the falling foliage.

Image
I'm curious, is that ground effect just done with same method used on most racing games of that era combined with a simple cycling palette on the rainbow and a few sprites for the trees or whatever they are? Is that basically all there is to it?
User avatar
kulor
Posts: 33
Joined: Thu Mar 15, 2018 12:49 pm

Re: Regarding SNES' object limitations

Post by kulor »

iNCEPTIONAL wrote: Tue Jul 05, 2022 5:01 pm 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?
As far as we're currently aware, it's not possible. The main issue is that you can't access VRAM (including OAM RAM) outside of blanking, but hblank is when the PPU is caching sprite data. Someone in the discord put together a ROM trying to quickly blast over a few sprite changes during hblank, which did work on emulators, but it lead to nasty looking visible artifacts on real hardware. The only way to change sprites mid-frame is to blank for some number of lines.
So basically, Genesis does, but you can't do this on Nintendo.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

kulor wrote: Wed Jul 06, 2022 1:18 pm
iNCEPTIONAL wrote: Tue Jul 05, 2022 5:01 pm 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?
As far as we're currently aware, it's not possible. The main issue is that you can't access VRAM (including OAM RAM) outside of blanking, but hblank is when the PPU is caching sprite data. Someone in the discord put together a ROM trying to quickly blast over a few sprite changes during hblank, which did work on emulators, but it lead to nasty looking visible artifacts on real hardware. The only way to change sprites mid-frame is to blank for some number of lines.
So basically, Genesis does, but you can't do this on Nintendo.
Well, it's a shame if it can't be done like this on SNES, but, as I mentioned before, I guess you just have to do similar things a different way on each console sometimes and play more to their particular strengths.

I mean, you can do the extra layer of snow like this with sprite multiplexing on Genesis https://youtu.be/XgnEovu2_HI?t=378 or you can do it like this by using the extra background layer that's available on SNES https://youtu.be/PfkJctxcMBs?t=3190

I would have liked to use the sprite multiplexing for basically a fifth parallax layer in my shmup [at little extra cost] but I was originally planning on just using some of the spare sprites from the 128 that are available for this anyway, so I guess I'll just have to stick with my original idea. Although, I do have an idea to use some animated tiles on two of the four background layers for some additional parallax snow anyway (just like Rare did in DKC), which should look pretty decent when combined with the sprite snowflakes that are currently in the foreground too.

Here's a wee video of exactly what I'm talking about (not including the extra snowflakes that can be added using animated tiles on a couple of the backgrounds layers): https://youtu.be/oCiSEChgjC4
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Regarding SNES' object limitations

Post by psycopathicteen »

Isn't there one guy on here who was trying to figure out the OAM fetching pattern? Any new information?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Regarding SNES' object limitations

Post by psycopathicteen »

viewtopic.php?t=18447

I'm still waiting for these guys to reply to me on that thread. If we can figure out the OAM access pattern we might be able to do sprite multiplexing.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

psycopathicteen wrote: Mon Jul 11, 2022 6:45 pm viewtopic.php?t=18447

I'm still waiting for these guys to reply to me on that thread. If we can figure out the OAM access pattern we might be able to do sprite multiplexing.
It would certainly be awesome if someone could crack this.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

psycopathicteen wrote: Mon Jul 11, 2022 6:45 pm viewtopic.php?t=18447

I'm still waiting for these guys to reply to me on that thread. If we can figure out the OAM access pattern we might be able to do sprite multiplexing.
I thought this was already discussed. IIRC (and it's been years) if no sprites are being fetched during hblank on that given line then, you won't get corruption on that line because there's nothing to show? And parsing OAM, in preparation of the next line, happens during active display - so you''ll be able to have the changes take effect on the next line if the change successfully update during hblank.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

turboxray wrote: Tue Jul 12, 2022 9:21 am
psycopathicteen wrote: Mon Jul 11, 2022 6:45 pm viewtopic.php?t=18447

I'm still waiting for these guys to reply to me on that thread. If we can figure out the OAM access pattern we might be able to do sprite multiplexing.
I thought this was already discussed. IIRC (and it's been years) if no sprites are being fetched during hblank on that given line then, you won't get corruption on that line because there's nothing to show? And parsing OAM, in preparation of the next line, happens during active display - so you''ll be able to have the changes take effect on the next line if the change successfully update during hblank.
As a non-programmer, does that mean it is or is not possible to do sprite multiplexing on SNES?

To me, it sounds like you're saying yes but in a very limited way that wouldn't really be useful in most cases anyway. Although, if you could describe some actual potential use-bases in a game then that might help me understand it better.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Regarding SNES' object limitations

Post by psycopathicteen »

Is this how it works in a summary?

Writes during active display alternate between X and Y position, depending on the toggle. The X position of the sprite doesn't get updated until the Y position does, because of the way the toggling works. During active display all writes go to both the LoOAM and HiOAM at the same time. Writes to HiOAM are not affected by the toggling. Which sprite it updates depends on which cycle/pixel during active display. During H-blank, writes go to either the HiOAM table of whatever sprite is currently being evaluated, with the backmost sprites being evaluated first, or the frontmost sprite of the last scanline to have sprites on it. I'm guessing each sprite always takes two cycles to evaluate, both during active display when it is determining if a sprite is on scanline or not, and during H-blank when it's doing the VRAM pattern fetches.

The stuff I don't know is, what happens if you write TWICE during h-blank? Will it effect X and Y of the corresponding sprite? Or the name/attributes word of the corresponding sprite, or does that depend on either you're writing to an even or odd cycle? Does DMA always occur on even cycles during active display, or does it occur on odd cycles on odd numbered scanlines?
As a non-programmer, does that mean it is or is not possible to do sprite multiplexing on SNES?

To me, it sounds like you're saying yes but in a very limited way that wouldn't really be useful in most cases anyway. Although, if you could describe some actual potential use-bases in a game then that might help me understand it better.
It sounds like it is possible but in very limited and convoluted. Like, you would have to do several runs at precisely the right timing, and have to watch out for the DRAM refresh messing up the timing, although that can probably be overcome by changing the OAM priority rotation setting. I still don't know if it is possible to change the attributes and name, or just the X and Y coordinates.
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Regarding SNES' object limitations

Post by Myself086 »

iNCEPTIONAL wrote: Tue Jul 12, 2022 10:58 am
turboxray wrote: Tue Jul 12, 2022 9:21 am
psycopathicteen wrote: Mon Jul 11, 2022 6:45 pm viewtopic.php?t=18447

I'm still waiting for these guys to reply to me on that thread. If we can figure out the OAM access pattern we might be able to do sprite multiplexing.
I thought this was already discussed. IIRC (and it's been years) if no sprites are being fetched during hblank on that given line then, you won't get corruption on that line because there's nothing to show? And parsing OAM, in preparation of the next line, happens during active display - so you''ll be able to have the changes take effect on the next line if the change successfully update during hblank.
As a non-programmer, does that mean it is or is not possible to do sprite multiplexing on SNES?

To me, it sounds like you're saying yes but in a very limited way that wouldn't really be useful in most cases anyway. Although, if you could describe some actual potential use-bases in a game then that might help me understand it better.
Yes if sprites are disabled for the next line.
No if sprites are enabled for the next line.

The only use case is for split screen with a horizontal black bar between the screens.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

Myself086 wrote: Tue Jul 12, 2022 11:40 am
iNCEPTIONAL wrote: Tue Jul 12, 2022 10:58 am
turboxray wrote: Tue Jul 12, 2022 9:21 am

I thought this was already discussed. IIRC (and it's been years) if no sprites are being fetched during hblank on that given line then, you won't get corruption on that line because there's nothing to show? And parsing OAM, in preparation of the next line, happens during active display - so you''ll be able to have the changes take effect on the next line if the change successfully update during hblank.
As a non-programmer, does that mean it is or is not possible to do sprite multiplexing on SNES?

To me, it sounds like you're saying yes but in a very limited way that wouldn't really be useful in most cases anyway. Although, if you could describe some actual potential use-bases in a game then that might help me understand it better.
Yes if sprites are disabled for the next line.
No if sprites are enabled for the next line.

The only use case is for split screen with a horizontal black bar between the screens.
1. Could you do the multiplexing without the split screen type of design if you had a game where sprites never moved up or down so as to make sure they never overlapped with sprites above or below them and therefore couldn't be affected by what's happening above or below them in code with all the hblank and scanline stuff to achieve the multiplexing?

2. Does a black bar truly have to be visible for this multiplexing on SNES to work at all, or are you just saying that would be the way to do it because then you can basically guarantee the sprites above the bar aren't going to cause any display issues with the multiplexed versions below the bar (plus you can actually use the force blanking time during the black bar to achieve this basically without any hassle at all)?

3. What if, for example, I had a game that was a series of horizontal background platforms and the sprites on the top platform could never move below that, could I then use this multiplexing method on SNES to have a bunch of the duplicate sprites on one of the lower platforms? In fact, to make it even easier to visualize, what if it were just a nice background image and the static word "Repeat" made out of a bunch of 32x32 sprites that I simply wanted to repeated say five times down the screen [without any blank/black scanlines in between] using multiplexing rather than using five times the amount of sprites for the same result?

PS. I really have no clue how all of this works, so I'm probably just talking complete rubbish. Lol
Locked