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

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

Post by iNCEPTIONAL »

If someone were to put the same dedication into finding every single instance of dropout, flicker, glitching into any game, scanning frame by frame the entirety of this boss fight for example:

https://youtu.be/YMVNeMp9HX4?t=266

They will find that bugs, dropout, flicker, etc, happen, even in the the most highly regarded games that are often touted as graphical showcase of just how capable a system is.

The same thing is true of slowdown and stutter and the like, especially during moments where a system is just trying to do too much:

https://youtu.be/1F1gT9yKwaY?t=1929

And the solution is better bug checking, better optimization, designing around a system's limitations, or, deciding what is and what isn't an acceptable level of compromise if you're trying to push a console and really wow people, and creating a great game with that in mind.

So, after taking into consideration all the previous posts, and recently seeing this example of the clearly bad followed by the clearly good on SNES: https://youtu.be/xeUe5ydqt1o?t=21

My goal is to learn from these examples, figure out where it didn't quite work, and aim towards doing things right on the SNES when working on my own Mode 0 shmup game. And hopefully the end result we be not only a great SNES game in its own right, but also one that is a genuine showcase for the system too, like this:

https://youtu.be/Tl7D25I6yDc?t=2833 (and this is even still in SlowROM no less)

If I can get anywhere close to that, I will be very happy indeed.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

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

Post by turboxray »

iNCEPTIONAL wrote: Mon Aug 01, 2022 9:40 am but also one that is a genuine showcase for the system too, like this:

https://youtu.be/Tl7D25I6yDc?t=2833 (and this is even still in SlowROM no less)

If I can get anywhere close to that, I will be very happy indeed.
Notice how the game only ramps up in that section when you don't have bullet to background collision detection. All you have to do in that area, code wise, is focus all cpu resource on object to object collision. Those are definitely tricks and hacks you can learn from observation.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

turboxray wrote: Mon Aug 01, 2022 10:27 am
iNCEPTIONAL wrote: Mon Aug 01, 2022 9:40 am but also one that is a genuine showcase for the system too, like this:

https://youtu.be/Tl7D25I6yDc?t=2833 (and this is even still in SlowROM no less)

If I can get anywhere close to that, I will be very happy indeed.
Notice how the game only ramps up in that section when you don't have bullet to background collision detection. All you have to do in that area, code wise, is focus all cpu resource on object to object collision. Those are definitely tricks and hacks you can learn from observation.
Yeah, and this guy clearly used almost all of them, because the result is one of the most stunning games of the entire 16-bit home console generation (not including something like Neo Geo, with its $300 games, obviously). Almost everyone I've seen comment on it after watching gameplay footage is like "Holy crap. That is one of the most impressive 16-bit games I've seen". I totally agree with all those people. . . .
Last edited by iNCEPTIONAL on Mon Aug 01, 2022 11:35 am, edited 1 time in total.
TrekkiesUnite118
Posts: 92
Joined: Fri Mar 08, 2013 5:56 pm

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

Post by TrekkiesUnite118 »

While yes there is slowdown and some minor sprite drop out in those examples you posted, it really boils down to what's acceptable. I'd say what was posted in the examples, the stuff in Alien Soldier and Thunder Force IV were generally seen as more acceptable to people. So let's go over them.

Alien Soldier Example:
While there is some sprite dropout here, it's pretty minor. It's only happening to a small part of the boss around where the players bullets are hitting it. The player is still clearly visible as is the majority of the boss he's fighting. Finally it doesn't last for a prolonged period of time. Contrast this to the Turtles in Time example and it's a pretty stark difference. In The Turtles in Time example entire enemies become invisble to the player, and significant portions of the player sprites and other enemies are dropping out. It makes it difficult to judge where the player is and what enemies are attacking them. It's not just for a single frame either, it lasts for a significant amount of time while the players are fighting that wave of enemies.

As for the slowdown here, it generally seems to happen more when the player does a flashy attack on the boss, which most players will right off as a dramatic effect even if it's a technical slowdown. You see this actually in a lot of Treasure games, even ones on more powerful systems like the Saturn. Radiant Silvergun will do it every time a boss dies, and it's generally seen as acceptable.

Thunder Force IV Example:
I'd actually say this is pushing the limit of what's acceptable for slowdown. But when compared to say stock Gradius III, it tends to get more of a free pass because of what all is going on here. You have a huge boss doing some intricate AI and firing complex bullet patterns at the player, while the player is firing back equally intense bullet patterns with a lot of collision detection going on. And again, it's only happening at specific instances. Which brings us to the next example.

Gradius III:
The reason this game got so much crap for so long is not just because it slowed down, but because the game was almost in a constant state of slowdown to the point that it felt like it was playing in slow motion. Even worse, this was happening when there seemed to be very little even going on which made it even more appalling. It's nice to see that people have started to fix it without the need of an SA-1 chip.

When it comes to actually designing a game for the SNES, I'd say your best bet is to focus on the game itself and tailoring it around the SNES itself, and not focus on trying to win a console war. If you do the former you're more likely to succeed with a good looking game that's a solid and fun experience for the SNES. If you focus on the latter, you're more likely to end up with a dull tech demo that will still be picked apart.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

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

Post by turboxray »

iNCEPTIONAL wrote: Mon Aug 01, 2022 10:33 am
turboxray wrote: Mon Aug 01, 2022 10:27 am
iNCEPTIONAL wrote: Mon Aug 01, 2022 9:40 am but also one that is a genuine showcase for the system too, like this:

https://youtu.be/Tl7D25I6yDc?t=2833 (and this is even still in SlowROM no less)

If I can get anywhere close to that, I will be very happy indeed.
Notice how the game only ramps up in that section when you don't have bullet to background collision detection. All you have to do in that area, code wise, is focus all cpu resource on object to object collision. Those are definitely tricks and hacks you can learn from observation.
Yeah, and this guy clearly used almost all of them, because the result is one of the most stunning games of the entire 16-bit home console generation (not including something like Neo Geo, with its $300 games, obviously). Almost everyone I've seen comment on it after watching gameplay footage is like "Holly crap. That is one of the most impressive 16-bit games I've seen". I totally agree with all those people. . . .
It's a beautiful tech demo. It's not that great of a game, which is a shame.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

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

Post by dougeff »

Turtles in Time (and other similar beat em up side scrolling games) would be better if you rotated the entire TV 90° and the rotated the game play to match. Then the sprites would be arranged in a vertical strip (according to the SNES PPU) and you wouldn't get sprite limit drop out.

If you think that sounds strange, many classic arcade games did that.
nesdoug.com -- blog/tutorial on programming for the NES
TrekkiesUnite118
Posts: 92
Joined: Fri Mar 08, 2013 5:56 pm

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

Post by TrekkiesUnite118 »

dougeff wrote: Mon Aug 01, 2022 10:42 am Turtles in Time (and other similar beat em up side scrolling games) would be better if you rotated the entire TV 90° and the rotated the game play to match. Then the sprites would be arranged in a vertical strip (according to the SNES PPU) and you wouldn't get sprite limit drop out.

If you think that sounds strange, many classic arcade games did that.
A TATE mode Beat'em up would be pretty cool to see on a home console.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

I'm going to stop at least my part talking about the other systems into this discussion in the SNESdev thread, before I somehow [solely] get another warning for starting console wars or whatever.

So, if I were to hold up a game on SNES as a technical showcase of what can be done on that system when playing to its particular strengths and working around its particular weaknesses, and one that really doesn't suffer from any notable stutter or slowdown (nigh close to zero, if we're being honest and fair here), and very little noteworthy flickering too, it would be something like this:

https://www.youtube.com/watch?v=Tl7D25I6yDc&t=734s

https://www.youtube.com/watch?v=Tl7D25I6yDc&t=1180s

https://www.youtube.com/watch?v=Tl7D25I6yDc&t=1367s

https://www.youtube.com/watch?v=Tl7D25I6yDc&t=2833s

Running in 2.68 MHz SlowROM no less (so about 75% of the full speed of the SNES), at full screen, with a crap load of stuff going on in both the backgrounds and onscreen action, at a rock-solid 60fps, and using no enhancement chips whatsoever.

Now, we all know fine well that Rendering Ranger R2, a [SlowROM] game released on a 16-bit home console in the '90s, is dang impressive.

That's the kind of game I'm going to use as my yard stick for what is possible on SNES in the right hands, and especially when taking into consideration everything I want to do in my own shmup.
Last edited by iNCEPTIONAL on Mon Aug 01, 2022 3:23 pm, edited 6 times in total.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

dougeff wrote: Mon Aug 01, 2022 10:42 am Turtles in Time (and other similar beat em up side scrolling games) would be better if you rotated the entire TV 90° and the rotated the game play to match. Then the sprites would be arranged in a vertical strip (according to the SNES PPU) and you wouldn't get sprite limit drop out.

If you think that sounds strange, many classic arcade games did that.
Actually agree. No one is ever gonna do it, but, yes. Actually, if someone did do that, it would probably make for a very popular video on YouTube.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

turboxray wrote: Mon Aug 01, 2022 10:37 am
iNCEPTIONAL wrote: Mon Aug 01, 2022 10:33 am
turboxray wrote: Mon Aug 01, 2022 10:27 am

Notice how the game only ramps up in that section when you don't have bullet to background collision detection. All you have to do in that area, code wise, is focus all cpu resource on object to object collision. Those are definitely tricks and hacks you can learn from observation.
Yeah, and this guy clearly used almost all of them, because the result is one of the most stunning games of the entire 16-bit home console generation (not including something like Neo Geo, with its $300 games, obviously). Almost everyone I've seen comment on it after watching gameplay footage is like "Holly crap. That is one of the most impressive 16-bit games I've seen". I totally agree with all those people. . . .
It's a beautiful tech demo. It's not that great of a game, which is a shame.
On that, I agree. It's a good game, but not up there with the multiple SNES games that still appear in every Best Games of All Time lists to this day.
MSonage
Posts: 22
Joined: Fri May 06, 2022 4:34 pm

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

Post by MSonage »

dougeff wrote: Mon Aug 01, 2022 10:42 am Turtles in Time (and other similar beat em up side scrolling games) would be better if you rotated the entire TV 90° and the rotated the game play to match. Then the sprites would be arranged in a vertical strip (according to the SNES PPU) and you wouldn't get sprite limit drop out.

If you think that sounds strange, many classic arcade games did that.
Oh God... that makes so much sense :shock:
This would also be nice for a Wolfenstein 3D style game using Mode 7 + hdma. Maybe reaching its 60 fps.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

MSonage wrote: Mon Aug 01, 2022 11:51 am
dougeff wrote: Mon Aug 01, 2022 10:42 am Turtles in Time (and other similar beat em up side scrolling games) would be better if you rotated the entire TV 90° and the rotated the game play to match. Then the sprites would be arranged in a vertical strip (according to the SNES PPU) and you wouldn't get sprite limit drop out.

If you think that sounds strange, many classic arcade games did that.
Oh God... that makes so much sense :shock:
This would also be nice for a Wolfenstein 3D style game using Mode 7 + hdma. Maybe reaching its 60 fps.
And now I kinda want to see that too. . . . :lol:
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

iNCEPTIONAL wrote: Mon Aug 01, 2022 10:54 am before I somehow [solely] get another warning
You solely get public warnings because everyone else responds usefully to private ones.

But when you receive a PM from the moderating team telling you you did something wrong, you instead try to explain how it wasn't wrong, and/or someone else should be punished too. So public warnings for you it must be.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

Yes, I get the warning on behalf of a Sega/Genesis fan and a PC Engine fan who brought up other consoles [first], and spent countless posts attacking the SNES and ridiculously focussing in on tiny meaningless little things just to troll, in a forum called, SNESdev. It tracks.

I think my mistake I made when coming in here was not paying attention to the fact that it isn't really about SNES development to some people but just a programming group that happens to have SNES in the title (but designers, artists, musicians and even just SNES gamers and fans are also part of SNES development, or should be), and that the mods presumably aren't just here for the SNES part of this blog even when specifically inside the SNESdev board, which means they don't quite align with my views here coming specifically into the SNESdev board, and visa versa. In fact, I have this gut feeling we're really not on much of a same wavelength on this at all, which is sad when I'm in something specifically called the SNESdev board (not "EliteCodersOnly" or "AllSystemsAreTehBestDevs" or "GenesisFirstFansDev" or "PCEngineLoversCreate").

But, I'm happy to, ya know, stop all that crap and actually talk about SNES stuff from the perspective of someone who actually loves the SNES console the most out of all the other consoles (hence I'm here and not segaretro or whatever), someone who wants to make something on SNES (as a designer and artist), who wants to learn about SNES (but is really not interested in specifically becoming a hardcore programmer), someone who's actually comfortable bigging-up the SNES in a forum called SNESdev (which, I honestly thought would be full or hardcore SNES fans, who similarly love the system, maybe even most out of all the 16-bit consoles, shock, and not certain people who constantly knock down the SNES--my biggest mistake by far).
Last edited by iNCEPTIONAL on Tue Aug 02, 2022 1:00 am, edited 16 times in total.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

You get public warnings. Other people get private ones and you don't see them.

Why do you get public warnings? That's explicitly what I stated in my previous message.

But please, do keep digging yourself deeper in that hole.
Post Reply