It is currently Wed Oct 18, 2017 9:53 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Thu Feb 14, 2013 3:00 am 
Offline
User avatar

Joined: Sun Dec 30, 2012 10:14 am
Posts: 7
will the sprite-0-hit set when *the priority of the sprite0 is 1 and the sprite0-pixel and bg-pixel are all not zero*?
is the sprite evaluation performed in pre-scanline?
from http://wiki.nesdev.com/w/index.php/PPU_rendering i read that the ppu doesn't perform sprite evaluation in pre-scanline, so there wtill be no sprite that shows in scanline 0? Outputting of sprites starts at scanline 1? As a result, sprite-0-hit will never be set before scanline1, and sprite-overflow will never be set before scanline0.----is it right?

thanks.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 5:04 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10052
Location: Rio de Janeiro - Brazil
ember wrote:
will the sprite-0-hit set when *the priority of the sprite0 is 1 and the sprite0-pixel and bg-pixel are all not zero*?

AFAIK, priorities have no effect on sprite 0 hits. If two solid pixels overlap, there's a hit.

Quote:
from http://wiki.nesdev.com/w/index.php/PPU_rendering i read that the ppu doesn't perform sprite evaluation in pre-scanline, so there wtill be no sprite that shows in scanline 0?

I'm confused about this myself. Historically, people used to justify the existence of the pre-render scanline with the fact that sprites are evaluated 1 scanline in advance, but this makes little since since no sprites are rendered in scanline 0.

Quote:
Outputting of sprites starts at scanline 1? As a result, sprite-0-hit will never be set before scanline1, and sprite-overflow will never be set before scanline0.----is it right?

I'm not sure of the timing details, but I believe the sprite 0 hit flag is set when the sprite is rendered, not when it's evaluated. The sprite overflow flag, on the other hand, gets set during evaluation, so if you have more than 8 sprites in scanline 1 the flag will most likely be set before scanline 1 starts.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 8:40 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
Sprite 0 hit is always set during active picture. You can delay it by a cycle by moving the sprite 3 pixels to the right. It couldn't be set during evaluation because at that point, the PPU doesn't know what the background pixel will be.

For sprite 0 hit to happen at a particular pixel (x, y), the following must be true:
  • The background must be enabled.
  • Sprites must be enabled.
  • The pixel must be in range of sprite 0. This allows the CPU to run ahead from the top of the picture to the top of sprite 0 and from the bottom of sprite 0 to the bottom of the picture.
  • The pixel in the background must be opaque.
  • The pixel in sprite 0, as flipped, must be opaque.
  • x must be less than or equal to 254 (no sprite 0 hit on last pixel).
  • If background or sprite clipping is enabled, x must be greater than or equal to 8.

The PPU does not consider the following at all:
  • Whether the opaque pixels have a value of 1, 2, or 3, as long as they're opaque (not 0). Even if the background pixel is color 2 and the sprite pixel is color 1, that doesn't prevent sprite 0 hit.
  • The color palette. A background pixel of color $02 (dark blue) and a sprite pixel of color $20 (white) will not prevent sprite 0 hit.
  • The priority bit. Several of my own productions place sprite 0 behind the background.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 9:58 am 
Offline
User avatar

Joined: Sun Dec 30, 2012 10:14 am
Posts: 7
THANKS! My SMB1 works fine after modified my sprite-0-hit trigger!


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 10:41 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
I thought the pre-render scanline was so they could get the background ready, even if the first 279 dots are pointless.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 11:58 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
That'd probably take up too much memory to cache, I imagine backgrounds are processed on the fly (wasn't it mentioned once that background tiles were processed 8 pixels before they appear, in fact, meaning they aren't cached at all?).


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 2:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
I think Dwedit is referring to the last two sets of fetches of line -1 during x=320 to 335, which are for the first two tiles of line 0.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 6:10 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
It's like starting any process. Seeking in an mp3 player is a good example. The simplest way is to seek to some arbitrary point in the file, possibly in the middle of a frame, but slightly before where you really want. Then run the decoder several frames so that any erroneous data's awful sound output will be run past, and the output synchronized and clean. This is simpler than working out how to decode cleanly from any point in a stream. Similar to that, I take it that the PPU runs an extra scanline where it'll have some junk in it, but by the end, everything will be synchronized so that it's as if it had been rendering 100 scanlines before.


Top
 Profile  
 
PostPosted: Fri Feb 15, 2013 9:19 pm 
Offline
User avatar

Joined: Sun Dec 30, 2012 10:14 am
Posts: 7
blargg wrote:
It's like starting any process. Seeking in an mp3 player is a good example. The simplest way is to seek to some arbitrary point in the file, possibly in the middle of a frame, but slightly before where you really want. Then run the decoder several frames so that any erroneous data's awful sound output will be run past, and the output synchronized and clean. This is simpler than working out how to decode cleanly from any point in a stream. Similar to that, I take it that the PPU runs an extra scanline where it'll have some junk in it, but by the end, everything will be synchronized so that it's as if it had been rendering 100 scanlines before.


at the moment between last dot of pre-scanline and first dot of scanline0, i think the first 2 tiles of scanline0 has been loaded and NO sprites in the latches/shift-registers/counters. right?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 9 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