Talk:Sprite overflow games

From NESdev Wiki
Revision as of 10:17, 25 October 2015 by Bavi H (talk | contribs) (→‎Zelda 1?: Oops, FCEUX source just increases a maxsprites variable; Which doors and Zelda version is page describing?)
Jump to navigationJump to search

Splitting Commercial Games

I have a question, Is it better to split the Commercial Games between Official and Unofficial Releases? (Example: Bee 52 is an Unlicenced cartridge, so this goes under Unofficial) --Hamtaro126 (talk) 14:38, 11 November 2014 (MST)

I might consider it once there is more than one unlicensed game in the list. Having more than one unlicensed game in the list may help toward an explanation of how unlicensed games on the whole use it more, less, or in a different manner compared to licensed games. But having only one doesn't accomplish much other than shaming Codemasters for not having the Seal. --Tepples (talk) 15:19, 12 November 2014 (MST)

Zelda 1?

The page claims that Zelda 1 uses this trick when Link is entering a vertical doorway. I took this to refer to the effect where Link appears to be going down stairs, such as when he enters the cave on the first screen of the game. But if I enable more than 8 sprites per scanline in FCEUX or Nestopia, nothing changes; Link still sinks behind the background like he's supposed to, suggesting this is done by some other means such as flipping his priority bit. Am I mistaken in understanding what the page is referring to, or is the page itself mistaken? - Furrykef (talk) 21:37, 24 October 2015 (MDT)

(Note: According to the page, the technique in question is to "intentionally place multiple blank sprites early in the OAM at the same Y position so that other sprites on those scanlines are hidden." This is a different thing than "flipping the priority bit". See PPU sprite priority.)
My understanding of the "more than 8 sprites per scanline" setting is that it is intended to reduce sprite flicker. I believe this setting tries to detect games that cycle sprites -- that is, when the game wants to display more than 8 sprites per scanline by flickering some on and off by reordering or reloading the sprite order every frame. If the game wants to hide sprites by rearranging the sprite order and keeping the same order (for longer than a frame?), then I think the emulator will obey the original NES behavior no matter what the value of this setting is.
For example, here's what the FCEUX help file says about the setting:
  • "Allow More than 8 sprites per scanline. On real NES hardware, more than 8 sprites on the screen causes flickering. Enabling this can cause less flickering by allowing more sprites to be visible at once. If you prefer to stay "true" to NES hardware, this should not be checked."
--Bavi H (talk) 03:48, 25 October 2015 (MDT)
Oops, I think I may have been wrong above. I looked in the FCEUX source code to see if I could back up my above statement. I traced the setting to this function in ppu.cpp:
void FCEUI_DisableSpriteLimitation(int a) {
	maxsprites = a ? 64 : 8;
}
So that makes it sound like the setting should display the hidden sprites in Zelda 1 as described on the page. I wonder if the page is talking about overworld doors or dungeon doors? Is it only in the Japanese version, or is it in the English version also? --Bavi H (talk) 04:17, 25 October 2015 (MDT)