Forums

This is a two-question topic, but it concerns -I guess- the same issue, which is no other than the limitations of our beloved console:

1) What would have been the minimum tech specs for the SMS to avoid flickering in its games?

2) Is flickering the main reason for the lack of 2-player coop games in demanding genres, as beat'em ups/brawlers?

(In fact, there are an incredible few amount of beat'em up for the SMS, even for just 1 player: Double Dragon, Vigilante, Running Battle, Renegade, Golden Axe, the two SoR, and maybe Black Belt and Altered Beast).

Assuming you mean sprite flickering? AFAIK this is essentially due to allowing free manipulation of the sprite attribute table, but running into the multiple sprites per line limit whenever the game happens to want to put more than 8 sprites on a single scanline.

Ron_Stard wrote

1) What would have been the minimum tech specs for the SMS to avoid flickering in its games?

The "minimum" specs would therefore be some combination of the width of macro-sprites (let's call that 'W') in the game and the upper limit on the chance of needing to render more than 8/W macro-sprites on a single line.

Taking Double Dragon as an example, it uses 2-tile (16px) macro-sprites for the main player(s), so can render a maximum of 4 macro-sprites on a single line before flickering occurs.

The main way to attempt to mitigate this that I know of is selectively rendering some characters as background tiles instead of sprites, but this is challenging at the best of times so I guess we are stuck with the flickering for most games.

By way of comparison, the MegaDrive/Genesis VDP I believe allows 16 sprites per line, so has double the capacity.

Ron_Stard wrote

2) Is flickering the main reason for the lack of 2-player coop games in demanding genres, as beat'em ups/brawlers?

I think that's a fair assumption - it does rather impair the playing experience. Personally I find Double Dragon almost unplayable, even in single player.

Thank you for your answers. Yes, I was referring to sprite flickering. I thought the size of the RAM and the VRAM would also have something to do with the flickering, but it seems secondary, according to your comments.

BTW I believe Lemmings is a good example of some very creative use of background tiles to give the illusion of more usable sprites than would otherwise be possible.

There is some flickering on Lemmings, but its a pretty smooth game considering the limitations.

I'm sure I saw a YouTube video on that at some point.

Yes the video chip would have needed to run faster to achieve more, basically to be more like the Mega Drive video chip. Adding more memory wouldn’t help much. Supporting bigger sprites would definitely have been nice, especially if that meant you could have 8 32x32 sprites as the limit or whatever, but also because it would have simplified things for game developers.

Maxim wrote

Yes the video chip would have needed to run faster to achieve more

I suspect that the sprite line limit isn't directly related to clock speed. It's more that it requires a relatively high amount of silicon on the ASIC compared to the rest of the VDP, since every possible sprite on the scanline requires 32 bytes of register (8 sprites x 4 colour planes x 8 bits per sprite tile line). Not sure whether anyone's actually decapped the TMSa to confirm, I'm basing this off my attempt to implement it myself in HDL.

That said, I do think the bottleneck in transferring data to the VDP from the CPU might mean that even if the VDP had provision for more sprites on a line it couldn't make much reasonable use of them anyway since every additional sprite displayed would require up to 3 extra bytes to be sent to the VDP, and they're not contiguous bytes either so even slower.

I keep meaning to play around with my FPGA implementation to see what happens when I allow for more than 8 sprites on a line. I wonder if it the flickering would just go away as if by magic, or whether some games rely on the limit of 8 somehow, whether by reading the status flag or otherwise. I guess it's relatively easy to modify an emulator to support more than 8 sprites per line too, to see what difference it would practically make.

There are a number of NES games that rely on using 8 invisible sprites on the same scanline to cut off the top or bottom of a 9th sprite - but there, dynamically updating sprites for transparency was either impossible, or at least more expensive than on the SMS

Author	Message
Ron_Stard Joined: 01 Apr 2008 Posts: 197 Location: Spain	About minimum desirable specs for the SMS Posted: Tue Nov 22, 2022 12:08 pm
Ron_Stard Joined: 01 Apr 2008 Posts: 197 Location: Spain	This is a two-question topic, but it concerns -I guess- the same issue, which is no other than the limitations of our beloved console: 1) What would have been the minimum tech specs for the SMS to avoid flickering in its games? 2) Is flickering the main reason for the lack of 2-player coop games in demanding genres, as beat'em ups/brawlers? (In fact, there are an incredible few amount of beat'em up for the SMS, even for just 1 player: Double Dragon, Vigilante, Running Battle, Renegade, Golden Axe, the two SoR, and maybe Black Belt and Altered Beast).

willbritton Joined: 06 Mar 2022 Posts: 670 Location: London, UK	Posted: Tue Nov 22, 2022 1:41 pm
	Assuming you mean sprite flickering? AFAIK this is essentially due to allowing free manipulation of the sprite attribute table, but running into the multiple sprites per line limit whenever the game happens to want to put more than 8 sprites on a single scanline. Ron_Stard wrote 1) What would have been the minimum tech specs for the SMS to avoid flickering in its games? The "minimum" specs would therefore be some combination of the width of macro-sprites (let's call that 'W') in the game and the upper limit on the chance of needing to render more than 8/W macro-sprites on a single line. Taking Double Dragon as an example, it uses 2-tile (16px) macro-sprites for the main player(s), so can render a maximum of 4 macro-sprites on a single line before flickering occurs. The main way to attempt to mitigate this that I know of is selectively rendering some characters as background tiles instead of sprites, but this is challenging at the best of times so I guess we are stuck with the flickering for most games. By way of comparison, the MegaDrive/Genesis VDP I believe allows 16 sprites per line, so has double the capacity. Ron_Stard wrote 2) Is flickering the main reason for the lack of 2-player coop games in demanding genres, as beat'em ups/brawlers? I think that's a fair assumption - it does rather impair the playing experience. Personally I find Double Dragon almost unplayable, even in single player.

Ron_Stard Joined: 01 Apr 2008 Posts: 197 Location: Spain	Posted: Tue Nov 22, 2022 10:33 pm
Ron_Stard Joined: 01 Apr 2008 Posts: 197 Location: Spain	Thank you for your answers. Yes, I was referring to sprite flickering. I thought the size of the RAM and the VRAM would also have something to do with the flickering, but it seems secondary, according to your comments.

willbritton Joined: 06 Mar 2022 Posts: 670 Location: London, UK	Posted: Tue Nov 22, 2022 10:52 pm
	BTW I believe Lemmings is a good example of some very creative use of background tiles to give the illusion of more usable sprites than would otherwise be possible. There is some flickering on Lemmings, but its a pretty smooth game considering the limitations. I'm sure I saw a YouTube video on that at some point.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14737 Location: London	Posted: Tue Nov 22, 2022 11:09 pm
	Yes the video chip would have needed to run faster to achieve more, basically to be more like the Mega Drive video chip. Adding more memory wouldn’t help much. Supporting bigger sprites would definitely have been nice, especially if that meant you could have 8 32x32 sprites as the limit or whatever, but also because it would have simplified things for game developers.

willbritton Joined: 06 Mar 2022 Posts: 670 Location: London, UK	Posted: Wed Nov 23, 2022 9:17 am
	Maxim wrote Yes the video chip would have needed to run faster to achieve more I suspect that the sprite line limit isn't directly related to clock speed. It's more that it requires a relatively high amount of silicon on the ASIC compared to the rest of the VDP, since every possible sprite on the scanline requires 32 bytes of register (8 sprites x 4 colour planes x 8 bits per sprite tile line). Not sure whether anyone's actually decapped the TMSa to confirm, I'm basing this off my attempt to implement it myself in HDL. That said, I do think the bottleneck in transferring data to the VDP from the CPU might mean that even if the VDP had provision for more sprites on a line it couldn't make much reasonable use of them anyway since every additional sprite displayed would require up to 3 extra bytes to be sent to the VDP, and they're not contiguous bytes either so even slower. I keep meaning to play around with my FPGA implementation to see what happens when I allow for more than 8 sprites on a line. I wonder if it the flickering would just go away as if by magic, or whether some games rely on the limit of 8 somehow, whether by reading the status flag or otherwise. I guess it's relatively easy to modify an emulator to support more than 8 sprites per line too, to see what difference it would practically make.

lidnariq Joined: 24 Mar 2021 Posts: 120	Posted: Wed Nov 23, 2022 7:24 pm
lidnariq Joined: 24 Mar 2021 Posts: 120	There are a number of NES games that rely on using 8 invisible sprites on the same scanline to cut off the top or bottom of a 9th sprite - but there, dynamically updating sprites for transparency was either impossible, or at least more expensive than on the SMS

Forums

View topic - About minimum desirable specs for the SMS