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.