I have it working where I can load multiple nametables and walk several screens length without any glitches and smooth scrolling (and man what a pain it was). Its great except for one thing. I load 32 tiles all the way across the screen whenever I step 8 pixels, so that I am not loading the whole nametable at once, but the problem with this is that the attribute table info is at the very end of the nametable data, so while all the tiles on the new map show up fine, the old attributes (colors) are showing up from the previous map I just scrolled off of until I have scrolled the whole new table onto the screen. <-- (wow that was a long sentance!). Then the attributes get loaded last and the whole screen changes colors before your eyes into the correct colors. I will try to load the attribute table for each new nametable first and see what that does, but I was wondering if there was a standard fix for this or if I am going about things the right way.

I realize that explanation wasn't very clear, if parts are confusing please ask me to reword it. Thanks!

-Pulper

Yeah, the attribute table can be a pain. I still don't have a really elegant solution for working with it, myself.

I believe you'll want to update 2 attribute bytes for every 32 tiles. Or 1 every 16 tiles, or 4 every 64 tiles. Whichever way seems best for you.

Of course, there will be a part of the nametable that will have the wrong attribute settings, but this should be on part of the nametable that will always be off-screen. By the time you update 64 tiles and 4 attribute bytes, it should be evened out and be ready to scroll into view.

If i'm using one-screen or horizontal mirroring, doesn't the attribute glitch have to be on the screen for a 1-8 pixel column?

Abonetochew

Well I gave it a shot but the attributes are still way off and crazy. I update 32 tiles every 8 pixels of movement, so I updated 2 attribute bytes every 32 tiles.

I'm thinking maybe the problem is that my offset added to the location of the attribute table low byte is rolling over at some point to $00 and leaping to an incorrect part of my nametable, then writing that as the last few attribute bytes. Does that sound possible or am I just flailing in the dark here? Here is the attribute code fully commented :-)


;--DRAW 2 BYTES OF ATTRIBUTE TABLE NOW--;

;If using $28, attribute table starts at $2BC0
;If using $20, starts at $23C0
lda whichnam ;will be either $28 or $20
cmp #$28
beq attr2 ;if its not $28, it must be $20, so continue from here

lda #$23
sta $2006 ;high byte of first attribute table
lda attroff1 ;low byte offset will go from $C0 to $FF
sta $2006 ;$2006 now knows where to copy nametable data TO.

;Address of correct map location is already in $0010 and $0011 from code before

ldy attroff1
ldx #0
attr0:
lda [$10],y
sta $2007
iny
inx
cpx #2 ;only draw 2 bytes of the next attr table at a time
bne attr0
sty attroff1 ;y increments 2 bytes and gets stored for next time
jmp endattr ;SKIP over the rest of the attribute code

attr2: ;we jumped to here if it was nametable $28xx
lda #$2B
sta $2006
lda attroff1 ;can use same variable as before because it still goes from $C0 to $FF
sta $2006 ;and it was reset to $C0 after the last nametable flipped.

ldy attroff1
ldx #0
attr3:
lda [$10],y
sta $2007
iny
inx
cpx #2
bne attr3
sty attroff1 ;we are done updating the attribute table a whole 2 bytes, wow!

endattr:

;--END OF ATTRIBUTE TABLE UPDATING--;


-Pulper

Yeah, the attribute address in the Y register will roll over. You'll probably want to do something like INY / BNE, where the BNE branches over an LDY #$C0 instruction.

BTW, you can make that loop a little smaller and faster by changing the LDX #0 to LDX #2, then with a DEX / BNE you won't need the CPX instruction.

Yeah, for horizontal scrolling (using H mirroring or one-screen) I think the attribute glitch will have to be partially visible.

But for vertical scrolling, almost all NTSC TVs cut off enough of the screen to where it would probably be hardly noticable, if it all, if it was done right. I believe the numbers given are like 240 pixels on screen, but only about 224 are supposedly visible.

That would require some trickery though, because one attribute byte will affect 32x32 pixels. So you'd have to update the nametable 4 bits at a time.

Oh wait, I was assuming that the 'attroff1' byte was starting at $C0. If the address at $10 is pointing directly to the attribute table, then of course you'd do the CPY #$40 / BNE + / LDY #0 / + thing.

the attroff1 byte does start at $C0, and is reset to $C0 once it reaches $FF later on in the NMI. Upon entering the attribute section, the address at $10 and $11 is not pointing directly to the attribute table, but directly at the beginning of the nametable data for that map. I don't know how to get it to point directly at the attribute table. That is why I have to do the freakish offset stuff. Point to the beginning of nametable, then offset by $3C0.
I made a couple changes, I had forgotten to take care of the high byte of the offset, and I tried to account for y rolling over but I don't think indexed addressing sets the zero bit:

;--DRAW 2 BYTES OF ATTRIBUTE TABLE NOW--;

;If using $28, attribute table starts at $2BC0
;If using $20, starts at $23C0
lda whichnam ;will be either $28 or $20
cmp #$28
beq attr2 ;if its not $28, it must be $20, so continue from here

lda #$23
sta $2006 ;high byte of first attribute table
lda attroff1 ;low byte offset will go from $C0 to $FF
sta $2006 ;$2006 now knows where to copy nametable data TO.

;Address of beginning of nametable location is already in $0010 and $0011 from code before

lda $11
clc ;***NEW***
adc #3 ;high byte offset is $3 because offset is $3C0
sta $11

ldy attroff1 ;this starts from $C0 and goes to $FF
ldx #2
attr0:
lda [$10],y
;***NEW***
bne temp9 ;if $10 + y rolls over to 0, add one to the high
lda $11 ;byte offset but I don't think this works with indirect
clc ;addressing
adc #1

temp9:
sta $2007
iny
dex
;only draw 2 bytes of the next attr table at a time
bne attr0
sty attroff1 ;y increments 2 bytes and gets stored for next time
jmp endattr ;SKIP over the rest of the attribute code

attr2: ;we jumped to here if it was nametable $28xx
lda #$2B
sta $2006
lda attroff1 ;can use same variable as before because it still goes from $C0 to $FF
sta $2006 ;and it was reset to $C0 after the last nametable flipped.

ldy attroff1
ldx #0
attr3:
lda [$10],y
sta $2007
iny
inx
cpx #2
bne attr3
sty attroff1 ;we are done updating the attribute table a whole 2 bytes, wow!

endattr:

;--END OF ATTRIBUTE TABLE UPDATING--;


-Pulper

Its fixed. I ended up loading all 64 bytes of the attribute table as soon the first part of the next nametable started to be drawn. I then had to end my drawing after 960 bytes were drawn instead of 1024 so I didn't draw the attributes twice and screw up my timing.

It was really tricky to get this working, I ended up creating a subroutine which put the location of the correct attribute table in addresses $12 and $13, then I could work with that in the NMI. It is awesome to be able to walk down 10 screens worth of data.

Now I will start sprite 0 detect so my dude doesn't walk right over mountains.

-Pulper