So, regarding the sprites per scanline . . .

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

So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

The SNES can handle 32 sprites per scanline [and display as max of 34 8x8 sprite tiles and 272 sprite pixels per scanline] according to all the resources I've seen online (that's how they describe it). So, just like the total sprites onscreen conversation I had previously (which was really more like total objects the SNES can handle/process in memory/code at maximum, or however you would describe it), is this 32 sprites per scanline number technically true at any of the available object sizes*, as in it simply represents what the SNES can handle/process at maximum in memory/code [or however you would describe it] irrespective of object size, or, does that 32 number of sprites per scanline that the SNES can handle/process in memory/code [or however you would describe it] actually go down when you use the larger object sizes?

*Yes, I'm aware there would be blatant drop-out/flickering beyond the 34 8x8 sprite tiles and 272 sprite pixels per scanline display limits if I tried to display say 32 32x32 sprites on a scanline for example, obviously.

Basically, ignoring any obvious drop-out/flicker that would occur and not talking about what you would see on the actual display output for a moment, is the SNES technically capable of "handling" 32 sprites per scanline regardless of the object size, or is it 32 sprites per scanline only at a specific object size (8x8) but actually less sprites per scanline at any of the other object sizes (16x16 and above)?

Again, I know there's going to be obvious drop-out/flicker if you actually try to display too many sprites per scanline [at any size], so that's not what I'm concerned with in terms of what I'm asking.

I hope it's clear what I'm specifically asking here.

Note: There is a possibility that I'm slightly confused here and all this talk of "sprites per scanline limit" is not actually a direct SNES hardware technical specification/function/limitation at all (unlike the max objects onscreen), and it is literally just being used as a simple way to describe what you can directly see before any drop-out/flicker occurs in the visible game when output to the display--basically, "You'll see some flicker if you put too many sprites on a scanline, purely because the system only has a resolution of 256 pixels horizontally and you obviously can't show more pixels than that in a row onscreen, but you could, in principle, technically put all 128 objects on a scanline at a purely hardware/code level as some random internal testing-of-the-system's-limits programming exercise", or something like that--in which case, just let me know that's the case.
Last edited by iNCEPTIONAL on Sat Jul 30, 2022 1:39 pm, edited 3 times in total.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: So, regarding the sprites per scanline . . .

Post by TmEE »

* SNES only has time to parse 128 sprites on one line, there's no memory bandwidth or memory itself to have more, this sets the maximum sprite count possible, ignoring the other limits :
** Pick out 32 sprites it deems visible on that line (regardless of size) and store their parameters in a list for the actual render process later. This is done by comparing current scanline with sprite Y position and its height. Similarly there's no room or time to do any more work to support additional sprites.
*** Render up to 256+8+8 pixels, there isn't bandwidth left to fetch any more pixels from VRAM. Sprite width and X position plays a role here, aswell as order of discovery of visibility as it sets the inter-sprite priority.
iNCEPTIONAL

Re: So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

TmEE wrote: Sat Jul 30, 2022 5:13 am * SNES only has time to parse 128 sprites on one line, there's no memory bandwidth or memory itself to have more, this sets the maximum sprite count possible, ignoring the other limits :
** Pick out 32 sprites it deems visible on that line (regardless of size) and store their parameters in a list for the actual render process later. This is done by comparing current scanline with sprite Y position and its height. Similarly there's no room or time to do any more work to support additional sprites.
*** Render up to 256+8+8 pixels, there isn't bandwidth left to fetch any more pixels from VRAM. Sprite width and X position plays a role here, aswell as order of discovery of visibility as it sets the inter-sprite priority.
OK, so, technically 32 sprites per scanline at any of the available object sizes (8x8/16x16/32x32/64x64), but the other limitations mean it will always end up with the max amount of allowed/visible pixels being displayed horizontally regardless, even if that means having to clip/drop some sprites on the scanline to achieve this, which makes sense. And, obviously, in any real game scenario, if you don't want your sprites getting randomly clipped/dropped and want to avoid any ugly flickering (at least beyond an acceptable minimum), you'd try to make sure you don't go over the 32 sprites, 34 8x8 sprite tiles and 272 sprite pixels per scanline limits as just a matter of good design.
TrekkiesUnite118
Posts: 92
Joined: Fri Mar 08, 2013 5:56 pm

Re: So, regarding the sprites per scanline . . .

Post by TrekkiesUnite118 »

Just a heads up, this is again from him replying to comments of mine on a youtube video about a Turtles in Time ROM hack that has more enemies. He asked how it well it ran on real hardware and I replied "If Ares is any indication, it has pretty bad flickering and slowdown." He came back saying "It still proved the point he was trying to make" and that flickering wasn't a big deal. So I linked him this: https://www.youtube.com/watch?v=ooHzxmEENeo

So that's probably where this question is coming from.

@iNCEPTIONAL Since I assume you want to know how it stacks up, the specs for Genesis in H40 mode are as follows as far as I'm aware:
80 Sprites total
20 Sprites per scanline
40 8x8 Sprite tiles per scanline
320 Sprite pixels per scanline
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: So, regarding the sprites per scanline . . .

Post by Dwedit »

Sprites won't drop out (flickering instead) if the sprite order is cycled, but then priority gets messed up.
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: So, regarding the sprites per scanline . . .

Post by 93143 »

Or, in H32 mode:

64 Sprites total
16 Sprites per scanline
32 8x8 Sprite tiles per scanline
256 Sprite pixels per scanline

The Mega Drive has slightly less % screen coverage than the SNES in both modes - 100% instead of 106.25%. But it supports more tiles/pixels per scanline in H40 mode than the SNES does, due to the higher resolution of that mode.

The reason for this is that the VDP switches clock speeds to do the resolution change, so everything scales with the resolution, including VRAM bandwidth and even DMA (the Mega Drive's DMA unit is on the VDP, not the CPU).

H32 mode is used primarily for games involving heavy CPU rendering; since the CPU does not change speed with the screen mode, the lower pixel count makes it quicker to render a frame. There's not really any other advantage to H32 unless you're porting something or running a Master System game, so traditional tile-based games like Sonic The Hedgehog and Alien Soldier tend to use H40 mode.
iNCEPTIONAL

Re: So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

Just a heads up, this thread literally has nothing at all to do with that Trekkie dude above. I was thinking about this long before he ever came into existence--look at my posts on most of the videos about this stuff on YouTube and you'll see they start from months to years back--and I was recently simply wanting to clarify in my head exactly how this particular feature works on SNES.

It's actually an extension on this post that I was querying about elsewhere: https://atariage.com/forums/topic/33866 ... -256-mode/

Note: What's the bets an [alt] account for this dude magically appears in that forum soon and he starts positing there now too. . . .

And it's also because I was thinking about exactly why there's lots of dropout/flickering in some of the recent SNES beat 'em up hacks, despite it apparently being able to show 32 sprites per scanline. I've mentioned those hacks in here on numerous occasions, and long before I ever talked to this dude in here.

As far as I'm aware, I've not talked to this guy on YouTube in ages, since literally that whole thread went to hell a couple of weeks ago, or however long it was--unless he's using some troll account with another name on YouTube and/or I didn't even recognise it was him--so nothing about this thread has anything to do with him in the slightest.

I'm entitled to ask reasonable questions around how SNES works here, and indeed how Genesis works in other dedicated Genesis forums, and I shouldn't have to deal with this random constantly stalking me.

Edit: Apparently I did respond to him, as he indicated below.

But, before I get the [sole] blame once again, maybe someone should go find that video and see who engaged who first, again, or how it all came about: https://www.youtube.com/watch?v=Rf2Gbfl ... e4kYjEolsi

Also, feel free to check my Twitter and see all this "spamming" of said video he's claiming (vs just typical and harmless posting on a "social" media site like Twitter): https://twitter.com/inceptionalnews?lang=en-GB

The guy has a personal agenda, and he's happy to paint whatever distorted picture that suits his narrative, forcing me to literally go on the defensive and look down exact posts I made and when and what I said and the context it was said in, etc, in fear of getting banned in here.

He'll keep making additional comments in here with more spurious claims, knowing I said I won't respond to him again, and hoping the narrative sticks due to no one else bothering to check what he's saying and what's actually happened in reality and the context of it, and hoping they just trust he's telling the truth about me and my motivations, partly based on the fact people have already made their minds up about me in here, and some of it, as we [the mods and I] already know, based on some very insidious articles created specifically about me and with very deliberate heinous intentions.

But, like I said, I clearly didn't even notice who I was replying to in that YouTube video's comments section (notice how relatively polite everything was), which shows how much I actually pay attention to this stuff or desire to keep some random in my short-term memory as if they are of any importance to me beyond some posts in some random moment, so this thread is not about him or anything he is saying. He just happens to be one of many people I'm responding to in countless posts on YouTube, in here, on various forums, on Twitter, etc.

Check every comment in this thread prior to the guy's arrival, and see if it's all sinister and evil. . . .

Check the general direction things are going in now and the unease in the air after his arrival, and consider whether my curiosity about and questions regarding the various systems in here is even remotely on par with his obvious intention here. . . .

I've seen multiple random iNCEPTIONAL clone accounts pop up on YouTube posting flame-bait comments recently (dudes called "inceptional hypocrisy" https://www.youtube.com/channel/UCL5fbN ... _hsACNPAYQ and "delusional" (both using my copyrighted logo for their pictures too), and guess where my thoughts on who's possibly behind that are going now. . . .

Seriously, actually follow the absurdity of one example of this person's "conversation" with me, and decide it I'm being an ass (or lying or manipulating the truth or whatever vs just talking about the facts as I understand them) or if they're being all insidious, trolling and flame-baity: https://www.youtube.com/watch?v=ytNUcBY ... YIF4AaABAg (should be at the top)

I might have some strong opinions on SNES (which I am entitled to have), and even big-up the SNES sometimes too, but we're not even in the same universe of disturbed.

Mods, if you can at least warn him, before some flame war starts and somehow I once again get the blame. I'll ignore him from now on in here, but you can also do your job and not let him turn this into a debacle once again.
Last edited by iNCEPTIONAL on Tue Aug 02, 2022 12:42 am, edited 29 times in total.
TrekkiesUnite118
Posts: 92
Joined: Fri Mar 08, 2013 5:56 pm

Re: So, regarding the sprites per scanline . . .

Post by TrekkiesUnite118 »

iNCEPTIONAL wrote: Sat Jul 30, 2022 12:36 pm As far as I'm aware, I've not talked to this guy on YouTube in ages,
You literally replied to me yesterday:
Image
iNCEPTIONAL

Re: So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

93143 wrote: Sat Jul 30, 2022 12:04 pm Or, in H32 mode:

64 Sprites total
16 Sprites per scanline
32 8x8 Sprite tiles per scanline
256 Sprite pixels per scanline

The Mega Drive has slightly less % screen coverage than the SNES in both modes - 100% instead of 106.25%. But it supports more tiles/pixels per scanline in H40 mode than the SNES does, due to the higher resolution of that mode.

The reason for this is that the VDP switches clock speeds to do the resolution change, so everything scales with the resolution, including VRAM bandwidth and even DMA (the Mega Drive's DMA unit is on the VDP, not the CPU).

H32 mode is used primarily for games involving heavy CPU rendering; since the CPU does not change speed with the screen mode, the lower pixel count makes it quicker to render a frame. There's not really any other advantage to H32 unless you're porting something or running a Master System game, so traditional tile-based games like Sonic The Hedgehog and Alien Soldier tend to use H40 mode.
Ah, that's interesting, because I was curious about why Sega would just drop the numbers lower in the 256 mode, when it would have been even better to have all the other specs the same but with less screen estate to cover in 256 mode.
TrekkiesUnite118
Posts: 92
Joined: Fri Mar 08, 2013 5:56 pm

Re: So, regarding the sprites per scanline . . .

Post by TrekkiesUnite118 »

iNCEPTIONAL wrote: Sat Jul 30, 2022 12:36 pm Apparently I did respond to him, as he indicated below. but maybe someone should go find that video and see who engaged who first again, or how it all came about.
Sure, it's this video here:
https://www.youtube.com/watch?v=Rf2Gbflgxus

It came about because you've been spamming that video at people on Twitter in regards to SNES and Genesis beat'em ups, new Genesis homebrew projects, etc. and one of them eventually made it's way onto my twitter feed. I clicked the video, tried the ROM out, saw you asking how it ran on the real thing in the comments and said "If Ares is any indication, it flickers and slows down pretty badly."

EDIT: To be clear I didn't say this was about me or anything like that. I simply pointed out this is again coming from a console war discussion else where so people know what it's about and what direction it's going.
iNCEPTIONAL

Re: So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

Dwedit wrote: Sat Jul 30, 2022 12:03 pm Sprites won't drop out (flickering instead) if the sprite order is cycled, but then priority gets messed up.
Do you know if this sprite order cycling feature was used often in SNES games?

I was looking at a couple of ROM hacks where there was a lot of stuff onscreen but also lots of flickering, and I wasn't sure if this could be improved by using the SNES' sprite order cycling routine or if it already was being used in those examples and that was about as good as it was going to get regarding the flickering.

Here's some examples I've been looking at and wasn't sure about:

https://youtu.be/Zo2l0NxqKUs
https://youtu.be/d8c2OwrcwMA
https://youtu.be/Rf2Gbflgxus
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: So, regarding the sprites per scanline . . .

Post by turboxray »

iNCEPTIONAL wrote: Sat Jul 30, 2022 1:36 pm
Dwedit wrote: Sat Jul 30, 2022 12:03 pm Sprites won't drop out (flickering instead) if the sprite order is cycled, but then priority gets messed up.
Do you know if this sprite order cycling feature was used often in SNES games?

I was looking at a couple of ROM hacks where there was a lot of stuff onscreen but also lots of flickering, and I wasn't sure if this could be improved by using the SNES' sprite order cycling routine or if it already was being used in those examples and that was about as good as it was going to get regarding the flickering.
Do you like NES games? :lol:

Z-priority-fighting isn't particular nice to look at.. especially for beat'em up games. If you can limit it down to one meta-object that's causing it, and there's some cases where you can apply it to just between two meta-objects. But this is easier said than done for beat'em up games because of how z-priority for the characters works. You'd need smarter enemy swarm/anti-swarm AI for it to be more effective. You're better off coming up with a system that identifies "hot spots" and drop the cells you want (even cycle them!).. and not let the PPU decide for you. But that requires cpu resource. SA-1 territory probably.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: So, regarding the sprites per scanline . . .

Post by dougeff »

Screenshot_20220730-185142_Chrome.jpg
Keep off-forum drama off forum.
nesdoug.com -- blog/tutorial on programming for the NES
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: So, regarding the sprites per scanline . . .

Post by turboxray »

iNCEPTIONAL wrote: Sat Jul 30, 2022 12:36 pm Just a heads up, this thread literally has nothing at all to do with that Trekkie dude above. I was thinking about this long before he ever came into existence--look at my posts on most of the videos about this stuff on YouTube and you'll see they start from months to years back--and I was recently simply wanting to clarify in my head exactly how this particular feature works on SNES.

It's actually an extension on this post that I was querying about elsewhere: https://atariage.com/forums/topic/33866 ... -256-mode/

Note: What's the bets an [alt] account for this dude magically appears in that forum soon and he starts positing there now too. . . .

And it's also because I was thinking about exactly why there's lots of dropout/flickering in some of the recent SNES beat 'em up hacks, despite it apparently being able to show 32 sprites per scanline. I've mentioned those hacks in here on numerous occasions, and long before I ever talked to this dude in here.

As far as I'm aware, I've not talked to this guy on YouTube in ages, since literally that whole thread went to hell a couple of weeks ago, or however long it was--unless he's using some troll account with another name on YouTube and/or I didn't even recognise it was him--so nothing about this thread has anything to do with him in the slightest.

I'm entitled to ask reasonable questions around how SNES works here, and indeed how Genesis works in other dedicated Genesis forums, and I shouldn't have to deal with this random constantly stalking me.

Edit: Apparently I did respond to him, as he indicated below.

But, before I get the [sole] blame once again, maybe someone should go find that video and see who engaged who first, again, or how it all came about: https://www.youtube.com/watch?v=Rf2Gbfl ... e4kYjEolsi

Also, feel free to check my Twitter and see all this "spamming" of said video he's claiming (vs just typical and harmless posting on a "social" media site like Twitter): https://twitter.com/inceptionalnews?lang=en-GB

The guy has a personal agenda, and he's happy to paint whatever distorted picture that suits his narrative, forcing me to literally go on the defensive and look down exact posts I made and when and what I said and the context it was said in, etc, in fear of getting banned in here.

He'll keep making additional comments in here with more spurious claims, knowing I said I won't respond to him again, and hoping the narrative sticks due to no one else bothering to check what he's saying and what's actually happened in reality and the context of it, and hoping they just trust he's telling the truth about me and my motivations, partly based on the fact people have already made their minds up about me in here, and some of it, as we [the mods and I] already know, based on some very insidious articles created specifically about me and with very deliberate heinous intentions.

But, like I said, I clearly didn't even notice who I was replying to in that YouTube video's comments section (notice how relatively polite everything was), which shows how much I actually pay attention to this stuff or desire to keep some random in my short-term memory as if they are of any importance to me beyond some posts in some random moment, so this thread is not about him or anything he is saying. He just happens to be one of many people I'm responding to in countless posts on YouTube, in here, on various forums, on Twitter, etc.

Check every comment in this thread prior to the guy's arrival, and see if it's all sinister and evil. . . .

Check the general direction things are going in now and the unease in the air after his arrival, and consider whether my curiosity about and questions regarding the various systems in here is even remotely on par with his obvious intention here. . . .

I've seen multiple random iNCEPTIONAL clone accounts pop up on YouTube posting flame-bait comments recently (dudes called "inceptional hypocrisy" https://www.youtube.com/channel/UCL5fbN ... _hsACNPAYQ and "delusional" (both using my copyrighted logo for their pictures too), and guess where my thoughts on who's possibly behind that are going now. . . .

Seriously, actually follow the absurdity of one example of this person's "conversation" with me, and decide it I'm being an ass (or lying or manipulating the truth or whatever vs just talking about the facts as I understand them) or if they're being all insidious, trolling and flame-baity: https://www.youtube.com/watch?v=ytNUcBY ... YIF4AaABAg (should be at the top)

I might have some strong opinions on SNES (which I am entitled to have), but we're not even in the same universe of disturbed.

Mods, if you can, remove him from this comments section, or at least warn him, before some flame war starts and somehow I once again get the blame. I'll ignore him from now on in here, but you can also do your job and not let him turn this into a debacle once again.
Are you just gonna keep editing this post.. making it larger and larger????
iNCEPTIONAL

Re: So, regarding the sprites per scanline . . .

Post by iNCEPTIONAL »

By the way, my thinking around how the whole sprite order cycling should work, at least as I understand it, would be that it's changing the sprite order 60 times per second across probably five, six or even seven large characters onscreen (potentially made up of multiple objects horizontally), so the flickering probably shouldn't actually be that noticeable if it's done right. I mean, it's possible to flicker a single sprite on and off 60 times per second and it creates a relatively smooth effect of the sprite just being semi-transparent, so long as the framerate is steady. If that's happening across multiple sprites at 60fps, I would imagine the flickering effect would actually be pretty unnoticeable or you'd just see a little bit of semi-transparency on each character whenever it happens, like 20% transparency or something like that (depends on the amount of characters in a row, but it would obviously have to be enough to cause any flickering in the first place). But I might not be visualising how it would work in practice entirely accurately. I'd need to actually see it clearly working in a real example, and one where it's executed correctly and optimally, to properly decide for myself.
Last edited by iNCEPTIONAL on Sat Jul 30, 2022 5:04 pm, edited 1 time in total.
Post Reply