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.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

turboxray wrote: Thu Jun 30, 2022 1:38 pm 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!).
I would and indeed will use it when some Genesis fanboy tells me one more time how the SNES is "slow" or rubbish or can't display as many sprites onscreen as Genesis or whatever. 128 64x64 >>> 80 32x32. Nintendoes what Genesis doesn't!

And I don't know about the exact numbers but there's a lot of sprites onscreen here and with absolutely not slowdown, and I'm certainly not complaining: https://youtu.be/Tl7D25I6yDc?t=1182 and https://youtu.be/Tl7D25I6yDc?t=1367

I quiet appreciate appreciate the amount of sprites they're throwing around at high speed without any slowdown here too: https://youtu.be/yXMNkIK4fI0?t=173

And this is still dang impressive (128 16x16 sprites bouncing around and lighting each other up when they overlap), especially on the "slow" SNES that apparently can't show as many sprites onscreen as Genesis (because of just how "slow" it is), even if you can't appreciate it: viewtopic.php?p=279342#p279342 (Thanks 93143 for that)
Last edited by iNCEPTIONAL on Thu Jun 30, 2022 2:13 pm, edited 8 times in total.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

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.
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 1:47 pm
turboxray wrote: Thu Jun 30, 2022 1:38 pm 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!).
I would and indeed will use it when some Genesis fanboy tells me one more time how the SNES is "slow" or rubbish or can't display as many sprites onscreen as Genesis or whatever. 128 64x64 >>> 80 32x32. Nintendoes what Genesis doesn't!
You do know... the Genesis can show more than 80 sprites, right???
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

turboxray wrote: Thu Jun 30, 2022 1:53 pm
iNCEPTIONAL wrote: Thu Jun 30, 2022 1:47 pm
turboxray wrote: Thu Jun 30, 2022 1:38 pm 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!).
I would and indeed will use it when some Genesis fanboy tells me one more time how the SNES is "slow" or rubbish or can't display as many sprites onscreen as Genesis or whatever. 128 64x64 >>> 80 32x32. Nintendoes what Genesis doesn't!
You do know... the Genesis can show more than 80 sprites, right???
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). 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
Last edited by iNCEPTIONAL on Thu Jun 30, 2022 2:22 pm, edited 2 times in total.
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Regarding SNES' object limitations

Post by jeffythedragonslayer »

iNCEPTIONAL wrote: Thu Jun 30, 2022 1:32 pm
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 have you seen how absurd some of the SNES vs Genesis arguments get online, especially on YouTube. I'll take what I can get. LOL
A wise YouTuber once said (don't remember who, this was at least 10 years ago) that he thinks console war arguments are people avoiding buyer's remorse. If you convince yourself the other console has no redeeming qualities you don't feel bad that you bought the wrong one.

I could always say "well you can software render everything in Mode 3 and do that in an enchancement chip so the SNES can do that actually."
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

jeffythedragonslayer wrote: Thu Jun 30, 2022 2:13 pm
iNCEPTIONAL wrote: Thu Jun 30, 2022 1:32 pm
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 have you seen how absurd some of the SNES vs Genesis arguments get online, especially on YouTube. I'll take what I can get. LOL
A wise YouTuber once said (don't remember who, this was at least 10 years ago) that he thinks console war arguments are people avoiding buyer's remorse. If you convince yourself the other console has no redeeming qualities you don't feel bad that you bought the wrong one.

I could always say "well you can software render everything in Mode 3 and do that in an enchancement chip so the SNES can do that actually."
He's probably correct.

To be fair, after all the stuff I've learned about Genesis in the last few years, even I have to admit I'm more impressed with just how capable it is than I ever was in the past. When it comes to 3D, I'm actually kinda blown away by what's it can do. I wish some Genesis fanboys could appreciate the SNES and some of the amazing things it can do similarly.

But I've learned enough about SNES in the last two year too, and I've gathered a lot of examples of it doing some really cool stuff, so I'm able to hold my own.
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Regarding SNES' object limitations

Post by Myself086 »

iNCEPTIONAL wrote: Thu Jun 30, 2022 1:47 pm I would and indeed will use it when some Genesis fanboy tells me one more time how the SNES is "slow" or rubbish or can't display as many sprites onscreen as Genesis or whatever. 128 64x64 >>> 80 32x32. Nintendoes what Genesis doesn't!
You can't show 128 64x64 on screen because you're limited to 34 tiles per scanline. You can only show up to 12 full 64x64 or 16 horizontally full 64x64 before the next one cuts off horizontally and the one after that doesn't show at all.

My overly simplified answer is 15.87109375 64x64. Almost 16!
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

Myself086 wrote: Thu Jun 30, 2022 2:28 pm
iNCEPTIONAL wrote: Thu Jun 30, 2022 1:47 pm I would and indeed will use it when some Genesis fanboy tells me one more time how the SNES is "slow" or rubbish or can't display as many sprites onscreen as Genesis or whatever. 128 64x64 >>> 80 32x32. Nintendoes what Genesis doesn't!
You can't show 128 64x64 on screen because you're limited to 34 tiles per scanline. You can only show up to 12 full 64x64 or 16 horizontally full 64x64 before the next one cuts off horizontally and the one after that doesn't show at all.

My overly simplified answer is 15.87109375 64x64. Almost 16!
I don't specifically know how the drop-out works, if it's an entire object that suddenly gets removed as soon as anything goes over the objects per scanline limit, or if it's just as many 8x8 tiles as needed to not go over the limit. If it's just as many 8x8 tiles as needed to not go over limit then I don't see why you technically couldn't have many 64x64 objects overlapping in rows and columns with some bits of each disappearing every frame, especially because the SNES apparently has some object priority cycling routine thing to somewhat help with this very issue*. The SNES can fill the entire screen with using 16 64x64 objects right next to each other as far as I know, 4 up by 4 across to cove the whole screen, but what if there's many more of them onscreen than that and they're overlapped by quite some margin and only small parts of each are getting dropped out every frame in some cycling clipping priority loop? Again, I dunno exactly how it works but that seems like it would possible to me.

*https://youtu.be/sheOZ-Dlleo?t=266

Edit: Actually, I do know that only parts of larger objects are dropped out if there's too many objects per scanline: https://youtu.be/sheOZ-Dlleo?t=311

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.
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 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
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Regarding SNES' object limitations

Post by Myself086 »

iNCEPTIONAL wrote: Thu Jun 30, 2022 2:44 pm
Myself086 wrote: Thu Jun 30, 2022 2:28 pm
iNCEPTIONAL wrote: Thu Jun 30, 2022 1:47 pm I would and indeed will use it when some Genesis fanboy tells me one more time how the SNES is "slow" or rubbish or can't display as many sprites onscreen as Genesis or whatever. 128 64x64 >>> 80 32x32. Nintendoes what Genesis doesn't!
You can't show 128 64x64 on screen because you're limited to 34 tiles per scanline. You can only show up to 12 full 64x64 or 16 horizontally full 64x64 before the next one cuts off horizontally and the one after that doesn't show at all.

My overly simplified answer is 15.87109375 64x64. Almost 16!
I don't specifically know how the drop-out works, if it's an entire sprite that suddenly gets removed as soon as anything goes over the sprites per scanline limit, or if it's just as many 8x8 tiles as needed to not go over the limit. If it's just as many 8x8 tiles as needed to not go over limit then I don't see why you technically couldn't have many 64x64 sprites overlapping in rows and columns with some bits of each disappearing every frame, especially because the SNES apparently has some sprite cycling thing to somewhat help with this very issue*. The SNES can fill the entire screen with 16 64x64 sprites next to each other as far as I know, 4 up by 4 across, but what if there's many more of them onscreen than that and they're overlapped by quite some margin and only small parts of each are getting dropped out every frame in some cycling loop? Again, I dunno exactly how it works but that seems like it would possible to me.

*https://youtu.be/sheOZ-Dlleo?t=266
34 sprite tiles per scanline. Counted as 8x1, not 8x8. For a total of 272 sprite pixels per scanline.
239 scanlines with over-scan active.
272 pixels/scanline * 239 scanlines = 65008 sprite pixels processed per frame.
65008 / 64 / 64 = 15.87109375
That's where I get my "almost 16" from. I know you told me that you know nothing about math but your arguments are invalid if you can't put proper numbers behind your words. I over simplified to 15.87109375 because you always asked for the most simplified answer possible.

The cycling thing you're talking about is the same as saying 256 sprites on screen by alternating 128 every other frame.
You can show 512 sprites on screen by using the technique that Pac Mac on Atari 2600 uses: https://www.youtube.com/watch?v=wYE1iZOTeI8
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

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.
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.

These are the options: http://problemkaputt.de/fullsnes.htm#snesppuspritesobjs

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...
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

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.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

Myself086 wrote: Thu Jun 30, 2022 4:10 pm
iNCEPTIONAL wrote: Thu Jun 30, 2022 2:44 pm
Myself086 wrote: Thu Jun 30, 2022 2:28 pm
You can't show 128 64x64 on screen because you're limited to 34 tiles per scanline. You can only show up to 12 full 64x64 or 16 horizontally full 64x64 before the next one cuts off horizontally and the one after that doesn't show at all.

My overly simplified answer is 15.87109375 64x64. Almost 16!
I don't specifically know how the drop-out works, if it's an entire sprite that suddenly gets removed as soon as anything goes over the sprites per scanline limit, or if it's just as many 8x8 tiles as needed to not go over the limit. If it's just as many 8x8 tiles as needed to not go over limit then I don't see why you technically couldn't have many 64x64 sprites overlapping in rows and columns with some bits of each disappearing every frame, especially because the SNES apparently has some sprite cycling thing to somewhat help with this very issue*. The SNES can fill the entire screen with 16 64x64 sprites next to each other as far as I know, 4 up by 4 across, but what if there's many more of them onscreen than that and they're overlapped by quite some margin and only small parts of each are getting dropped out every frame in some cycling loop? Again, I dunno exactly how it works but that seems like it would possible to me.

*https://youtu.be/sheOZ-Dlleo?t=266
34 sprite tiles per scanline. Counted as 8x1, not 8x8. For a total of 272 sprite pixels per scanline.
239 scanlines with over-scan active.
272 pixels/scanline * 239 scanlines = 65008 sprite pixels processed per frame.
65008 / 64 / 64 = 15.87109375
That's where I get my "almost 16" from. I know you told me that you know nothing about math but your arguments are invalid if you can't put proper numbers behind your words. I over simplified to 15.87109375 because you always asked for the most simplified answer possible.

The cycling thing you're talking about is the same as saying 256 sprites on screen by alternating 128 every other frame.
You can show 512 sprites on screen by using the technique that Pac Mac on Atari 2600 uses: https://www.youtube.com/watch?v=wYE1iZOTeI8
I don't really know what you're talking about to be honest. All I know is I'm not believing the SNES can't show more than the 16 64x64 objects onscreen that it takes to simply cover the whole screen. Unless someone literally shows me otherwise, it seems to me the SNES can display more than that but just parts of some of the objects will now obviously overlap and simply start to flicker to compensate for going over the objects/tiles per scanline limit. At least going by what this guy says: https://youtu.be/sheOZ-Dlleo?t=261 Even if bits of some of them are flickering, if there's more than 16 64x64 objects on that screen in some form, that is still more than 16 64x64 objects. Now, I have literally no idea how much starts to get clipped once you get up to the 128 64x64 objects range (an absurd amount I have no doubt) but, again, I've been told the machine can technically put that many objects onscreen--and I believe this--but most of the objects are going to be basically invisible for periods or time and/or constantly flickering and so on, assuming they're actually moving around and stuff so they're not just having the same spots always hidden. Technically though, I still count that as 128 64x64 objects on that screen, and, certainly for the sake of the SNES vs Genesis argument, that's the hill I will absolutely die on until someone proves otherwise in a way that is beyond debate. 128 64x64 >>> 80 32x32 (and those are the numbers the official documentation says for each system too).

Like, you have actually taken into account that the sprites can both overlap and indeed move around and change position constantly too, which, even with dropout means sometimes some parts of one sprite will be visible at some times and not at others (affected by priority and position and so on), so this isn't just about how many [non-overlapping and static] sprites it takes to technically cover the full screen, right?

It's like the SNES can't have eleven characters in a row in Turtles in Time because that would go beyond its objects per scanline limit--except it can, with lots of dropout and flickering: https://youtu.be/P0knlRmlAq4 (from 5:36)
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Regarding SNES' object limitations

Post by Myself086 »

iNCEPTIONAL wrote: Thu Jun 30, 2022 5:24 pm Now, I have literally no idea how much starts to get clipped once you get up to the 128 64x64 objects range
15.87109375 / 128 = 0.123992919921875

Meaning that at least 87.6% of your sprite pixels aren't rendered each frame.

You'll need to rotate your OAM over a period of at least 8 frames to show mostly everything on screen.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

Myself086 wrote: Thu Jun 30, 2022 6:32 pm
iNCEPTIONAL wrote: Thu Jun 30, 2022 5:24 pm Now, I have literally no idea how much starts to get clipped once you get up to the 128 64x64 objects range
15.87109375 / 128 = 0.123992919921875

Meaning that at least 87.6% of your sprite pixels aren't rendered each frame.

You'll need to rotate your OAM over a period of at least 8 frames to show mostly everything on screen.
Now, would how and where you move the tiles also affect this percentage on a per-tile basis, like, if you had them all overlapping an equal amount and moving across each other in a very linear and equal way, would that result in each object being more or less likely to get some [partial] visible time than if you did something a bit more random or even novel, like rotating them all around the screen in a kind of circular or wavy motion or all around the edge of the screen with large chucks off screen like some kind of moving multi-object snake border, so they're always changing both position onscreen and how much of them and what parts of them are covered by any other objects?

It's all largely meaningless becuse there's no real practical use for this, but I'm just curious.The thought exercise has some value to me.

Someone should do that experiment, where they actually put 128 64x64 objects onscreen (giving them as much visual variety as possibly within the tileset limitations so it's possible to at least tell some of them apart at a glance, maybe some playing cards would work with the different colours and hearts/spades/clubs/diamonds symbols on them) and then try moving them around the screen in different patterns to just see what happens.

You know, I might even try that in Game Maker or something, just out of pure curiosity, although I'm not a great programmer, so getting them to all move in various patterns is probably a huge undertaking for me and likely not worth the time and effort for the end result.
Locked