It is currently Sun Nov 19, 2017 5:36 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 92 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 1:13 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 1:55 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
Quote:
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

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 2:19 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
And what do these registers do/control?


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 2:39 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
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


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 2:57 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
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.


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 3:16 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 4:07 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2359
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.


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 5:03 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
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.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 6:00 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 6:15 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
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.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 6:21 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3108
Location: Nacogdoches, Texas
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.


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 7:00 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
From this forum...

https://www.smwcentral.net/?p=viewthread&t=23281

Quote:
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


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 7:11 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2359
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 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.


Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 7:59 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
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.


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

Top
 Profile  
 
 Post subject: Re: Platform-a-lotis
PostPosted: Tue May 23, 2017 8:33 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1823
Location: DIGDUG
Some of this sounds wrong to me.

Quote:
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...
https://wiki.superfamicom.org/snes/show/Sprites


Quote:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 92 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group