8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
koitsu
Posts: 4214
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 8x16 and whatever else unreg wants to know

Post by koitsu » Thu Jun 27, 2019 2:20 pm

I'm coming in late, but: you generally do not:

1. Try to write an entire nametable (read: entire screen) worth of data in VBlank/NMI -- reasons have been covered already I think, but it takes too long / too much data
2. Turn off rendering unless you are absolutely positively 100% certain you know why you need to do it. In general you need to design your game/thing so that you do not have to do this.

I don't understand why you're trying to do #1. I don't think Tepples does either. Is this because you want to make it easy on yourself? If so, you're not going to win this battle. You need to learn how to update the edges of the screen (left and right columns when using the increment-by-32 mode of PPU addressing). Yes, writing the engine code that does all of this is (IMO) complicated and "not fun", there's a lot you have to keep track of.

Does this game/thing use panning/scrolling at all? If you're trying to do everything in single-screen and you aren't using panning/scrolling, my advice is: don't. Make use of the memory in the adjacent nametable and flip-flop between them using bits in $2000. You draw to the one that isn't visible, then switch to it, rinse lather repeat. This is effectively what's called "double buffering" (probably a term you've encountered somewhere before).

tepples
Posts: 21707
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples » Thu Jun 27, 2019 5:15 pm

If you're trying to animate a lot of stuff within the nametable, as in the FMV demos "Motion" by Chris Covell and "Bad Apple!! PV-FC 2" by someone else, then you should probably be using double buffering.

supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: 8x16 and whatever else unreg wants to know

Post by supercat » Thu Jun 27, 2019 10:14 pm

koitsu wrote:Does this game/thing use panning/scrolling at all? If you're trying to do everything in single-screen and you aren't using panning/scrolling, my advice is: don't. Make use of the memory in the adjacent nametable and flip-flop between them using bits in $2000. You draw to the one that isn't visible, then switch to it, rinse lather repeat. This is effectively what's called "double buffering" (probably a term you've encountered somewhere before).
Scrolling can be combined with double-buffered animation provided one isn't scrolling too fast, by using a few frames to draw new screen content in the parts of the nametable that aren't being displayed, and then in the last VBLANK update the areas that overlap the old frame and switch to showing the new one.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Mon Jul 01, 2019 3:16 pm

koitsu wrote:If you're trying to do everything in single-screen and you aren't using panning/scrolling, my advice is: don't. Make use of the memory in the adjacent nametable and flip-flop between them using bits in $2000. You draw to the one that isn't visible, then switch to it, rinse lather repeat. This is effectively what's called "double buffering" (probably a term you've encountered somewhere before).
Thank you koitsu for recommending double buffering! :D It should be all set up now, but there is a weird problem, Mesen switches to delay-display the nametable that we're writing to the instant that $2006 is completely written to (after the low byte). By delay-display, I mean that nametable 1 is highlighted in Mesen's Nametable Viewer after $2400 is written to $2006, and also that nametable 1 is displayed the next frame. This is weird bc $2000 is never changed... like you said, "Make use of the memory in the adjacent nametable and flip-flop between then using bits in $2000."

My goal was to see the entire screen drawn in nametable 1 b4 flip-flopping. Now it's way confusing. Is the NES susposed to behave this way? If so, why? :) And, otherwise I guess Mesen has been set up incorrectly by me. :(

edit: Also, the wiki didn't mention anything about $2006 changing what nametable is displayed. So maybe I've set Mesen up incorrectly?

lidnariq
Posts: 8691
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: 8x16 and whatever else unreg wants to know

Post by lidnariq » Mon Jul 01, 2019 3:35 pm

$2006, $2005, and the two nametable bits in $2000 are all ways to access the same thing. nesdevwiki:PPU scrolling

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Mon Jul 01, 2019 3:48 pm

lidnariq wrote:$2006, $2005, and the two nametable bits in $2000 are all ways to access the same thing. nesdevwiki:PPU scrolling
Ahha! Thank you lidnariq! :D I forgot they shared an internal register. :oops:

edit: Maybe that page could be linked to from the PPU registers page in the $2000, $2005, $2006 register sections... or on the PPU registers page maybe say something like, "these share an internal register"... that would be really helpful, IMHO. :)

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Wed Jul 10, 2019 3:12 pm

Now, the blinking is gone since the game now draws a 5th of each screen inside vblank! Thank you all so much! :D Time to decompress my sister's RLE... I'll be silent unless questions arrise. :)


edit: (this is an edit bc it's not important) our game isn't that efficient bc it does draw an 8th of each screen inside of vblank. Not a 5th, I'm sorry for my mistake.



final-edit-note: it actually draws an 8th, not a 7th, so the first edit was adjusted accordingly. :oops:

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Tue Aug 06, 2019 8:35 am

unregistered[color=#FF8040], on pg. 98,[/color] wrote:Ok, so asm6 is limited to 64 hex codes following its .hex. (i.e. When our game assembles, the cursor at the end of most of our .hex lines is in column 135. The hex codes start, after .hex, in column 7. 135-7=128. 128/2=64.) Why this limitation-have no clue right now. With 65 hex codes per line asm6 gives, "Not a number."
Now, it's evident that while, 64 hex codes following asm6's .hex will assemble, the 64th hex code is incorrectly tranferred to the ROM during assembly. The 64th code on the first RLE line in our game is #$BC but it was assembled as #$0B, #$0C... so after limiting each line of the first screen to 62 hex codes they assemble just fine. :)

It makes some sense that each line would be limited to less than 64 hex codes, but we're using 62 per line bc RLE uses 2 hex codes for each different value-set (though I'm sure 63 would work just fine too).

Post Reply