It is currently Wed Nov 14, 2018 4:59 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Sep 12, 2018 6:43 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2037
Location: Fukuoka, Japan
Seems like a lot of fun! (Aim gun at foot and... :lol:)


Top
 Profile  
 
PostPosted: Wed Sep 12, 2018 10:06 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
One thing that I've wanted to see tried is a "short" scroll set, using just the last two: 2005/2006. It'll set fine X and coarse X, and the write to 2006 will guarantee they're in sync (and also set the lower 3 bits of coarse Y). But I'm not entirely sure what will happen to the Y scroll. I think the upper 5 bits of coarse Y will reset to the top of the screen, and I'm really not certain what will happen with fine Y.


Top
 Profile  
 
PostPosted: Wed Sep 12, 2018 10:55 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10962
Location: Rio de Janeiro - Brazil
lidnariq wrote:
I think the upper 5 bits of coarse Y will reset to the top of the screen, and I'm really not certain what will happen with fine Y.

Yeah, based on the "Skinny" doc, it does look like the original Y scroll, the one that remains unaltered in t, will be copied to v during that $2006 write. Why would you expect something different to happen to the fine Y scroll though?

Resetting the Y back to the top of the screen really limits the usefulness of this, and since you have to do some bit juggling to form that last $2006 value anyway, this is barely any simpler than the $2006/5/5/6 technique, which allows full control over both X and Y.


Top
 Profile  
 
PostPosted: Thu Sep 13, 2018 12:09 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7567
Location: Chexbres, VD, Switzerland
lidnariq wrote:
One thing that I've wanted to see tried is a "short" scroll set, using just the last two: 2005/2006. It'll set fine X and coarse X, and the write to 2006 will guarantee they're in sync (and also set the lower 3 bits of coarse Y). But I'm not entirely sure what will happen to the Y scroll. I think the upper 5 bits of coarse Y will reset to the top of the screen, and I'm really not certain what will happen with fine Y.

I see no reason why they'd be reset to the top of the screen, most likely it's untouched. Writing to $2005(/1) then $2006(/2) will result in being able to set some bits of the coarse Y scroll (within each 1/4 of the nametable; $2000-$20ff, $2100-$21ff, $2200-$22ff and $2300-$23bf), and to be honest I fail to see how that's any useful but if that's useful for you that's great.

Personally I much prefer the variant with just two $2006 writes, this allows to set the coarse scroll anywhere in the name tables, and leaves fine scroll untouched.

Quote:
As for color changes, I just avoid them altogether, too much stuff to watch out for. If scroll changes seem complicated, wait until you try palette changes! :twisted:

I'd agree - you're developing for a limited system on purpose just for the heck of it. I consider the NES palette to be a limitation, and changing the palette mid-frame is awfully complicated for very limited results. Only do that if you are absolutely sure you really need it. I find that re-using colours creatively is much more "the NES way to do it".


Top
 Profile  
 
PostPosted: Thu Sep 13, 2018 1:03 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2037
Location: Fukuoka, Japan
Bregalad wrote:
I'd agree - you're developing for a limited system on purpose just for the heck of it. I consider the NES palette to be a limitation, and changing the palette mid-frame is awfully complicated for very limited results. Only do that if you are absolutely sure you really need it. I find that re-using colors creatively is much more "the NES way to do it".


I would prefer not to but this is a special case were the asset was imported by a tool that extract the main image for the bg and if not enough color, uses sprites as overlays. This is working fine except there is 1 case where a palette animation causes 1 color to be affected. Since editing by hand what was automatically generated is difficult and I'm no artist, the code solution was more approachable for me. But I already have many issue to just change the palette while waiting for an nmi that it may have not been able because of too many variables in that scene having impact. I will just try for that part to use sprite overlays to cover the bg that change color that is not supposed to but this means creating that data, which is not simple but possible.


Top
 Profile  
 
PostPosted: Thu Sep 13, 2018 4:27 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10962
Location: Rio de Janeiro - Brazil
Bregalad wrote:
I see no reason why they'd be reset to the top of the screen, most likely it's untouched.

When the PPU is rendering, it increments the Y scroll in the v register, it doesn't change t at all. When you write to $2005, you update the X bits of t (Y bits still untouched). Then the write to $2006 can change the lower 3 bits of the coarse Y scroll in t, but the remaining bits are still unchanged since the top of the picture, and that's what will be copied to v. That's what lidnariq meant with resetting to the top of the screen.

Quote:
to be honest I fail to see how that's any useful

Same here.

Quote:
Personally I much prefer the variant with just two $2006 writes, this allows to set the coarse scroll anywhere in the name tables, and leaves fine scroll untouched.

Not untouched - the top bit of the fine Y scroll is cleared on the first $2006 write, so you can never scroll to a position on the lower half of a row of tiles. As for the fine X scroll, in most cases people will want to change that (parallax effects, status bars, etc.).


Top
 Profile  
 
PostPosted: Thu Sep 13, 2018 11:16 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7567
Location: Chexbres, VD, Switzerland
Oh I see, when doing $2005(1) and $2006(2) write it actually reset to the last used value when setting the scroll, which lidnarq called "top of the screen", which makes sense in the case where only this mean of scrolling is used mid-frame after a normal $2005 scroll in VBlank. I still fail to see how this'd be in any way useful.

Quote:
Not untouched - the top bit of the fine Y scroll is cleared on the first $2006 write, so you can never scroll to a position on the lower half of a row of tiles. As for the fine X scroll, in most cases people will want to change that (parallax effects, status bars, etc.).

What I meant is that $2006(1) $2006(2) as a way to scroll makes sense, is useful as it allows you to move coarse scroll anywhere. I can see many ways this is useful. It's still limited compared to $2006(1) $2006(2) $2005(1), or $2006(1) $2005(2) $2005(1) $2006(2), but it makes less registers to write and is actually useful.


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

All times are UTC - 7 hours


Who is online

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