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.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

iNCEPTIONAL wrote: Thu Jun 30, 2022 4:59 pm
turboxray wrote: Thu Jun 30, 2022 4:01 pm
iNCEPTIONAL wrote: Thu Jun 30, 2022 1:58 pm All the online documents say the Genesis can display a maximum of 80 8x8-32x32 sprites (even the total fanboy ones), just as the SNES documents say it can display 128 sprites (and apparently up to 64x64 in size, but absolutely up to 16x16 at the very least, which has been very effectively demonstrated by 93143 to be 100% true).
Well.. 'Display' is a loose term. It's from the perspective of how many entries the SAT/OAM is accessible during active display - and not as literal as it sounds. It was never in question that the SNES can't hold 128 and display 16x16 entries from a sPPU perspective. The SNES definitely can not show 128 6x64 sprites. And the Genesis definitely can not show 80 32x32. Your line limit, accumulated across all scanlines - wouldn't be enough. 'Clipping' doesn't count, because then they aren't '64x64' or '32x32' intact.

Someone in the comments (or maybe the other thread), already mentioned looking at this in the perspective of 'screen coverage'. I think this is a really good metric for looking at sprites sizes vs sat/oam size - to get a round about understanding of capability. PCE for instance only has 64 entries, but it has '32x64' size as the largest. A lot of games use that size, but can you display all '32x64' on screen at the same time? The SAT can hold all of them, but again like the SNES and Genesis the line limit would prevent you from seeing all of them as-is. So technically, no. From a screen coverage perspective, the Genesis and PCE surpass the requirement - they can have more sprite pixel data that can be shown/seen on screen. The snes in 16x16|8x8 more cannot. You have to jump to 16x16|32x32 and mostly use 32x32 cells to get there.

But, okay, here we go. I guess you're going to go about sprite multiplexing on Genesis or some other hack like that, right? And that's somehow not possible on SNES too, right? "Genesis can do a bazillion sprites!" I mean, Super Mario Kart certainly doesn't do anything remotely like that at all: https://youtu.be/K7gWmdgXPgk?t=767
Sure, here we go. You can update the SAT entries on whatever scanline and you don't need to force blank the frame into parts like the SNES - on the Genesis. So no, it doesn't have some convoluted arbitrary limitations like the SNES. So it's actually practical and useful. It's not a hack. You literally just update an entry. And a few games use it.

Mario Kart doesn't do what I'm referring to, and doesn't have the capability that I'm referring to. I mean even the PCE can do a forced blank SAT reload like what Mario Kart is doing (and with just a two line-gap separation). Again, neither of those are the same thing.
So, it would seem that what I am saying should be technically possible: Way more than 16 64x64 objects onscreen but with lots of clipping and dropout.
Then you're NOT showing 64x64 objects, are you? It's a totally ridiculous metric you're forcible trying to justify. You're getting into the realm of bullshit.. we get enough of that from sonicretro tech site hahah
It all just sounds really blah blah blah to me: The SNES can show 128 8x8-16x16 sprites for loads more onscreen sprites total than the other consoles as standard--FACT. The SNES can show enough big sprites to cover the entire screen too--FACT. The SNES can show lots of sprites onscreen in general, in actual games during actual gameplay, and enough of them doing enough stuff to have loads of intense action going on, as perfectly demonstrated in the two examples I provided (Super Smash TV and Rendering Ranger)--FACT. The rest is really all just meaningless gibberish because some people want to pretend the Genesis can do absolutely everything the SNES can do and indeed do it all better, but it can't; it can do SOME things the SNES can do and SOME of them it can do better, while others it cannot do at all and some things it simply does worse--FACT

So, if people want to keep arguing numbers on paper and continue to try and convince all the world the Genesis is this infinite beast that just beats the SNES no matter what: 128 objects onscreen (up to 64x64 in size) >>> 80 objects onscreen (up to 32x32 in size), as per the official documentation and not counting various hacks that BOTH machines are capable of in many different ways to manipulate those numbers.

Nintendoes what Genesis doesn't--FACT.

Here's another thing the SNES can do as standard that the Genesis cannot EVER do: Four fully overlapping full background layers.

Here's something else the SNES can do as standard that the Genesis simply cannot do: Proper colour math for actual transparency on both sprites and backgrounds.

Here's one more thing the SNES can do as standard that the Genesis just can't (I've certainly never seen it even come close): Full background rotation, scaling and skewing on as many as four separate player views at once (ala Street Racer's 4-player mode).

Here's another thing the SNES does as standard that is impossible on Genesis: Max 512x448 resolution (and in-game at that).

Here's another thing the SNES does as standard that the Genesis just cannot do: Eight channels of PCM audio. It can't do surround sound either--The SNES can.

Here's yet another thing the SNES does as standard that the Genesis doesn't even manage with its pay-extra-for-it controller, never mind the 3-button meh that comes in the box: A controller with a d-pad plus six actions buttons plus a Start button plus a Select button, and in a setup that allows for a whole load of versatility in how it's used (trying intuitively strafing in Doom while turning and firing at the same time on Genesis and let's see how good that feels--Oh, wait, there is no version of Doom for the actual Genesis. Well, try it on the 32X version. . . .).

Just as the Genesis has its strengths and does some things that the SNES can't touch, the SNES has many of its own strengths and can do a bunch of things that the Genesis can't touch, and I think Genesis defenders need to get over it and just accept the SNES actually beats the Genesis sometimes and in some meaningful ways--God forbid.

It's okay for Genesis fanboys to actually admit the Genesis can and does lose sometimes--the world will not collapse.

The SNES won the console war and for many good reasons. Genesis fanboys need to get over it and stop trying to re-write the narrative thirty years too late. They lost--FACT.
My experience isn't "numbers on paper" -- FACT. I can code, and do write code for these old consoles (as well write my own emulation), you barely understand what's even presented in front of you, let alone the questions you ask -- FACT. The level of irony is at maximum, of you, telling me, what's what -- FACT. You're the acting like the SNES version of sonicretro rolled into a user -- FACT. Your responses are now just amounting to butthurt fodder -- FACT. Seriously, just stop. Are you interested in facts, context, capability or just a inaccurate crusade? I seriously thought you were moving beyond this stuff... smh. I don't care who won the console war. Matter of fact, I won it! Because I owned and played all these systems (and still do). I only care facts and capability in context. Controllers? Wars? what...
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

93143 wrote: Thu Jun 30, 2022 4:22 pm
turboxray wrote: Thu Jun 30, 2022 4:01 pmPCE for instance only has 64 entries, but it has '32x64' size as the largest. A lot of games use that size
SNES can do 32x64 and 16x32 as well. Vertical flipping isn't correct, and I'm not sure any game used them (they were unofficial), but they're there.
Yeah, I remember the unofficial ones. Was it tested with every sPPU revision? I remember some system tests showed it wasn't 100% reliable (like the unofficial OR mode 'transparency' mode on the Genesis that launch systems can't do).. but that was like 10 years ago.
From a screen coverage perspective, the Genesis and PCE surpass the requirement - they can have more sprite pixel data that can be shown/seen on screen. The snes in 16x16|8x8 more cannot. You have to jump to 16x16|32x32 and mostly use 32x32 cells to get there.
You don't have to use adjacent sprite sizes. My game uses 8x8 and 32x32.
It's just an example. IMO, 16x16|32x32 is generally more practical.. but obviously depends on what you're making. The point was, you need the larger 32x32 size to get the coverage.
And yeah, I would really really love to be able to specify the axes independently per sprite. It would make a lot of the things I'm doing so much easier. But it's working okay, and at least one of my workarounds has a material benefit...
Yeah, but I mean it's like that with any system haha. It's more interesting to design implementations to over come whatever limitations. Or at least the challenge is more fun.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

turboxray wrote: Thu Jun 30, 2022 7:20 pm My experience isn't "numbers on paper" -- FACT. I can code, and do write code for these old consoles (as well write my own emulation), you barely understand what's even presented in front of you, let alone the questions you ask -- FACT. The level of irony is at maximum, of you, telling me, what's what -- FACT. You're the acting like the SNES version of sonicretro rolled into a user -- FACT. Your responses are now just amounting to butthurt fodder -- FACT. Seriously, just stop. Are you interested in facts, context, capability or just a inaccurate crusade? I seriously thought you were moving beyond this stuff... smh. I don't care who won the console war. Matter of fact, I won it! Because I owned and played all these systems (and still do). I only care facts and capability in context. Controllers? Wars? what...
128 64x64 >>> 80 32x32

PS. Show me where what I said in the previous quoted comment wasn't a fact--not the bits that are obviously just my opinion of why some people are saying what they are saying--and then you can attempt to tell me what I do and do not know or understand and have it carry any weight with me whatsoever.

Or, you can say nothing more on it, since I've already had my original thread question answered by a few other people and don't need or want any more of your input on it, and we can stop the warring as the guy below requested. Thanks.
Last edited by iNCEPTIONAL on Fri Jul 01, 2022 12:44 am, edited 8 times in total.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Regarding SNES' object limitations

Post by Fiskbit »

Please keep the YouTube-comment-style fanboy console warring on YouTube.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

93143 wrote: Thu Jun 30, 2022 1:50 pm
dougeff wrote: Thu Jun 30, 2022 12:56 pm With absolutely minimal movement code, and nothing else going on... I agree, 128 is possible.
Did you notice that each sprite is lit if and only if it overlaps at least one other sprite? That's not a hardware feature on SNES.

The movement code isn't a particularly large fraction of the available compute time.
Regarding your 128 16x16 sprites simultaneously bouncing around onscreen and lighting each other up at 60fps demo*, theoretically, how would that be affected if you'd used 64x64 sprites instead? And similar question if you went with 32x32 sprites.

I don't mean in terms of dropout/flickering, which would obviously be a total visual mess, but more in terms of how much that one change would affect the speed of things and lead to any potential slowdown and the like.

*viewtopic.php?p=279342#p279342
Last edited by iNCEPTIONAL on Fri Jul 01, 2022 1:59 pm, edited 2 times in total.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

It wouldn't affect slowdown. It costs the CPU nothing to say "large sprites should be 64x64 in size" vs "large sprites should be 16x16 in size". That's just 1 number you need to change in 1 register. Nothing else is different, except maybe the measurements for collision detection will be larger... but it's the same math, just with a bigger number.
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

dougeff wrote: Fri Jul 01, 2022 6:12 am It wouldn't affect slowdown. It costs the CPU nothing to say "large sprites should be 64x64 in size" vs "large sprites should be 16x16 in size". That's just 1 number you need to change in 1 register. Nothing else is different, except maybe the measurements for collision detection will be larger... but it's the same math, just with a bigger number.
OK, good to know.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

93143 wrote: Thu Jun 30, 2022 1:50 pm
dougeff wrote: Thu Jun 30, 2022 12:56 pm With absolutely minimal movement code, and nothing else going on... I agree, 128 is possible.
Did you notice that each sprite is lit if and only if it overlaps at least one other sprite? That's not a hardware feature on SNES.

The movement code isn't a particularly large fraction of the available compute time.
Curious, does your demo run in SlowROM 2.68 MHz mode or FastROM 3.58 MHz mode (if that's applicable here)?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

dougeff wrote: Fri Jul 01, 2022 6:12 amIt wouldn't affect slowdown.
Actually, I think it might be somewhat faster (more compute time left in the frame) with larger sprites. There would be more overlaps, and the algorithm I used likes overlaps. Don't quote me on this; I haven't tested it.

Doing the collision checks naïvely gets you single-digit frame rates. Kannagi tried it (with 60 fps movement, but you can tell the collisions are slower). The SNES can't do a collision check in 6 cycles, so you have to get clever if you want 128x128 collision at 60 fps.
iNCEPTIONAL wrote: Fri Jul 01, 2022 1:58 pmCurious, does your demo run in SlowROM 2.68 MHz mode or FastROM 3.58 MHz mode (if that's applicable here)?
It's FastROM. It wouldn't have worked in SlowROM; as it stands it uses over 90% of the frame at peak load.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

93143 wrote: Fri Jul 01, 2022 2:23 pm
dougeff wrote: Fri Jul 01, 2022 6:12 amIt wouldn't affect slowdown.
Actually, I think it might be somewhat faster (more compute time left in the frame) with larger sprites. There would be more overlaps, and the algorithm I used likes overlaps. Don't quote me on this; I haven't tested it.

Doing the collision checks naïvely gets you single-digit frame rates. Kannagi tried it (with 60 fps movement, but you can tell the collisions are slower). The SNES can't do a collision check in 6 cycles, so you have to get clever if you want 128x128 collision at 60 fps.
iNCEPTIONAL wrote: Fri Jul 01, 2022 1:58 pmCurious, does your demo run in SlowROM 2.68 MHz mode or FastROM 3.58 MHz mode (if that's applicable here)?
It's FastROM. It wouldn't have worked in SlowROM; as it stands it uses over 90% of the frame at peak load.
OK. Cool cool.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Regarding SNES' object limitations

Post by Dwedit »

Doom on MS DOS used a "Blockmap" to reduce the number of collision checks. There's a grid of "blocks", and objects are grouped inside of that block together, and you only check against those. Doom also happened to have some missed collisions for when objects went from one block to another.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

That's why instead of only checking sprites in the same block, I also check sprites in adjacent blocks that could possibly overlap the current sprite.

I've been playing Doom lately, and I think I've been blockmapped a few times. It's really annoying, and if I ever make a SNES re-port I will use a more robust method.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

93143 wrote: Fri Jul 01, 2022 10:40 pm That's why instead of only checking sprites in the same block, I also check sprites in adjacent blocks that could possibly overlap the current sprite.

I've been playing Doom lately, and I think I've been blockmapped a few times. It's really annoying, and if I ever make a SNES re-port I will use a more robust method.
Please make a SNES re-port of Doom. :D
Last edited by iNCEPTIONAL on Sat Jul 02, 2022 3:30 am, edited 1 time in total.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

I've been tossing ideas around, but it's a lot of work and I'm booked solid. We'll see what happens, but don't hold your breath.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

93143 wrote: Fri Jul 01, 2022 11:54 pm I've been tossing ideas around, but it's a lot of work and I'm booked solid. We'll see what happens, but don't hold your breath.
I'm gonna blimmin' well hold my breath. . . . :-P
Locked