I don't think there's anything wrong with what psycopathicteen said about sprite priorities. If you follow the convention of leaving empty space at the bottom of the sprites, you can sort them so that sprites with higher Y coordinates have higher priority over sprites with lower Y coordinates, so that the empty spaces always lose the PPU's priority fight. This will impact the sprite cycling though, since you'll only be able to shuffle sprites horizontally. There's also the overhead of sorting by Y coordinate.

All he's talking about is that if you set a certain bit, you set any of the 128 sprites as the first sprite from front to back, but it always drops the front most sprites regardless of which sprite is set to be first. It's not really all that important because when it's not set, it acts like the NES's OAM only it drops the front instead of the rear most sprite.

Interesting that the SNES drops front most sprites rather than the back most ones. Does this have to do with the fact the SNES uses a line buffer to render sprites, so it has to draw them back to front to respect the layering, and when the time is up it's the front most ones that get axed since they're drawn last?

Anyway, what does "high priority" mean in SNES terms? On the NES, "high priority" means that the sprite has higher chances of being rendered (a high priority sprite is picked for drawing before a low priority one) AND that it's displayed in front of lower priority sprites. But if I understand what you're saying, "high priority" can't mean both these things in the SNES, right?

FirstSprite ends up on top of all other sprites, regardless of the priority bits in OAM. FirstSprite+1 is on top of FirstSprite+2 is on top of FirstSprite+3 and so on until FirstSprite+127 (wrapping of course from sprite 127 to sprite 0). Note that only the priority of the topmost sprite is considered relative to the backgrounds. Thus, if FirstSprite+3 and FirstSprite+4 are identical except FirstSprite+3 has priority 0 and FirstSprite+4 has priority 3, they will both be hidden by any backgrounds that hide priority 0 sprites. This may seem counter-intuitive, since FirstSprite+4 would normally go in front of these BGs, but many games depend on this behavior.

From what I've tested, sprite <-> sprite overlap depends on the OAM order.The lower in the OAM table, the higher the sprite <-> sprite priority.[Lower # sprites will show up in front]The PP bits in YXPPCCCT don't seem to have any effect in sprite <-> sprite overlap at all. Their effect goes into layer <-> sprite. (And here, the order in OAM doesn't matter, again.)The higher the value of the PP bits, the higher the priority of sprites over [BG] layers.

[Bracket = my addition]

_________________nesdoug.com -- blog/tutorial on programming for the NES

Isn't it like that on the NES and Genesis where you can have conflicting sprite priorities. Heck, I wouldn't be surprised if the Sega Saturn is like that.

Quote:

CHR RAM loading slowdownTons of animation frames might get stuck in the PRG ROM because of limited bandwidth to the PPU. The NES can copy about eight tiles to the PPU per frame, plus OAM and whatever map updates are required for scrolling. Unlike the NES, the GBC has HDMA to CHR RAM at one tile per scanline.

16 tiles, if not much else in the PPU is happening. You could probably still use forced blank to get a little bit more.

1. Sprites get layered in order according to a "first sprite" parameter, which can change per-scanline, lowest index on top. (Like NES but with a movable "index 0".)2. If there are more than 32 sprites on a scanline, the highest index drops out first. (Like NES.)3. Breaking the 32 sprites into 8-pixel wide slivers, if there are more than 34 slivers, slivers from the lowest indexed sprite will drop out first; within a single sprite its 1-8 slivers will drop out from right to left. (No equivalent on NES, because it only has 8-pixel wide sprites.)4. After the visible sprite for a pixel is selected via steps 1-3, its priority bits are used to interleave it with the background layers. (Like NES but with more layers, e.g. you can use a lower index "background" priority sprite to mask off a "foreground" sprite.)

Edit: amended with information from below.

Last edited by rainwarrior on Tue May 23, 2017 9:29 pm, edited 3 times in total.

1) Range: Starting with the FirstSprite, determine the first 32 sprites on this scanline. Only those sprites with -size < X < 256 are considered in Range. If there are more than 32 sprites on the scanline, set bit 6 of register $213e.2) Time: Starting with the last sprite in Range, load up to 34 8x8 tiles (from left-to-right, after flipping). If there are more than 34 tiles in Range, set bit 7 of $213e. Only those tiles with -8 < X < 256 are counted.

So, my interpretation is...take the first 32 sprites (on that scanline) in order of priority... then, with that subset, in reverse order, get the LAST 34 8x8 tiles. So...it's complicated.

_________________nesdoug.com -- blog/tutorial on programming for the NES

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum