Platform-a-lotis
Moderator: Moderators
Re: Platform-a-lotis
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.
Re: Platform-a-lotis
SNES allows 32 sprites per line, and they can be much bigger sprites (up to 64x64)I'm not sufficiently familiar with the SNES to explain exactly how this differs from the SNES.
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
nesdoug.com -- blog/tutorial on programming for the NES
Re: Platform-a-lotis
And what do these registers do/control?
Re: Platform-a-lotis
It sets an address in the OAM for the top priority sprite. The official document describes it. Page 2-20-2
nesdoug.com -- blog/tutorial on programming for the NES
Re: Platform-a-lotis
Yes, yes, "time over" and "range over", but that doesn't explain drop-out order, which was the entire question.dougeff wrote:SNES allows 32 sprites per line, and they can be much bigger sprites (up to 64x64)
Re: Platform-a-lotis
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.dougeff wrote:The official document describes it. Page 2-20-2
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Platform-a-lotis
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.
Re: Platform-a-lotis
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.
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.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Platform-a-lotis
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?
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?
Re: Platform-a-lotis
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.
Doing some voodoo with 2102 changes which sprite gets evaluated first.
nesdoug.com -- blog/tutorial on programming for the NES
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Platform-a-lotis
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/Backgroundstokumaru wrote:"high priority" can't mean both these things in the SNES, right?
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.
Re: Platform-a-lotis
From this forum...
https://www.smwcentral.net/?p=viewthread&t=23281
https://www.smwcentral.net/?p=viewthread&t=23281
[Bracket = my addition]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.
nesdoug.com -- blog/tutorial on programming for the NES
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Platform-a-lotis
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.
16 tiles, if not much else in the PPU is happening. You could probably still use forced blank to get a little bit more.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.
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Platform-a-lotis
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.
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.
Re: Platform-a-lotis
Some of this sounds wrong to me.
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...
https://wiki.superfamicom.org/snes/show/Sprites
Who said reverse? I think it is the same as NES. (?)Like NES but reverse?
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...
https://wiki.superfamicom.org/snes/show/Sprites
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.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.
nesdoug.com -- blog/tutorial on programming for the NES