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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Regarding SNES' object limitations

Post by psycopathicteen »

Myself086 wrote: Tue Jul 12, 2022 11:40 am
iNCEPTIONAL wrote: Tue Jul 12, 2022 10:58 am
turboxray wrote: Tue Jul 12, 2022 9:21 am

I thought this was already discussed. IIRC (and it's been years) if no sprites are being fetched during hblank on that given line then, you won't get corruption on that line because there's nothing to show? And parsing OAM, in preparation of the next line, happens during active display - so you''ll be able to have the changes take effect on the next line if the change successfully update during hblank.
As a non-programmer, does that mean it is or is not possible to do sprite multiplexing on SNES?

To me, it sounds like you're saying yes but in a very limited way that wouldn't really be useful in most cases anyway. Although, if you could describe some actual potential use-bases in a game then that might help me understand it better.
Yes if sprites are disabled for the next line.
No if sprites are enabled for the next line.

The only use case is for split screen with a horizontal black bar between the screens.
He was talking about the thread I posted. The people in the thread I posted said it is POSSIBLE to write to OAM during active display, but you have to synchronize it with the PPU's internal sprite evaluation.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

I should note that what I was saying earlier about DMA alignment was a bit blinkered. DMA is necessary for the direct colour trick because maximum speed is necessary to produce anything resembling a picture, but for sprite multiplexing it may be possible to use CPU instructions to do the writes. And unlike DMA, CPU instructions do allow dynamic half-dot alignment regardless of the boot condition.

I'm not liking this idea of LoOAM and HiOAM being written simultaneously...
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

iNCEPTIONAL wrote: Tue Jul 12, 2022 11:55 am
Myself086 wrote: Tue Jul 12, 2022 11:40 am
iNCEPTIONAL wrote: Tue Jul 12, 2022 10:58 am

As a non-programmer, does that mean it is or is not possible to do sprite multiplexing on SNES?

To me, it sounds like you're saying yes but in a very limited way that wouldn't really be useful in most cases anyway. Although, if you could describe some actual potential use-bases in a game then that might help me understand it better.
Yes if sprites are disabled for the next line.
No if sprites are enabled for the next line.

The only use case is for split screen with a horizontal black bar between the screens.
1. Could you do the multiplexing without the split screen type of design if you had a game where sprites never moved up or down so as to make sure they never overlapped with sprites above or below them and therefore couldn't be affected by what's happening above or below them in code with all the hblank and scanline stuff to achieve the multiplexing?

2. Does a black bar truly have to be visible for this multiplexing on SNES to work at all, or are you just saying that would be the way to do it because then you can basically guarantee the sprites above the bar aren't going to cause any display issues with the multiplexed versions below the bar (plus you can actually use the force blanking time during the black bar to achieve this basically without any hassle at all)?

3. What if, for example, I had a game that was a series of horizontal background platforms and the sprites on the top platform could never move below that, could I then use this multiplexing method on SNES to have a bunch of the duplicate sprites on one of the lower platforms? In fact, to make it even easier to visualize, what if it were just a nice background image and the static word "Repeat" made out of a bunch of 32x32 sprites that I simply wanted to repeated say five times down the screen [without any blank/black scanlines in between] using multiplexing rather than using five times the amount of sprites for the same result?

PS. I really have no clue how all of this works, so I'm probably just talking complete rubbish. Lol
Well, I think anything is valuable. Just because it's not as powerful/flexible/whatever as some other system, doesn't mean it doesn't have use cases, right?

I was thinking more of if you can some how force blank just sprite rendering, and leave BG active, artistically you can use that transition line(s) to make it look like it's covering over sprites.. but actually allow for reloading/reusing some OAM entries. Blank/black lines is kinda pretty limited use case (I was hoping for at least controllable solid color lines). But even if you can't, but you can update on lines that have no sprite pixel fetching.. or you can predict the length of sprite fetching and have DMA dummy writes that delays the real DMA write until sprite pixel data is finished.. and you can update 1 or 2 sprites, that's still something! A big part of special effects in game designs, it making it look like the limitations don't exist - even when they do.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Regarding SNES' object limitations

Post by 93143 »

turboxray wrote: Wed Jul 13, 2022 3:49 pmI was thinking more of if you can some how force blank just sprite rendering
That's easy. You can simply not send OBJ to either the main or sub screen, and it won't show up regardless of how much of a mess you make of it.

This only allows (probably) the HBlank trick, where you force blank the moment the line ends, write to OAM, and turn the screen back on before BG fetches start. But it does somewhat extend the concept of "a line that has no sprites on it", which could be useful in certain circumstances. If you can contrive to have a couple of mostly black lines in the BG graphic that covers this area, even better...
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

turboxray wrote: Wed Jul 13, 2022 3:49 pm
iNCEPTIONAL wrote: Tue Jul 12, 2022 11:55 am
Myself086 wrote: Tue Jul 12, 2022 11:40 am
Yes if sprites are disabled for the next line.
No if sprites are enabled for the next line.

The only use case is for split screen with a horizontal black bar between the screens.
1. Could you do the multiplexing without the split screen type of design if you had a game where sprites never moved up or down so as to make sure they never overlapped with sprites above or below them and therefore couldn't be affected by what's happening above or below them in code with all the hblank and scanline stuff to achieve the multiplexing?

2. Does a black bar truly have to be visible for this multiplexing on SNES to work at all, or are you just saying that would be the way to do it because then you can basically guarantee the sprites above the bar aren't going to cause any display issues with the multiplexed versions below the bar (plus you can actually use the force blanking time during the black bar to achieve this basically without any hassle at all)?

3. What if, for example, I had a game that was a series of horizontal background platforms and the sprites on the top platform could never move below that, could I then use this multiplexing method on SNES to have a bunch of the duplicate sprites on one of the lower platforms? In fact, to make it even easier to visualize, what if it were just a nice background image and the static word "Repeat" made out of a bunch of 32x32 sprites that I simply wanted to repeated say five times down the screen [without any blank/black scanlines in between] using multiplexing rather than using five times the amount of sprites for the same result?

PS. I really have no clue how all of this works, so I'm probably just talking complete rubbish. Lol
Well, I think anything is valuable. Just because it's not as powerful/flexible/whatever as some other system, doesn't mean it doesn't have use cases, right?

I was thinking more of if you can some how force blank just sprite rendering, and leave BG active, artistically you can use that transition line(s) to make it look like it's covering over sprites.. but actually allow for reloading/reusing some OAM entries. Blank/black lines is kinda pretty limited use case (I was hoping for at least controllable solid color lines). But even if you can't, but you can update on lines that have no sprite pixel fetching.. or you can predict the length of sprite fetching and have DMA dummy writes that delays the real DMA write until sprite pixel data is finished.. and you can update 1 or 2 sprites, that's still something! A big part of special effects in game designs, it making it look like the limitations don't exist - even when they do.
Well, exactly. And it's going to be the "use cases" that make the difference between just something and something that a lot of people might even find rather impressive just on the face of it. I mean, look at all those demo scene examples: Most of the effects you see in those demos rarely appear in any actual games but people still go wow over them, and rightly so. Personally though, I wanna see if there's some cool ways to use whatever tricks we have access to in actual games because that's what really matters to me. :)
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Regarding SNES' object limitations

Post by psycopathicteen »

I want to know what happens between H=256 and H=272. Is the OAM address still frozen? Would turning on and off forced blank work?
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

I think it was in this thread that we were discussing about the SNES displaying all 128 sprites onscreen and whether that was possible in a real game scenario and how limited things would have to be to show all 128 sprites during actual gameplay and so on. Some people didn't really think it would even be feasible to use all 128 sprites effectively, some people thought the system would inevitably slow to a crawl unless it used some enhancement chip, some people thought the system was capable of this and potentially in actual gameplay scenarios, one person provided a cool demos showing 128 16x16 sprites bouncing around and lighting up, etc. Nothing truly conclusive came out in terms of just having it all work in a real game during actual gameplay and work well, as far as I recall.

So, I was just wondering if anyone can properly clarify that what the video below [the footage on the right] is showing is a stock SNES running in standard 3.58 MHz mode playing a commercially released game that puts all 128 sprites onscreen during regular gameplay, with lots of actual gameplay stuff going on (player moving, multiple lasers firing, multiple missiles launching, four Option objects following player, bubbles bouncing, bubbles breaking up, other enemies onscreen, enemies firing, sprites being used for all the stars in the background and all moving at different speeds for parallax, one background for scenery with some animated tiles and the other background for the overlaid HUD, etc), and, due to the code being further optimized than in the original game, it is running with far less slowdown [during one of the most object/code/processor intensive moments in the entire game] and to the point where, imo, any remaining slowdown can now be considered a non-issue (at least to any normal person):

https://youtu.be/myXWaOASRd4?t=192

And, I think the point of it seems to be showing that, while it is possible to use the SA-1 chip to really give the SNES a massive speed boast and basically eliminate all slowdown from games like this, with properly optimized code, it is actually possible to basically achieve the same goal, which is removing most if not all of the slowdown from these games [easily enough that any normal person is honestly going to be more than happy with the results] and not actually require any enhancement chip at all.

Now, I know it's in Portuguese or whatever, but can anyone get the gist if that's what is going on here in the video?

If that is what is being shown, it's really encouraging to see what the SNES is capable of in the right hands, and indeed allows me to think about just how far I might be able to push my own shmup so long as I have a great programmer and design my game well.

PS. I'm also really impressed with how well it's handling any dropout and flicker too. It's never so bad that it even remotely registers as some glaring issue to me. Very nice. Makes me wonder if this game uses the SNES' sprite priority cycling feature to better hide what would likely be more obvious dropout and flicker without having such a feature, or if this is just some other magic or fluke going on. I mean, I know there is obviously some dropout and flicker, but with so much stuff onscreen, I would kind of expect the whole screen to be going crazy constantly, and it's really not. Although, I don't know if this is running on a real physical SNES, so I couldn't say what difference that would make.
Last edited by iNCEPTIONAL on Mon Aug 01, 2022 7:05 am, edited 5 times in total.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

this video is showing is a stock SNES running in standard 3.58 MHz mode playing a commercially released game that puts all 128 sprites onscreen
Well, this video shows an emulator, I think a save state is used for the Sprite viewer tool. Not that it matters, it should run the same on a real SNES.
use the SA-1 chip
Well, that isn't exactly "stock" then, if it uses a fast coprocessor. This game isn't very code heavy, the stars are sprites that don't collide, so the code involved is just x=x-1. Easy to optimize.

So, yes... it can be done, if you keep the sprite movements very simple. That one demo is proof.
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

dougeff wrote: Mon Aug 01, 2022 6:05 am
this video is showing is a stock SNES running in standard 3.58 MHz mode playing a commercially released game that puts all 128 sprites onscreen
Well, this video shows an emulator, I think a save state is used for the Sprite viewer tool. Not that it matters, it should run the same on a real SNES.
use the SA-1 chip
Well, that isn't exactly "stock" then, if it uses a fast coprocessor. This game isn't very code heavy, the stars are sprites that don't collide, so the code involved is just x=x-1. Easy to optimize.

So, yes... it can be done, if you keep the sprite movements very simple. That one demo is proof.
To be clear, I'm talking about NOT using any enhancement chips here. If it were though, then, yes, you would be correct that it wouldn't be "stock". What I am interested in is if the footage on the right is running on a stock SNES in 3.58 MHz, using all 128 sprites in various ways with negligible slowdown, and with all the other considerations I mentioned. That's the part I can use when it comes to my own game. And I absolutely do not want to use the SA-1 or any other enhancement chips--unless absolutely necessary (and if any physical cart manufacturers even support that anyway). This is why I'm looking so much into what the stock SNES can do and trying to figure out all its limitations and, indeed, just how much you can actually do on it when truly pushed to those limits (but really from a game design and end user gamer point of view).

And, honestly, if this game isn't considered code heavy, they I have no idea why I'm even remotely worrying about what the SNES is capable of. Because, I'm not going to be designing a game for the sake of code but for the gameplay and fun, and I see all the gameplay a shmup needs in that video. So, if the gameplay can be achieved with less complicated code, that's entirely to my advantage. I mean, I'm not exactly sure what people imagine someone might want to do on the SNES in whatever scenario that would qualify as and require being code heavy, but I'm not designing some complex physics engine or something, just a 2D shmup with a player, some weapons fire and some enemies. The rest will all be about the design of the game and the gameplay selling the experience. So this is all good news to me.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Regarding SNES' object limitations

Post by dougeff »

I see, there are 2 versions here. Sa1 and FastROM.

FastROM is stock SNES. Yes.
nesdoug.com -- blog/tutorial on programming for the NES
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

dougeff wrote: Mon Aug 01, 2022 6:46 am I see, there are 2 versions here. Sa1 and FastROM.

FastROM is stock SNES. Yes.
Ah, sorry. I didn't realise that wasn't obvious. My bad.

Yes, and that's what I was trying to just double check: That what we are seeing on the right is indeed a SNES game displaying all 128 sprites during a full action in-game scene with all the stuff going on at once that I described and with [imo] genuinely negligible slowdown, achieved by simply switching to FastROM and then having basically the properly optimised code that was missing from the original in the first place, which is apparently what caused almost all of the slowdown that the game is infamous for, and that I'm not mistaken about what I'm seeing in the video.

Because, if I'm not mistaken about what I'm seeing, it bodes very well indeed.
Last edited by iNCEPTIONAL on Mon Aug 01, 2022 8:39 am, edited 3 times in total.
MSonage
Posts: 22
Joined: Fri May 06, 2022 4:34 pm

Re: Regarding SNES' object limitations

Post by MSonage »

iNCEPTIONAL wrote: Mon Aug 01, 2022 5:27 am I think it was in this thread that we were discussing about the SNES displaying all 128 sprites onscreen and whether that was possible in a real game scenario and how limited things would have to be to show all 128 sprites during actual gameplay and so on. Some people didn't really think it would even be feasible to use all 128 sprites effectively, some people thought the system would inevitably slow to a crawl unless it used some enhancement chip, some people thought the system was capable of this and potentially in actual gameplay scenarios, one person provided a cool demos showing 128 16x16 sprites bouncing around and lighting up, etc. Nothing truly conclusive came out in terms of just having it all work in a real game during actual gameplay and work well, as far as I recall.

So, I was just wondering if anyone can properly clarify that what the video below [the footage on the right] is showing is a stock SNES running in standard 3.58 MHz mode playing a commercially released game that puts all 128 sprites onscreen during regular gameplay, with lots of actual gameplay stuff going on (player moving, multiple lasers firing, multiple missiles launching, four Option objects following player, bubbles bouncing, bubbles breaking up, other enemies onscreen, enemies firing, sprites being used for all the stars in the background and all moving at different speeds for parallax, one background for scenery with some animated tiles and the other background for the overlaid HUD, etc), and, due to the code being further optimized than in the original game, it is running with far less slowdown [during one of the most object/code/processor intensive moments in the entire game] and to the point where, imo, any remaining slowdown can now be considered a non-issue (at least to any normal person):

https://youtu.be/myXWaOASRd4?t=192

And, I think the point of it seems to be showing that, while it is possible to use the SA-1 chip to really give the SNES a massive speed boast and basically eliminate all slowdown from games like this, with properly optimized code, it is actually possible to basically achieve the same goal, which is removing most if not all of the slowdown from these games [easily enough that any normal person is honestly going to be more than happy with the results] and not actually require any enhancement chip at all.

Now, I know it's in Portuguese or whatever, but can anyone get the gist if that's what is going on here in the video?

If that is what is being shown, it's really encouraging to see what the SNES is capable of in the right hands, and indeed allows me to think about just how far I might be able to push my own shmup so long as I have a great programmer and design my game well.

PS. I'm also really impressed with how well it's handling any dropout and flicker too. It's never so bad that it even remotely registers as some glaring issue to me. Very nice. Makes me wonder if this game uses the SNES' sprite priority cycling feature to better hide what would likely be more obvious dropout and flicker without having such a feature, or if this is just some other magic or fluke going on. I mean, I know there is obviously some dropout and flicker, but with so much stuff onscreen, I would kind of expect the whole screen to be going crazy constantly, and it's really not. Although, I don't know if this is running on a real physical SNES, so I couldn't say what difference that would make.
This is a fastrom + optimization hack, made by the romhacking.com users "slidelljohn" and "Aaendy" (called "psycopathicteen" here).
This is the thread where they were discussing about this project and some download links of each new update: https://www.romhacking.net/forum/index. ... ic=27609.0

I've done a better comparison here, showing the difference in seconds during each demo:
https://youtu.be/xeUe5ydqt1o
The plant stage takes a whopping 26 seconds to sync up.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

MSonage wrote: Mon Aug 01, 2022 8:13 am This is a fastrom + optimization hack, made by the romhacking.com users "slidelljohn" and "Aaendy" (called "psycopathicteen" here).
This is the thread where they were discussing about this project and some download links of each new update: https://www.romhacking.net/forum/index. ... ic=27609.0

I've done a better comparison here, showing the difference in seconds during each demo:
https://youtu.be/xeUe5ydqt1o
The plant stage takes a whopping 26 seconds to sync up.
Just shows you how much difference using FastROM and optimizing the code properly can make. Very impressive.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Regarding SNES' object limitations

Post by turboxray »

128 hardware sprites != 128 objects. In that video, the freeze frame shot with 128 OAM entries, only 31-33 objects are actually on screen (that doesn't include the starfield). It's 128 hardware sprites because the snes doesn't have more optimal sprite sizes. If I were to convert that exact scene to PCE or MD, it would be ~49 hardware sprites for those same ~31 objects. I've seen Batman Returns on the SNES hit 128 entries.. with just 3 clowns on screen + snow.

@MSonage
The length capture videos are nice, but it would much more insightful to have a frame lag overlay (like digital foundry). Has none does this??? Most slowdown I've looked at in the 16bit generation tends to be 50% (one missed frame), but I seen stuff like Super R-Type do like a 3,2,3,2,3,2 stager slowdown (Irem was just ridiculous). I wouldn't doubt it that Gradius 3 (original setup) is the same in some areas. But it'd be nice to have a frame rate analysis to see it more clearly.
iNCEPTIONAL

Re: Regarding SNES' object limitations

Post by iNCEPTIONAL »

turboxray wrote: Mon Aug 01, 2022 9:51 am 128 hardware sprites != 128 objects. In that video, the freeze frame shot with 128 OAM entries, only 31-33 objects are actually on screen (that doesn't include the starfield). It's 128 hardware sprites because the snes doesn't have more optimal sprite sizes. If I were to convert that exact scene to PCE or MD, it would be ~49 hardware sprites for those same ~31 objects. I've seen Batman Returns on the SNES hit 128 entries.. with just 3 clowns on screen + snow.

@MSonage
The length capture videos are nice, but it would much more insightful to have a frame lag overlay (like digital foundry). Has none does this??? Most slowdown I've looked at in the 16bit generation tends to be 50% (one missed frame), but I seen stuff like Super R-Type do like a 3,2,3,2,3,2 stager slowdown (Irem was just ridiculous). I wouldn't doubt it that Gradius 3 (original setup) is the same in some areas. But it'd be nice to have a frame rate analysis to see it more clearly.
I'm sure you could do various things on the other consoles. What does that have to do with the clearly amazing achievement here on SNES relative to the SNES' capabilities, and how they went from a game with abysmal slowdown to a game with basically irrelevant slowdown to any normal gamers?

And, sure, you might find having a frame lag overlay much more insightful. Maybe they can add that in a future video for your benefit. I found the comparison very meaningful as is, and I appreciate the effort put into both the optimisation work done here and the video very clearly showing off some of the benefits.
Locked