NintendoAge http://nintendoage.com/forum/ -Sqooner Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-20T17:38:20 -05.00 bigjt_2 13 Originally posted by: mewithoutYou52

Ohh, thanks for this. I was wanting to learn how to load different nametables ahead of time for scrolling, so I'll definitely take a look at this!

If anyone has any ?s, feel free to PM me or post on the thread.  That background scroller may not be the most ideal, it's just what I've been able to make work so far.  Mario's Right Nut found a bug yesterday where it malfunctions if you change the amount of INC/DEC on the xScroll variable.  I have a temporary working fix that requires changing a couple of hard-coded numbers in the main ASM file.  If anyone else runs into it, let me know and I'll tell you which two numbers to change.
]]> Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-20T17:34:49 -05.00 bigjt_2 13 Originally posted by: albailey


So in summary, if you are going to put a status area on the bottom of your screen, make sure you load it into both $2000 and $2400 nametables, and make sure that at least the top line of the status region runs continuously the entire width. 

Al



I actually noticed this, too, when I first started messing around with the Sprite 0 code a couple weeks ago.  I was originally trying to make my status bar like SMB1s where it seems transparent and only the bottom of the coin is the sprite used for intersection.  As soon as that sprite leaves the non-transparent pixels background, everything crashes.  The best thing to do is what Al suggested above.  I still have no clue how SMB1 got it to work.  (Perhaps moved the sprite as the screen scrolled?  I have no idea.)  But then I guess that game is programmed a little oddly, from what I've heard.
]]> Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-20T15:22:55 -05.00 bigjt_2 13 Originally posted by: bunnyboy

Originally posted by: albailey

; FINE X scrolling updates right away, but I do not care so long as the status bar color is the same all the way through nametable $2000 and $2400. Otherwise I will see crawling.
LDA X_SCROLL
STA $2005 ; first write is X scrolling
LDA #$00
STA $2005 ; second write is Y scrolling

What I have done is timed loops starting when the sprite 0 hit happens.  If you can get your $2005 writes to happen at the end of the scanline, when the PPU is fetching sprite data, you won't see any graphical glitches.  Sprite fetching is long enough to account for the variable width crawl.
One other observation about crawling, but not directly pertaining to "fine X" scrolling.

I had a bug a while back where I was using a status area at the bottom of the screen, and was placing the sprite zero on the top row of that status area (around row 22).

My bug was that because I placed the sprite zero in the status area, a portion of that status area would scroll as part of the game scrolling region. This was noticeable because I made the status region not run the entire width of the screen.  This meant I had not used a solid line at the top of my status area, and I could visually see it moving across the screen. 

The bug was actually more serious than just a graphical glitch, because the crawling meant that when an all transparent background  tile scrolled to the location of the sprite zero, I did not get my sprite zero collision, and therefore my NMI routine never returned properly, etc..

I would not have had this problem with a status region at the top of the screen, because the only "crawling" that would be seen is the fine X scroll that Brian alluded to in his post.

A possible work around would have been to locate sprite zero above the status area, but in my opinion that can also lead to trouble, since you need to remember to make sure you do not have fully transparent background blocks in the game area for that row, otherwise you can hit the same problem.

So in summary, if you are going to put a status area on the bottom of your screen, make sure you load it into both $2000 and $2400 nametables, and make sure that at least the top line of the status region runs continuously the entire width. 

Al

]]> Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-20T14:18:31 -05.00 bigjt_2 13 Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-20T13:44:29 -05.00 bigjt_2 13 Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-19T13:27:02 -05.00 bigjt_2 13
Got it working on the top.  Thanks again, Al!  I'm posting the new demo in case any other noobs like myself are messing around with scrolling/Sprite 0 split and need a working demo to reference for their own projects.

Also, this one doesn't have the updating counter on the scrolling bar, but I did get the better controller reading working on the demo with the status bar at the bottom, as well.  So thanks for the help with controller input, Metalslime and Mario's Right Nut.  That also helped me finally get a pause function working on the pong game I made.  Woo-hoo!

Lastly, I took an hour and cleaned up my comments so they ACTUALLY reflected the code.  Novel idea, I know.  I will warn that the comments on the demo with status bar at the bottom have not been checked over and are inaccurate.  The comments in this demo should be fine, though.
]]> Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-18T12:02:50 -05.00 bigjt_2 13 Originally posted by: albailey

; FINE X scrolling updates right away, but I do not care so long as the status bar color is the same all the way through nametable $2000 and $2400. Otherwise I will see crawling.
LDA X_SCROLL
STA $2005 ; first write is X scrolling
LDA #$00
STA $2005 ; second write is Y scrolling

What I have done is timed loops starting when the sprite 0 hit happens.  If you can get your $2005 writes to happen at the end of the scanline, when the PPU is fetching sprite data, you won't see any graphical glitches.  Sprite fetching is long enough to account for the variable width crawl. ]]> Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-18T11:39:58 -05.00 bigjt_2 13 Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-12T20:39:16 -05.00 bigjt_2 13
The premise of putting the status bar at the top, is to remember to reset both the nametable page (register $2000) as well as both scroll registers ($2005).

Then you wait for sprite zero to be reset (this happens at the end of vblank)
Then you wait for sprite zero to be set (this happens when the screen draws sprite zero, and at least two of its pixels intersect the status area)
Then you set the nametable correctly in register $2000 (either $2000 or $2400) and the scroll correctly.

Here's example code:

nmiHandler:
; NMIs can be called anywhere at any time, so lets protect A,X,Y by putting them on the stack
PHA ; 3 cycles
TXA ; 2 cycles
PHA ; 3 cycles
TYA ; 2 cycles
PHA ; 3 cycles so 13 CPU cycle setup cost to protect A,X,Y (and another 16 to restore things back at the end of the RTI)


LDA $2002 ; reset address latch


; update the graphics, etc..

; reset the status region to nametable of register PPU Control Register $2000 to be the nametable where the status region is located (usually $2000)
LDA #%10001000
STA $2000
; Reset the scrolling
LDA #$00
STA $2005
STA $2005

; sprite DMA
lda #$02
sta $4014

; Credit to DVDmth and DWEdit and Disch for helping me with sprite 0 detection
; I do not care what is in the accumulator. The BIT command will set overflow based on bit 6 of memory address ($2002)
; Basically here is what happens with Sprite #0. The hit flag is set and stays set for the entire frame and not cleared until scanline #0 starts (end of vblank)
; Hit flag gets set when a non color 00 background instersects a non 00 color sprite pixel. This cannot occurs at X position 255

; Wait for Scanline #0 to reset the Sprite #0 hit flag
: BIT $2002
BVS :-

; Wait for the first intersected pixel of sprite #0 to be rendered
: BIT $2002
BVC :-

; Now set the screen and scroll for the game part
LDA CURRENT_SIDE_SCROLLER_DATA
STA $2000

; FINE X scrolling updates right away, but I do not care so long as the status bar color is the same all the way through nametable $2000 and $2400. Otherwise I will see crawling.
LDA X_SCROLL
STA $2005 ; first write is X scrolling
LDA #$00
STA $2005 ; second write is Y scrolling

etc..
Al

]]> Top Status Bar and Controller Question http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=33132 2010-05-12T18:52:58 -05.00 bigjt_2 13 ]]>