It is currently Wed Sep 18, 2019 8:39 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1523 posts ]  Go to page Previous  1 ... 98, 99, 100, 101, 102
Author Message
PostPosted: Thu Jun 27, 2019 2:20 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
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).


Top
 Profile  
 
PostPosted: Thu Jun 27, 2019 5:15 pm 
Offline

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Thu Jun 27, 2019 10:14 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 161
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.


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 3:16 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1036
Location: cypress, texas
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?


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 3:35 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8559
Location: Seattle
$2006, $2005, and the two nametable bits in $2000 are all ways to access the same thing. nesdevwiki:PPU scrolling


Top
 Profile  
 
PostPosted: Mon Jul 01, 2019 3:48 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1036
Location: cypress, texas
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. :)


Top
 Profile  
 
PostPosted: Wed Jul 10, 2019 3:12 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1036
Location: cypress, texas
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:


Top
 Profile  
 
PostPosted: Tue Aug 06, 2019 8:35 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1036
Location: cypress, texas
unregistered, on pg. 98, 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).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1523 posts ]  Go to page Previous  1 ... 98, 99, 100, 101, 102

All times are UTC - 7 hours


Who is online

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