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.
where do you see that in the wiki?
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.
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.
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
Q.
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.
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".
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?
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).
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.
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.
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).
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.
I've used the terminology "at x=256". Is that unambiguous?
tepples wrote:
I've used the terminology "at x=256". Is that unambiguous?
That would be the 257th pixel, right?
I kinda wondered why we didn't start numbering at the left edge of the screen/signal. I don't know exactly what clock it's on, but there's a region at the start of the line before it starts rendering any sprite or nametable pixels that it will output the background colour.
Probably because the earliest we can detect within the scanline with sprite 0 is x=0 (the first rendered pixel).
Because of NMI, that's what defined pixel 0.
Yeah, the left border of the very first rendered scanline is the hblank of the pre-render scanline.
That's the point I disagree. Anyway, here my last $0.02:
a) Is there a special reason for using the word "dot" instead of "cycle"?
b) The word "pixel" would count effective pixels from 1, and not from zero.
I suggest to abandon the usage of "dot" as "ppu cycles"; just "cycle" is good enough, and it counts from zero. When saying "pixel", it's always from 1.
tepples wrote:
I've used the terminology "at x=256". Is that unambiguous?
Since x can be zero, you mean the 257th rendered pixel.
Does "cycle" refer to CPU cycles (1.8 MHz), PPU cycles (5.4 MHz), or master clock cycles (21.5 MHz)? "Dot" is less ambiguous. I seem to remember someone finally nailing down the terminology as "cycles" for the CPU, "dots" or "pixels" for the PPU, and "clocks" for the master clock. As for "dot" vs. "pixel", I'll look into that too.
EDIT: It was
this post by blargg.
The term "dot clock" is used in an
X server HOWTO.
To me dots are the timebase of the PPU, while pixels are the dots that actually paint something on screen, though I suppose that the video signal is always outputting something for every dot, like the background color, or the sync pulse. I think most people refer to only 256 of the 341 dots of a scanline as pixels.
The benefit of "dot" over "ppu cycle" is that the latter is more verbose, not entirely clear, and will be shortened to "cycle" in discussion, which might then be confused with the CPU.