confused about something about sprite rendering

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
ember
Posts: 7
Joined: Sun Dec 30, 2012 10:14 am

confused about something about sprite rendering

Post by ember » Thu Feb 14, 2013 3:00 am

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.

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: confused about something about sprite rendering

Post by tokumaru » Thu Feb 14, 2013 5:04 am

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.
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.
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.

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: confused about something about sprite rendering

Post by tepples » Thu Feb 14, 2013 8:40 am

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.

User avatar
ember
Posts: 7
Joined: Sun Dec 30, 2012 10:14 am

Re: confused about something about sprite rendering

Post by ember » Thu Feb 14, 2013 9:58 am

THANKS! My SMB1 works fine after modified my sprite-0-hit trigger!

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: confused about something about sprite rendering

Post by Dwedit » Thu Feb 14, 2013 10:41 am

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!

Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: confused about something about sprite rendering

Post by Sik » Thu Feb 14, 2013 11:58 am

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?).

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: confused about something about sprite rendering

Post by tepples » Thu Feb 14, 2013 2:48 pm

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.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: confused about something about sprite rendering

Post by blargg » Thu Feb 14, 2013 6:10 pm

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.

User avatar
ember
Posts: 7
Joined: Sun Dec 30, 2012 10:14 am

Re: confused about something about sprite rendering

Post by ember » Fri Feb 15, 2013 9:19 pm

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?

Post Reply