Well, recently I've been getting into sprite priorities/tricks/quirks and while reading the PPU tech doc I read how if a sprite's priority is set to be behind the background and it goes behind the background while being in front of another sprite (the sprite has a lower number thus higher priorty than the aforementioned sprite) that doesn't have the behind background bit set, the background goes in front of both sprites (except for the transparent pixels of the higher priorty sprite).

Well, I just confused myself by typing all that, but hopefully you understand what I mean. I have a few questions on it (and about sprites in general) though since I can't test my programs on a real NES since I'm not rich enough (yet.....hahahaha.....) to buy one of those fancy EEPROM writers.

1) If there are 8 sprites behind the background (all have high priorities) on the same scanline/s and there was a foreground sprite (in front of background) on the same scanline/s, would the lowest priorty sprite dissappear (not be drawn)? What about vice versa? Well, basically just tell me if sprites act the same whether their being drawn behind the background or not? And if not tell me why if you please. thx :)


2) Well in the PPU doc it said to try out megaman 2 to see the sprite/background priorty pixel quirk. So since I just bought the game awhile back so I decide to test it out on the real thing. I went to airman's stage and at the very beginning I went to the left of the screen and jumped where the energy bar was (and if you jump high enough the clouds are there to) and sure enough the clouds were displayed in front of the energy bar (minus the transparent pixels). But it was weird when megaman and the energy bar are at the same place. It looks like it's flickering or something. Like it keeps switching priorties between megaman and the energy bar back and forth really fast (so megaman isn't solidly in front of the energy bar.....but you can still see he is in front of it pretty easily). Well I decided to test this flicker thing in an emulator to see if it did the same thing. Well, I tested it in VirtuaNES (although not the most accurate emulator, it is still my favorite) and it did the same flicker thing. I assumed it was that megaman's sprite priorty kept switching constantly so that more sprites could be "seen" on one scanline. But I decided to test it on Nintendulator (as I consider that emulator to be the most accurate) and when I jump in front of the energy bar, megaman's sprite is solidly in front of it. So then I knew it wasn't a sprite priorty thing. I tested it on a lot of other emulators (nestopia, fce ultra) and got the same results as VirtuaNES (the flickery thing between megaman and the energy bar). So my question is why does it do that weird flickery thing? And my other question is why doesn't it do it in Nindenulator?

3) And also do transparent pixels count as the 64 pixel limit on sprites for each scanline? Does the pixel being in the background foreground affect it in any way?

Sorry about my post being too big, but I am really interested in this. THX :)

1) The 8 highest priority sprites are drawn... regardless of X-coord, BG priority, or anything else. It doesn't matter where the 9th sprite is or how it would be drawn... if there are 8 sprites ahead of it... it won't appear on screen.

When sprites are being checked to see if they're in the scanline.. only the first 8 it finds are taken (starting at Sprite 0 and working down to Sprite 63). Only the sprite's Y coord is checked in this process... so BG priority and other sprite attributes do not matter at this stage.


2) I had a similar phenomonon when running the game in my emu (I expected it to act different because of how the doc explained it), but I guess I was doing it right if the same thing happens on the real thing =).

> So my question is why does it do that weird flickery thing?

I can't say for certain... but it's probably the game's OAM cycling (running through the sprites and changing their priorities around so that both will be visible even when they overlap).

As for why it doesn't act that way in Nintendulator... I'll leave that to Quietust.

But if you witnessed the flickering on the real thing... then that is the proper behavior. Always judge by the real thing over an emulator... regardless on how accurate an emu may be, it's never more accurate than the real thing.


3) There is no 64 pixel limit... there's only a 8 sprite limit. So yes... if the first 8 sprites are all transparent... the 9th sprite still won't be drawn. The BG does not affect this in any way.

"3) There is no 64 pixel limit... there's only a 8 sprite limit"
Eight sprites are always 64 pixels wide. Expressing sprite capacity in pixels may be more familiar to those who have worked with the Super NES or the GBA.

Thx, that really helps a lot. :)



Well, I figured it was OAM cycling, but after it didn't do the same thing on Nintendulatorm so I was pretty sure that it wasn't, as I'm positive that the Nintendulator would be able to emulate something as easy as that (and in other OAM cycling games the OAM cycling works fine in Nintendulator). I wasn't sure if it was some PPU quirk of the NES when sprites overlap or something (as I've never really been able to play a game on the NES where sprites are "allowed" to overlap and the doesn't use OAM sycling). That would make sense if it was OAM cycling of course, but it doesn't make sense why Nintendulator wouldn't emulate it as it does emulate other OAM cycling games.

Well, I'm going to do some testson the sprite thing vs. Nintenulator. thx for your help.