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
iNCEPTIONAL

Regarding SNES' object limitations

Post by iNCEPTIONAL »

Just to double checking something I think some people said in another thread: The SNES can display 128 objects onscreen in any of the available sizes (8x8, 16x16, 32x32 and 64x64, with two sizes at a time), so it could technically have 128 64x64 objects onscreen at once (not all unique, obviously), even though there's clearly going to be a LOT of dropout due to the objects/tiles per scanline limit and the like, correct?
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Regarding SNES' object limitations

Post by jeffythedragonslayer »

If you consider invisible or glitched dropped-out sprites to be displayed, sure that sounds okay to me. Megacat studios has written about the limits:
Sprites per Scanline: 32. This is a hard limit. On top of that only 34 8x8 tiles can be displayed regardless of how big the sprites are. This is related to the next limit.

Sprite Pixels per Scanline: 256. This means no matter how many sprites are there, after 256 pixels the PPU starts cutting off sprites. The renderer always clips the frontmost (lower id) sprites.
https://megacatstudios.com/blogs/retro- ... guidelines
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Regarding SNES' object limitations

Post by lidnariq »

Sprite pixels per scanline is 34·8=272, not 256.
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Regarding SNES' object limitations

Post by jeffythedragonslayer »

lidnariq wrote: Wed Jun 29, 2022 6:07 pm Sprite pixels per scanline is 34·8=272, not 256.
Huh, I'll believe you over a magic number because you gave a derivation haha :lol:
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

jeffythedragonslayer wrote: Wed Jun 29, 2022 6:03 pm If you consider invisible or glitched dropped-out sprites to be displayed, sure that sounds okay to me. Megacat studios has written about the limits:
Sprites per Scanline: 32. This is a hard limit. On top of that only 34 8x8 tiles can be displayed regardless of how big the sprites are. This is related to the next limit.

Sprite Pixels per Scanline: 256. This means no matter how many sprites are there, after 256 pixels the PPU starts cutting off sprites. The renderer always clips the frontmost (lower id) sprites.
https://megacatstudios.com/blogs/retro- ... guidelines
Well, let's put it like this, some people say the SNES can't have more than four or maybe five enemies at once in scrolling beat 'em ups because it's too "slow", yet there's a SNES Turtles in Time "Arcade Edition" hack that has up to ten enemies onscreen at once but with glitching (a bit too much with ten enemies but acceptable with seven, I'd say). So, for the sake of this argument, yeah, I'll count a bit of glitching. Now, it would be FAR beyond reasonable once you get to the extreme example I'm talking about, but, technically speaking, it can do 128 64x64 sprites. This is also a lot more than 80 32x32 sprites on the Genesis, which is the kind of thing I like to keep in mind when designing my own game as part of the goal is try and do things that show off the SNES' strengths in whatever areas. And I just wanted to check that was the case.
Last edited by iNCEPTIONAL on Mon Jul 18, 2022 3:18 pm, edited 1 time in total.
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Regarding SNES' object limitations

Post by jeffythedragonslayer »

Well I wouldn't recommend arguing with conviction on that point with anyone (if proving someone wrong is that important to you) until you've tested a rom that does it - I am simply pointing out that your thought process makes sense. As we just learned from lidnariq it's not always the best to just quote what someone else has said about the SNES' limitations.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

I was the one who said you'd get slowdown with over 80 sprite objects. The issue is the CPU speed, not the PPU's sprites per line limit.

Even with the most optimal code, you just don't have enough time per frame to process all objects every frame, though you could split half of the sprite game logic / collision checks over 2 frames, and get a full 128 sprite objects moving independently, they would essentially be functioning at 30 frames per second instead of 60.

I probably also recommend not using 64x64 sprites, just because they can't scroll off the top and bottom of the screen without noticable wrap around. Unless you can be sure those 64x64 sprites are staying away from the top/bottom edges, then they are fine.

In any case it doesn't make a difference to the CPU what size the sprites are (ie won't cause slowdown).
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

It should be noted that with the addition of an SA-1 (aka Super Accelerator) chip, that a game should have no trouble handling 128 sprite objects per frame.

SA-1 hacks to remove slowdown have been very popular in the past year or so.


Though... really... you don't need that many sprites. Certainly not 128 different 64x64 sprites. You can fill the entire screen with only 16 sprites at 64x64 size. You can fill the entire screen with 56 sprites at 32x32.
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 »

64x64 sprites have limited use in in-game situations, unless you really need all that coverage. There will be a lot of wasted empty tiles with many normal gameplay objects and it is better to compose the game sprite out of multiple smaller hardware sprites to reduce the wasted tiles and need to juggle them into VRAM etc.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

TmEE wrote: Thu Jun 30, 2022 8:02 am 64x64 sprites have limited use in in-game situations, unless you really need all that coverage. There will be a lot of wasted empty tiles with many normal gameplay objects and it is better to compose the game sprite out of multiple smaller hardware sprites to reduce the wasted tiles and need to juggle them into VRAM etc.
This is obviously true.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

dougeff wrote: Thu Jun 30, 2022 5:54 am I was the one who said you'd get slowdown with over 80 sprite objects. The issue is the CPU speed, not the PPU's sprites per line limit.

Even with the most optimal code, you just don't have enough time per frame to process all objects every frame, though you could split half of the sprite game logic / collision checks over 2 frames, and get a full 128 sprite objects moving independently, they would essentially be functioning at 30 frames per second instead of 60.

I probably also recommend not using 64x64 sprites, just because they can't scroll off the top and bottom of the screen without noticable wrap around. Unless you can be sure those 64x64 sprites are staying away from the top/bottom edges, then they are fine.

In any case it doesn't make a difference to the CPU what size the sprites are (ie won't cause slowdown).
Pretty sure someone in here already provided me with a demo of 128 sprites (8x8 I think) moving around at 60fps (I think) on SNES, as I recall. If whomever it was recalls that, maybe they could post it in here again. I could possibly hunt it out. . . .

Edit: It was 128 16x16 sprites at 60fps actually: viewtopic.php?p=279342#p279342 (Thanks 93143 for that)

So, unless there's something I'm missing here, there's that.

But, yeah, I get what you're saying in the other comment about it not actually being practical to use so many 64x64 sprites and so on, and I obviously agree. It was just something I was curious about on a purely numbers level for my own curiosity.
Last edited by iNCEPTIONAL on Thu Jun 30, 2022 1:25 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 »

With absolutely minimal movement code, and nothing else going on... I agree, 128 is possible.

I notice also that there's never any adjustment of the OAM high table, which greatly simplifies and speeds up the sprite update per frame. OAM high table = changing sprite size (small vs large), and moving a sprite to a negative X position, so you can scroll it off the left edge of the screen. These things are optional but you lose some flexibility, if you can never change them.

I like this demo. It's nice to see someone pushing the limits. ..... making a game that can do this... good luck with that.

Edit... look at this demo again and tell you you need that many sprite objects. You don't. It's too much. You can't play a level with this many things flying around.
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

dougeff wrote: Thu Jun 30, 2022 12:56 pm With absolutely minimal movement code, and nothing else going on... I agree, 128 is possible.

I notice also that there's never any adjustment of the OAM high table, which greatly simplifies and speeds up the sprite update per frame. OAM high table = changing sprite size (small vs large), and moving a sprite to a negative X position, so you can scroll it off the left edge of the screen. These things are optional but you lose some flexibility, if you can never change them.

I like this demo. It's nice to see someone pushing the limits. ..... making a game that can do this... good luck with that.

Edit... look at this demo again and tell you you need that many sprite objects. You don't. It's too much. You can't play a level with this many things flying around.
Well, from asking about that demo, you could have two normal background layers, a few of the objects for characters, and then the rest of the objects for say a hundred or so toys being thrown out of the proverbial pram in a scene something like this (at least just as an end sequence without any necessary gameplay taking place): https://youtu.be/U8btNneN8ew?t=24573

I personally would have been blown away if I'd seen a scene like this with around one hundred or so objects being thrown out of the proverbial pram after beating Baby Bowser.

But, yeah, it's clearly way more objects than you'd ever need in most practical scenarios--but not for my intended purpose, which is, as usual, to show off the SNES' strengths vs the competition in various areas.
Last edited by iNCEPTIONAL on Mon Jul 18, 2022 3:21 pm, edited 2 times in total.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

jeffythedragonslayer wrote: Thu Jun 30, 2022 2:51 am Well I wouldn't recommend arguing with conviction on that point with anyone (if proving someone wrong is that important to you) until you've tested a rom that does it - I am simply pointing out that your thought process makes sense. As we just learned from lidnariq it's not always the best to just quote what someone else has said about the SNES' limitations.
Well, true, but it's also useful stuff to know, and every console's numbers are theory until someone tests them, and until that point, if one console has higher numbers than the others, it's a good starting point imo. I mean, if I have more sprites to work with on paper, I'd like to show that off in actual practice at some point. And, for me, that's a win.
Last edited by iNCEPTIONAL on Mon Jul 18, 2022 3:23 pm, edited 1 time in total.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

64x64 is not just impractical - it's useless. It really is. There should NEVER be a situation were you purposely would choose 64x64 as a sprite size option when you already have 128 OAM entries (four 32x32 aren't going to "break the bank", as well as cell line limit) and since you only have two sprite size options at a time.

The only time where 128 16x16 sprites becomes advantageous, is some edge case design (shmup with only tiny objects). I mean as a trade-off in relation to not having other immediate sizes like 32x16 and 16x32, etc. Otherwise, you need that many entries to make up for it having more than two sizes at once. So 128 isn't advantageous so much as it's a crutch to over come a different issue.

So +1 for some super edge case, -1 for almost every other use cases (if we're comparing against the Genesis.. which all these threads seem to be about. But even the PCE!).
Locked