nesdev.com
http://forums.nesdev.com/

Pixel 250->256 change
http://forums.nesdev.com/viewtopic.php?f=3&t=9690
Page 1 of 2

Author:  Zepper [ Fri Jan 11, 2013 6:02 am ]
Post subject:  Pixel 250->256 change

Well, it's been a long time since the affirmation of Y incrementing at dot 251 (pixel 250), and now it comes that it occurs at 256 instead, for my surprise. I remember of someone said of such condition (at 251) as "essential" for Battletoads in terms of accuracy.

Could someone clarify such change? I read it at the wiki right now.

Author:  James [ Fri Jan 11, 2013 8:03 am ]
Post subject:  Re: Pixel 250->256 change

where do you see that in the wiki?

Author:  tepples [ Fri Jan 11, 2013 8:14 am ]
Post subject:  Re: Pixel 250->256 change

The wiki's copy of "The skinny on NES scrolling" has been completely overhauled.

I think the issue is this:
"At dot 256 of each scanline: If rendering is enabled, the PPU increments the vertical position in v."

That used to say 251.

Author:  Zelex [ Fri Jan 11, 2013 8:15 am ]
Post subject:  Re: Pixel 250->256 change

I thought the end of a scanline was X==341 (with the exception of the pre-scanline which alternates between 340 and 341)

Nevermind, your talking about something else.

Author:  Quietust [ Fri Jan 11, 2013 8:37 am ]
Post subject:  Re: Pixel 250->256 change

It was something I posted on the Talk page after doing some testing with Visual2C02 - effectively, the VRAM address increments both the H and V bits at dot 256 and then reloads the H bits one pixel later (dot 257).

Author:  Zepper [ Fri Jan 11, 2013 8:55 am ]
Post subject:  Re: Pixel 250->256 change

Thanks Q. :)

Author:  James [ Fri Jan 11, 2013 9:04 am ]
Post subject:  Re: Pixel 250->256 change

Quietust wrote:
It was something I posted on the Talk page after doing some testing with Visual2C02 - effectively, the VRAM address increments both the H and V bits at dot 256 and then reloads the H bits one pixel later (dot 257).

Thanks. BTW, does dot = 0-based cycles? i.e., dot 0 = cycle 0.

Author:  Quietust [ Fri Jan 11, 2013 9:27 am ]
Post subject:  Re: Pixel 250->256 change

I'm assuming the 0-340 "dot" timings, though the PPU actually starts outputting pixels at "dot 1" and stops outputting them at the end of "dot 256".

Author:  tokumaru [ Sat Jan 12, 2013 9:39 am ]
Post subject:  Re: Pixel 250->256 change

Quietust wrote:
I'm assuming the 0-340 "dot" timings, though the PPU actually starts outputting pixels at "dot 1" and stops outputting them at the end of "dot 256".

Now that's confusing, because we're used to counting pixels from 0 to 255...

So there are 341 dots, numbered 0 through 340, but there's 1 dot before the visible area of the scanline? The scroll counters are updated at the same time that the last pixel is rendered (dot 256)? Which dot is skipped every other frame when rendering is enabled?

Author:  Bregalad [ Sat Jan 12, 2013 9:51 am ]
Post subject:  Re: Pixel 250->256 change

I think the numering is arbitrary really. There is a periodic thing that takes 341 cycles, 256 of them being visible pixels and 85 of them being hblank.
There is 341 ways to number this, but only 2 of them really make sense :
1) Put the HBlank before the visible scanline
2) Put the HBlank after the visible scanline

Also the dots can be numbered from 1 to 341 or from 0 to 340, it's a matter of preference.

For some reason Nintedulator and all the NEStech docs uses the second one when I think the 1st one would make more sense, especially when you know sprites are evaluated during HBlank for what they will be displayed on the following drawn pixels. Depending on where you "imagine" the HBlank it could be the same scanline or the following scanline. Probably the reason HBlank was placed "after" the scanline is because the NNI fires after the last HBlank. (I think, I don't know all this stuff by heart so I might be wrong).

Author:  tokumaru [ Sat Jan 12, 2013 10:14 am ]
Post subject:  Re: Pixel 250->256 change

Bregalad wrote:
There is 341 ways to number this, but only 2 of them really make sense :
1) Put the HBlank before the visible scanline
2) Put the HBlank after the visible scanline

Well, Quietust apparently put 1 cycle of HBlank before the visible scanline and 84 after. With so many ways to number these thinks, I can never know what people actually mean when they say "the vertical scroll increments at dot 256". IMO these times should all be relative to the pixels, because they are easy to visualize, and not two numbering styles running in parallel so that you have to constantly convert between them to understand what happens when.

Author:  blargg [ Sat Jan 12, 2013 12:42 pm ]
Post subject:  Re: Pixel 250->256 change

I'd think they'd be numbered relative to whatever internal counter keeps track of the 341 count. When it's zero, you're on dot zero, even if the first pixel starts on dot 42.

Author:  Zepper [ Sat Jan 12, 2013 7:56 pm ]
Post subject:  Re: Pixel 250->256 change

Example: "at pixel 256", is this the 256th PPU pixel or it's being counted from zero, as "pixel 0, pixel 1... pixel 255"?
For my best (most of you will disagree), "256th PPU pixel" means the output pixel number counted from 1 up to 256, and "dot" as the relative PPU scanline cycle, starting at zero, after the last HBlank cycle).

Author:  blargg [ Sat Jan 12, 2013 8:15 pm ]
Post subject:  Re: Pixel 250->256 change

My take on naming:

"at pixel 256" is referring to the pixel with the label 256, sort of like "at pixel Marvin". So the meaning of 256 here depends on how we've defined them. Usually this means they're numbered from 0, otherwise we'd just say the 256th pixel if they were numbered from 1.

"at the 257th pixel" uses the standard definition of 257th, that is, that there are 256 prior pixels.

Author:  Zepper [ Sat Jan 12, 2013 8:38 pm ]
Post subject:  Re: Pixel 250->256 change

I got it.

Page 1 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/