im taking scanlines as -1 trough 239.
Does the pre-render (in my case -1) scanline evalutate sprites?
thx in advance.
Does the pre-render (in my case -1) scanline evalutate sprites?
thx in advance.
I always wondered this as well. Several documents say that the reason this scanline exists is to start the sprite evaluation process, but that sounds really bogus, since no sprites are ever displayed in the first visible scanline.
I know that the first couple of background patterns for the next scanline are fetched at the end of each scanline though, so that might be the reason why the pre-render scanline exists.
I know that the first couple of background patterns for the next scanline are fetched at the end of each scanline though, so that might be the reason why the pre-render scanline exists.
tokumaru wrote:
I always wondered this as well. Several documents say that the reason this scanline exists is to start the sprite evaluation process, but that sounds really bogus, since no sprites are ever displayed in the first visible scanline.
I know that the first couple of background patterns for the next scanline are fetched at the end of each scanline though, so that might be the reason why the pre-render scanline exists.
I know that the first couple of background patterns for the next scanline are fetched at the end of each scanline though, so that might be the reason why the pre-render scanline exists.
It is not bogus.
Sprite evaluation is a 2 step process. Sprites are first evaluated, then loaded, then displayed.
Evaluation of the NEXT scanline's sprites are occuring while the sprites evaluated last scanline are being displayed. After evaluation, sprite data is fetched near the end of the scanline in Hblank, which will then be shown on the next scanline. This pipelining is required since rendering cannot be stopped to fetch sprites.
I'm sure you know much more about this than I do, but I really don't get it.
Exactly. If the sprite rendering process really starts in the pre-render scanline, the NEXT scanline is the first rendered one, but it doesn't have any sprites. What's the point of doing the whole sprite evaluation process and pattern fetching during the pre-render scanline if the NEXT scanline doesn't have sprites at all?
kevtris wrote:
Evaluation of the NEXT scanline's sprites are occuring while the sprites evaluated last scanline are being displayed.
Exactly. If the sprite rendering process really starts in the pre-render scanline, the NEXT scanline is the first rendered one, but it doesn't have any sprites. What's the point of doing the whole sprite evaluation process and pattern fetching during the pre-render scanline if the NEXT scanline doesn't have sprites at all?
As I understand it, the PPU doesn't evaluate or fetch sprites during y=-1 (the pre-render scanline). All it does is fetch the first two tiles of the first scanline's background.
That's what I figured, but a lot of documents (including our wiki) say that the reason the pre-render scanline exists is the evaluation of sprites, which confuses me to this day.
tepples wrote:
As I understand it, the PPU doesn't evaluate or fetch sprites during y=-1 (the pre-render scanline). All it does is fetch the first two tiles of the first scanline's background.
Doesn't it still do the dummy fetches though?
Now I am confused. Right, in my emulator, the dummy scanline fetches sprites.
Zepper wrote:
Now I am confused. Right, in my emulator, the dummy scanline fetches sprites.
What I meant is the dummy fetches occur because no sprites are in view.
So which is it? Dummy reads or not, the purpose of the pre-render scanline can't be to get the sprite system going, since no sprites are displayed in the next scanline. To me it really seems like the purpose is to get the background rendering started, since the first couple of background patterns are fetched at the end of the previous scanline.
Isn't it possible they just don't get sprites, but run the same functions as a normal scanline with the fetching? Although, if you think about that, that'd mean it'd fetch all sprites of $FF, which would put a line at the top of the screen of sprites, and then block out all on the top. So that right there makes it say it just doesn't fetch sprites.
I'm actually contesting 2 things here:
1. What the PPU actually does during the pre-render scanline;
It may very well be performing the sprite logic, but since it's impossible to put sprites at coordinate -1 they will never show up in the first rendered scanline. This makes me wonder though, why didn't they look for sprites at Y coordinate 0 during scanline -1 so that the Y coordinates of the sprites would match the screen coordinates rather than be off by 1?
2. The fact that lots of documents say the purpose of the pre-render scanline is to kickstart the sprite rendering system;
Since no sprites are displayed in the first rendered scanline, this can't possibly be the purpose of the pre-render scanline. I'm not saying the documents are wrong about what they say the PPU does during that time (as I can't possibly verify that myself), but that they are wrong about why the PPU does it.
1. What the PPU actually does during the pre-render scanline;
It may very well be performing the sprite logic, but since it's impossible to put sprites at coordinate -1 they will never show up in the first rendered scanline. This makes me wonder though, why didn't they look for sprites at Y coordinate 0 during scanline -1 so that the Y coordinates of the sprites would match the screen coordinates rather than be off by 1?
2. The fact that lots of documents say the purpose of the pre-render scanline is to kickstart the sprite rendering system;
Since no sprites are displayed in the first rendered scanline, this can't possibly be the purpose of the pre-render scanline. I'm not saying the documents are wrong about what they say the PPU does during that time (as I can't possibly verify that myself), but that they are wrong about why the PPU does it.
Well when we get enough PPU's to send for decapping, we will then REALLY know.....how long does that take? A couple weeks?
tokumaru wrote:
This makes me wonder though, why didn't they look for sprites at Y coordinate 0 during scanline -1 so that the Y coordinates of the sprites would match the screen coordinates rather than be off by 1?
Inexperience, I guess. The NES PPU was Nintendo's first attempt at making a TMS9918-style VDP after someone in Nintendo saw the promise of the ColecoVision. (See topic 5039.) As I understand it, the video circuit in most arcade games of the time, such as the Radar Scope board that the Donkey Kong games ran on, tended to have only enough OAM entries for one scanline.
Quote:
2. The fact that lots of documents say the purpose of the pre-render scanline is to kickstart the sprite rendering system;
Please find me the places on wiki.nesdev.com that still say this, and I'll go fix them.
tepples, he already pointed out a place in the wiki. 
EDIT: never mind, it has been edited. ^_^;;
tokumaru wrote:
That's what I figured, but a lot of documents (including our wiki) say that the reason the pre-render scanline exists is the evaluation of sprites,
which confuses me to this day.
which confuses me to this day.
EDIT: never mind, it has been edited. ^_^;;
That's the only place in the wiki where I saw this information. I'm sure I have read this in some "classic" documents as well, but there's nothing we can do about those.
tokumaru wrote:
That's the only place in the wiki where I saw this information. I'm sure I have read this in some "classic" documents as well, but there's nothing we can do about those.
I was thinking about that a while after I read it (and subsequently wrote the rendering page on the wiki). It makes sense for sprite evaluation to take place during the dummy scanline, but due to the 1-scanline offset of the sprites, that's obviously not what's happening.
I wonder if the dummy scanline is a last-minute fix for some kind of problem BG rendering had, and they either didn't have time or had issues with the sprite rendering engine operating during a "blanked" scanline.
Maybe it's so that the first visible scanline doesn't display random garbage for sprites?
kevtris wrote:
tokumaru wrote:
I always wondered this as well. Several documents say that the reason this scanline exists is to start the sprite evaluation process, but that sounds really bogus, since no sprites are ever displayed in the first visible scanline.
I know that the first couple of background patterns for the next scanline are fetched at the end of each scanline though, so that might be the reason why the pre-render scanline exists.
I know that the first couple of background patterns for the next scanline are fetched at the end of each scanline though, so that might be the reason why the pre-render scanline exists.
It is not bogus.
Sprite evaluation is a 2 step process. Sprites are first evaluated, then loaded, then displayed.
Evaluation of the NEXT scanline's sprites are occuring while the sprites evaluated last scanline are being displayed. After evaluation, sprite data is fetched near the end of the scanline in Hblank, which will then be shown on the next scanline. This pipelining is required since rendering cannot be stopped to fetch sprites.
Kevtis is right it is not bogus. The pre-render scanline actaully evaluate sprites and is needed.
Anes wrote:
Kevtis is right it is not bogus. The pre-render scanline actaully evaluate sprites and is needed.
Yeah, we already concluded that. My point was that the purpose of the pre-render scanline is not to evaluate sprites for the first scanline, since we all know that sprites are never displayed there.
tokumaru wrote:
Anes wrote:
Kevtis is right it is not bogus. The pre-render scanline actaully evaluate sprites and is needed.
Yeah, we already concluded that. My point was that the purpose of the pre-render scanline is not to evaluate sprites for the first scanline, since we all know that sprites are never displayed there.
Yeah that's right.