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
User avatar
kulor
Posts: 33
Joined: Thu Mar 15, 2018 12:49 pm

Re: Regarding SNES' object limitations

Post by kulor »

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.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Regarding SNES' object limitations

Post by rainwarrior »

kulor wrote: Tue Jul 05, 2022 9:45 amhttps://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.
That's a really interesting page. I had been wondering how Bloodlines did that.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

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.
Wikipedia says SNES can do sprite multiplexing: https://en.m.wikipedia.org/wiki/Sprite_multiplexing

So, can the SNES do some form of sprite "multiplexing" too or not?

I know it does some trick in Super Mario Kart to show the sprites in the race on the top part of the screen plus the sprites on the map on the bottom half of the screen, which I presume would go above its limits if it didn't (otherwise, why even bother with it?), but I'm not really sure exactly what trick it's using there other than Retro Game Mechanics Explained saying it is doing some kind of trick to show more sprites: https://youtu.be/K7gWmdgXPgk (watch at 12:46)

I know that systems like the NES, C64, Amiga, Genesis, etc, can do some form of sprite multiplexing, and someone in some forum mentioned something about this regarding Donkey Kong Country on SNES, but I didn't quite understand what they were talking about.

So, can someone in here shed more light on where SNES stands regarding this capability?
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Regarding SNES' object limitations

Post by Dwedit »

I don't think Mario Kart uses all that many sprites? So it wouldn't need to multiplex them.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
iNCEPTIONAL

Re: Sprite multiplexing to surpass the 64 sprite limit

Post by iNCEPTIONAL »

Can the SNES do sprite multiplexing similarly?

Like, let's say I wanted to have loads of snowflakes onscreen in my game without using most of the normal sprites for the effect, which I want to have available for the player and a bunch of enemies, could I use sprite multiplexing on SNES to make a handful of snowflakes appear like many more floating down the screen?

If you want a perfect example of this then check out Stone Protectors on Genesis, which uses this method for the snow: https://youtu.be/XgnEovu2_HI (watch from the 6:04 mark)

And all I want to know is if the same technique can be used on SNES to have way more sprites than usual onscreen too?
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Sprite multiplexing to surpass the 64 sprite limit

Post by dougeff »

Not easily. SNES has the same issues as NES with OAM updates.

The wiki says you can't use HDMA to change OAM.

So, you'd have to do forced blank, probably using IRQs, probably mid screen, so... part of the screen would have blank areas.


edit, I guess this topic was continued here...

viewtopic.php?t=23998
nesdoug.com -- blog/tutorial on programming for the NES
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Regarding SNES' object limitations

Post by Pokun »

SMK uses HDMA to split the screen into a play screen and a map screen or player 2 play screen, not for increasing the number of sprites AFAIK.


Sprite multiplexing is quite a generic term. Multiplexing is when multiple signals are combined into one signal, in the case of sprite multiplexing it's a technique to combine several sprites into one sprite attribute entry (OAM entry in SNES terms) in order to overcome some sort of sprite limitation. So there are many ways to do this with different limitations to overcome, like the sprites-per-scanline limitation (32 on SNES) or the sprites-per-frame limitation (128 on SNES).

The scanline limitation is done by shuffling the OAM entries around every frame so that sprites that are outside the limit will be displayed every other frame, they will flicker but they will at least be visible. About any system that supports 32 sprites/frame or more can do this type of multiplexing, and it's common on NES and older systems which is why they tend to flicker much more than SNES when there are a lot of sprites. The SNES provides a hardware solution to make this easier by allowing to shuffle sprite priorities around instead of whole OAM entries.

The frame limitation multiplexing is typically done on older systems like the C64 which only supports 8 sprites/frame but can apparently also be done on the Megadrive. I would think it should be technically doable with HDMA (just use it to change OAM attributes), but I don't know if it's feasible nor I have I heard of it being used in any SNES game.

About any sprite system can do some sort of sprites/frame multiplexing like alternating entities' sprite usage every frame so that two entities (AKA objects) shares the same OAM entry but both can only use it half the frames. This makes it seem like the sprites/frame limit is doubled but also causes ALL sprites to flicker. I think Tepples' Missile Command clone NES homebrew game Thwaite does this to make more bombs on screen.


Edit: OK I checked the video and he basically explains that the sprites/frame type of sprite multiplexing is doable on the SNES, at least in the way that Super Mario Kart uses it. The sprites on the top screen and on the map screen comes from two separate sets of the 128 sprites (two copies of OAM in RAM). The time between the lines is probably too short for HDMA to rewrite the entire OAM, so the game briefly enables forced blanking to give more graphics update time, resulting in a thick black line in the middle of the screen. This is of course only doable for games that are OK with this thick black line and not something that can be done to simply double the sprites/frame in just any game.
Last edited by Pokun on Tue Jul 05, 2022 2:09 pm, edited 1 time in total.
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 12:13 pmWikipedia says SNES can do sprite multiplexing: https://en.m.wikipedia.org/wiki/Sprite_multiplexing
If you read that, you'll notice that it uses a generous definition of sprite multiplexing, claiming the NES has hardware support for multiplexing on the grounds that it supports 64 sprites total in OAM despite only being able to display 8 of them per scanline.

If you take the NES sprite limit as 8, being the number of sprites the NES can display on a line, this makes some sense. If you take the NES sprite limit as 64 (the size of OAM), multiplexing would have to mean displaying more than 64 sprites onscreen, and I don't think the NES can do that; it certainly has no official hardware support for it.

...

In the context of the SNES, what I think we should mean by multiplexing is the latter - displaying more than 128 sprites by reassigning OAM entries as the screen is drawn. We already know the SNES can display more than 32 sprites onscreen simply by making sure they're at different vertical coordinates, or by shuffling OAM so they flicker instead of just not showing up; that's not an interesting question. The interesting question is: can we make the SNES accept new OAM data during active display?

So far, I don't think anyone has done it. I've been meaning to try something, but it's a tad more complicated than the live CGRAM rewrite trick I used to get DMA direct colour working. If it turns out that the DMA has to target OAM with half-dot precision, it may not be possible to do it reliably even if the data goes in, because on some models of SNES the CPU-to-PPU half-dot alignment is set randomly at boot, and DMA auto-aligns on CPU timing. There was a way around this with DMA direct colour, but with OAM I don't see one.

You can't do the obvious thing, which is rewriting OAM during HBlank - at least, not in the general case. You can do that with CGRAM because it isn't being used when no pixels are actually being rendered to video out. You can do it with VRAM if you use forced blank to stop PPU accesses to VRAM during HBlank - but what are those accesses? Sprite graphics. So you can't safely rewrite VRAM unless there happen to be no sprites on the scanline immediately following the forced-blank HBlank, because if there are they will not load properly. And obviously the same is true of rewriting OAM, with the additional complication that it's a lot harder to come up with a scenario where you can guarantee that there are scanlines with no sprites on them in useful areas of the screen if the scenario is such that you're heavily using OAM. (If you do have a situation where you can guarantee that, yes, I think it's safe to say the SNES can multiplex sprites quite easily.)
otherwise, why even bother with it?
Because there's no other way to trim individual sprites vertically so they don't cross over the screen split.

(Well, there is, but it involves using more sprites and possibly flirting with scanline overload. It takes advantage of the fact that sprite-sprite priority and sprite-BG priority are independent, so that sprite A can be above sprite B even if sprite A is below BG1 and sprite B is above BG1 - in this case, sprite B will have a sprite-A-shaped hole cut in it and BG1 will show through. The solution Super Mario Kart settled on is arguably more elegant.)
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

Super Mario Kart is doing a force blank, as described in the video by the black bar - because you need to be able to reload OAM entries when nothing else is accessing it. This IS multiplexing, but it's not the same sense as Gen/MD multiplexing (or C64 or Amiga sprite multiplexing).

Not all multiplexing is created equally. The Gen/MD version pretty much has no restrictions (at least in the sense that it needs a force blank area) - you don't need to stop ALL drawing of BG and sprites just to update sprite entries.

I believe there is a game on the SNES that reloads some OAM entries mid screen, without the force blank wide bar, but apparently gets really lucky because otherwise you corrupt OAM (I remember Near talking about this) . There were details mentioned somewhere on the forum here.

Pokun wrote: Tue Jul 05, 2022 1:58 pm The scanline limitation is done by shuffling the OAM entries around every frame so that sprites that are outside the limit will be displayed every other frame, they will flicker but they will at least be visible. About any system that supports 32 sprites/frame or more can do this type of multiplexing, and it's common on NES and older systems which is why they tend to flicker much more than SNES when there are a lot of sprites. The SNES provides a hardware solution to make this easier by allowing to shuffle sprite priorities around instead of whole OAM entries.
Cycling entries every other frame is NOT sprite multiplexing. I don't care what anyone says haha. That soo misleading to describing frame alternating OAM/SAT as sprite multiplexing. That's typically referred to as sprite table shuffling or cycling.

There's interframe sprite multiplexing like the MD/C64/Amiga, and then there's interline multiplexing (which IIRC is pretty much ONLY doable on the Amiga. I could be wrong on the C64 though).




@93143 What's the smallest force blank area you can get away with for an OAM reload for SNES? As in the number of scanlines? 2? 3?
Last edited by turboxray on Tue Jul 05, 2022 2:19 pm, edited 1 time in total.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Regarding SNES' object limitations

Post by Pokun »

Sprite attribute table shuffling or cycling is indeed commonly known as sprite multiplexing, it's not my own invention. That's why I'm saying sprite multiplexing is a very generic term for many different things. Multiplexing is generic and has nothing to do if it's per line or per frame.


BTW I added an additional part to my last post but was ninja'd when editing.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

Pokun wrote: Tue Jul 05, 2022 1:58 pm Edit: OK I checked the video and he basically explains that the sprites/frame type of sprite multiplexing is doable on the SNES, at least in the way that Super Mario Kart uses it. The sprites on the top screen and on the map screen comes from two separate sets of the 128 sprites (two copies of OAM in RAM). The time between the lines is probably too short for HDMA to rewrite the entire OAM, so the game briefly enables forced blanking to give more graphics update time, resulting in a thick black line in the middle of the screen. This is of course only doable for games that are OK with this thick black line and not something that can be done to simply double the sprites/frame in just any game.
This might be a stupid question but does the forced blanking used to do this type of multiplexing on SNES have to be in between the multiplexed sets of sprites or whatever when such a technique is employed, or could the forced blanking be activated at the top or bottom of the frame instead, so as not to be particularly noticeable when doing some sprite multiplexing like this?

And if the line does have be somewhere obvious on the screen, technically, could you just do it say every second frame so the line would half as visible? I know this would presumably mean the multiplexing would flicker too, almost like interleaving, but just curious.
Last edited by iNCEPTIONAL on Tue Jul 05, 2022 4:29 pm, edited 1 time in total.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

turboxray wrote: Tue Jul 05, 2022 2:07 pm @93143 What's the smallest force blank area you can get away with for an OAM reload for SNES? As in the number of scanlines? 2? 3?
A full OAM reload, rounded up, takes four scanlines. 544 bytes / 165.5 bytes per line = ~3.287 lines. You'd probably want five lines, with the bottom line being active display but with nothing actually sent to the screen, so as to load sprites properly for the line below that. The lines are just barely too short for a four-line total black area: HBlank + active line + HBlank + active line + HBlank + active line + HBlank is only 3.257 scanlines, so the full table transfer would overlap the start of the OAM scan for the fourth line.

A partial reload could obviously take significantly less time.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

Do you realize that what you are describing is lots of stripes across the screen where no pixels can display?
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:27 pm
turboxray wrote: Tue Jul 05, 2022 2:07 pm @93143 What's the smallest force blank area you can get away with for an OAM reload for SNES? As in the number of scanlines? 2? 3?
A full OAM reload, rounded up, takes four scanlines. 544 bytes / 165.5 bytes per line = ~3.287 lines. You'd probably want five lines, with the bottom line being active display but with nothing actually sent to the screen, so as to load sprites properly for the line below that. The lines are just barely too short for a four-line total black area: HBlank + active line + HBlank + active line + HBlank + active line + HBlank is only 3.257 scanlines, so the full table transfer would overlap the start of the OAM scan for the fourth line.

A partial reload could obviously take significantly less time.
Is there a reason you need to do a full reload vs a partial reload?
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

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?
Well, it's one stripe in Super Mario Kart, so, depending on the situation, it may be totally acceptable, no?

PS. I wonder if this is how the 4-player mode in Street Racer is partly done: https://youtu.be/Hrwjofjexfk?t=117
Locked