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...iNCEPTIONAL wrote: ↑Thu Jun 30, 2022 4:59 pmIt 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--FACTturboxray wrote: ↑Thu Jun 30, 2022 4:01 pmWell.. '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.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).
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.
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.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
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.
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 hahahSo, 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.
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.
Regarding SNES' object limitations
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: Regarding SNES' object limitations
Re: Regarding SNES' object limitations
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.
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.You don't have to use adjacent sprite sizes. My game uses 8x8 and 32x32.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.
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.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...
Re: Regarding SNES' object limitations
128 64x64 >>> 80 32x32turboxray 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...
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.
Re: Regarding SNES' object limitations
Please keep the YouTube-comment-style fanboy console warring on YouTube.
Re: Regarding SNES' object limitations
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.
Re: Regarding SNES' object limitations
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
Re: Regarding SNES' object limitations
OK, good to know.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.
Re: Regarding SNES' object limitations
Curious, does your demo run in SlowROM 2.68 MHz mode or FastROM 3.58 MHz mode (if that's applicable here)?
Re: Regarding SNES' object limitations
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.
It's FastROM. It wouldn't have worked in SlowROM; as it stands it uses over 90% of the frame at peak load.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)?
Re: Regarding SNES' object limitations
OK. Cool cool.93143 wrote: ↑Fri Jul 01, 2022 2:23 pmActually, 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.
It's FastROM. It wouldn't have worked in SlowROM; as it stands it uses over 90% of the frame at peak load.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)?
Re: Regarding SNES' object limitations
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!
Re: Regarding SNES' object limitations
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.
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.
Re: Regarding SNES' object limitations
Please make a SNES re-port of Doom.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.
Last edited by iNCEPTIONAL on Sat Jul 02, 2022 3:30 am, edited 1 time in total.
Re: Regarding SNES' object limitations
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.