It is currently Wed Nov 22, 2017 7:04 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Pixel 250->256 change
PostPosted: Fri Jan 11, 2013 6:02 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
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.

_________________
Zepper
RockNES developer


Last edited by Zepper on Fri Jan 11, 2013 8:58 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Fri Jan 11, 2013 8:03 am 
Offline
User avatar

Joined: Sat Jan 22, 2005 8:51 am
Posts: 427
Location: Chicago, IL
where do you see that in the wiki?

_________________
get nemulator
http://nemulator.com


Top
 Profile  
 
PostPosted: Fri Jan 11, 2013 8:14 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19249
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri Jan 11, 2013 8:15 am 
Offline

Joined: Fri Apr 29, 2011 9:44 pm
Posts: 267
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.


Top
 Profile  
 
PostPosted: Fri Jan 11, 2013 8:37 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1392
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).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
PostPosted: Fri Jan 11, 2013 8:55 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
Thanks Q. :)

_________________
Zepper
RockNES developer


Top
 Profile  
 
PostPosted: Fri Jan 11, 2013 9:04 am 
Offline
User avatar

Joined: Sat Jan 22, 2005 8:51 am
Posts: 427
Location: Chicago, IL
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.

_________________
get nemulator
http://nemulator.com


Top
 Profile  
 
PostPosted: Fri Jan 11, 2013 9:27 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1392
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, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 9:39 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 9:51 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
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).


Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 10:14 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 12:42 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 7:56 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
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).

_________________
Zepper
RockNES developer


Last edited by Zepper on Sat Feb 09, 2013 12:44 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 8:15 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2013 8:38 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
I got it.

_________________
Zepper
RockNES developer


Last edited by Zepper on Sat Feb 09, 2013 12:44 pm, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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