So, regarding the sprites per scanline . . .
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: So, regarding the sprites per scanline . . .
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.
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.
Re: So, regarding the sprites per scanline . . .
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 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.
Re: So, regarding the sprites per scanline . . .
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. . . .turboxray wrote: ↑Mon Aug 01, 2022 10:27 amNotice 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 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.
Last edited by iNCEPTIONAL on Mon Aug 01, 2022 11:35 am, edited 1 time in total.
-
- Posts: 92
- Joined: Fri Mar 08, 2013 5:56 pm
Re: So, regarding the sprites per scanline . . .
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.
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.
Re: So, regarding the sprites per scanline . . .
It's a beautiful tech demo. It's not that great of a game, which is a shame.iNCEPTIONAL wrote: ↑Mon Aug 01, 2022 10:33 amYeah, 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. . . .turboxray wrote: ↑Mon Aug 01, 2022 10:27 amNotice 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 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.
Re: So, regarding the sprites per scanline . . .
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.
If you think that sounds strange, many classic arcade games did that.
nesdoug.com -- blog/tutorial on programming for the NES
-
- Posts: 92
- Joined: Fri Mar 08, 2013 5:56 pm
Re: So, regarding the sprites per scanline . . .
A TATE mode Beat'em up would be pretty cool to see on a home console.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.
Re: So, regarding the sprites per scanline . . .
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.
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.
Re: So, regarding the sprites per scanline . . .
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.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.
Re: So, regarding the sprites per scanline . . .
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.turboxray wrote: ↑Mon Aug 01, 2022 10:37 amIt's a beautiful tech demo. It's not that great of a game, which is a shame.iNCEPTIONAL wrote: ↑Mon Aug 01, 2022 10:33 amYeah, 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. . . .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.
Re: So, regarding the sprites per scanline . . .
Oh God... that makes so much sensedougeff 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.
This would also be nice for a Wolfenstein 3D style game using Mode 7 + hdma. Maybe reaching its 60 fps.
Re: So, regarding the sprites per scanline . . .
And now I kinda want to see that too. . . .MSonage wrote: ↑Mon Aug 01, 2022 11:51 amOh God... that makes so much sensedougeff 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.
This would also be nice for a Wolfenstein 3D style game using Mode 7 + hdma. Maybe reaching its 60 fps.
Re: So, regarding the sprites per scanline . . .
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.
Re: So, regarding the sprites per scanline . . .
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).
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.
Re: So, regarding the sprites per scanline . . .
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.
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.