Page 3 of 7
Posted: Tue May 23, 2017 1:13 pm
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.
Posted: Tue May 23, 2017 1:55 pm
I'm not sufficiently familiar with the SNES to explain exactly how this differs from the SNES.
SNES allows 32 sprites per line, and they can be much bigger sprites (up to 64x64)
You can also rotate priorities on SNES by simply changing the value at...I think...register 2102 every V-blank.
(With ...set bit 7 of $2103)
Edit: added details
Posted: Tue May 23, 2017 2:19 pm
And what do these registers do/control?
Posted: Tue May 23, 2017 2:39 pm
It sets an address in the OAM for the top priority sprite. The official document describes it. Page 2-20-2
Posted: Tue May 23, 2017 2:57 pm
dougeff wrote:SNES allows 32 sprites per line, and they can be much bigger sprites (up to 64x64)
Yes, yes, "time over" and "range over", but that doesn't explain drop-out order, which was the entire question.
Posted: Tue May 23, 2017 3:16 pm
dougeff wrote:The official document describes it. Page 2-20-2
Not interested enough to go looking for the information myself, I thought you had volunteered to explain the relevant details of SNES sprite priorities, since you replied to rainwarrior.
Posted: Tue May 23, 2017 4:07 pm
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.
Posted: Tue May 23, 2017 5:03 pm
Official doc says...
Write $80 to $2103
Write top priority object # (0-127) to bits d1-d7 of $2102
(That is sprite # << 1)....during v-blank.
Priority will wrap once they pass 127.
So, if you write (1 << 1) = 2 to 2103, the #1 sprite will have top priority, and the #2 next, then #3...and #0 sprite will have lowest priority.
Posted: Tue May 23, 2017 6:00 pm
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?
Posted: Tue May 23, 2017 6:15 pm
I think you're misunderstanding my example. Normally, sprite #0 would have top priority. That means it gets evaluated first.
Doing some voodoo with 2102 changes which sprite gets evaluated first.
Posted: Tue May 23, 2017 6:21 pm
tokumaru wrote:"high priority" can't mean both these things in the SNES, right?
Yes. Sprites have two priority bits (I really wish one of these was another size bit...), along with each background tile having one. The order for each BG mode is here: https://wiki.superfamicom.org/snes/show/Backgrounds
I thought this except was odd:
wiki.superfamicom.org wrote: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.
Posted: Tue May 23, 2017 7:00 pm
From this forum...
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]
Posted: Tue May 23, 2017 7:11 pm
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.
CHR RAM loading slowdown
Tons 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.
Posted: Tue May 23, 2017 7:59 pm
So, to summarize, is this correct?
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.
Posted: Tue May 23, 2017 8:33 pm
Some of this sounds wrong to me.
Like NES but reverse?
Who said reverse? I think it is the same as NES. (?)
EDIT, psychopathic teen said it. I don't know then.
I wish bazz or byuu would chime in, but this topic isn't in in SNES DEV, so they probably won't read it. I really don't feel qualified to do any more than regurgitate tech. documents.
EDIT2 - reading further on...
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.