Hi there!
It’s well known that the SMS supports 64 onscreen sprites, but for each scanline, at most 8 sprites can be displayed without flickering.
However, I’m puzzled about how R-Type seems to have overcome this limit. Take a look at this long play at 5:31 https://youtu.be/dQc_hkTEb4s?t=331 (frame shown below).
It seems to me that there are many scan lines almost full of sprites and not just 8 (see top part of the attached figure).
Yes, some flickering occurs in some frames, but on other frames all the sprites are visible at once. I thought that even with flickering, still eight sprites could be drawn per each scanline on each frame.
Did I misunderstand how flickering occurs?
Or perhaps in this video we see just inaccurate emulation or “wrong” screen capture? Or did the programmer use some background tiles, as trick (especially in the horizontal part of the snake) ?
Cheers!
Nicola
R-Type on SMS, technical details about sprites
R-Type on SMS, technical details about sprites
next-hack.com
Re: R-Type on SMS, technical details about sprites
Good question! I'm going to stay tuned to this thread as I'm taking notes for the Master System edition of Games That Pushed the Limits:
http://www.racketboy.com/guide/games-th ... o-hardware
http://www.racketboy.com/guide/games-th ... o-hardware
Support Racketboy on Patreon
Follow Racketboy on Social: Instagram / Twitter / Facebook
Subscribe to Email Newsletter (Blog / Guide Updates Every Week or Two)
Follow Racketboy on Social: Instagram / Twitter / Facebook
Subscribe to Email Newsletter (Blog / Guide Updates Every Week or Two)
Re: R-Type on SMS, technical details about sprites
I know a lot of NES emulators have the options to remove sprite limits, so I'm assuming you can do that on some SMS emulators as well (I have never used one). Or, if it's real hardware, it could depend on how it was captured. There could be a framerate mismatch. For example, the invulnability in Castlevania, if you capture it at 30 FPS then the sprite will either be missing or solid in the video (depending on which frames it's grabbing) instead of flickering (making it sort of translucent) like it should be.