It is currently Mon Jul 23, 2018 5:12 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Sun Feb 07, 2016 7:49 pm 
Offline

Joined: Tue Jul 09, 2013 7:13 am
Posts: 61
Ive been looking as a .rom nocarrier made called gallerynes to load a sequence of .nam files. I am trying to remove the blank frame each time a new .nam is loaded.

I can't work out how to approach it though as I assume you need to vblank before loading a new .nam so it loads cleanly but the vblank is causing the blank frame?

I have put a pastebin here of the code.

http://pastebin.com/p50y8HER

What I am eventually trying to do is create a little rom to load a series of say 10 .nam files to make little full screen "page flip" animations like in the high hopes demo by aspect. The effect shown here

https://youtu.be/eQ-OcS2Gwvk?t=72

And as far as I can work out, there isn't a blank frame shown during the "animation"

Anyone know where I would start?

thanks!


Last edited by lazerbeat on Sat Mar 12, 2016 5:06 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Feb 07, 2016 8:11 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
Normally, the blank frames between different screens are there because vblank doesn't provide enough time to change large amounts of VRAM data, so rendering has to be turned off to give the programmer full access to VRAM.

If the name tables are not being scrolled, you could instead load the new graphics progressively to the hidden name table across several frames during vblank (like, 128 or so bytes per vblank, instead of the whole 1024 bytes at once), and then switch to that name table when you're done. This technique is called "double buffering".


Top
 Profile  
 
PostPosted: Sun Feb 07, 2016 8:22 pm 
Offline

Joined: Tue Jul 09, 2013 7:13 am
Posts: 61
Thats awesome, I will give that a try. I am sorry if this is a silly question, would I need to reload the attribute table as well or just the .nam file?


Top
 Profile  
 
PostPosted: Sun Feb 07, 2016 8:26 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
lazerbeat wrote:
would I need to reload the attribute table as well

If the image uses more than 4 colors, yes, you probably have to modify the attribute table as well.

Quote:
or just the .nam file?

How big are your .nam files? If they're 1024 bytes, the attribute table is included, if not, they'll be 960 bytes.


Top
 Profile  
 
PostPosted: Sun Feb 07, 2016 8:28 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20291
Location: NE Indiana, USA (NTSC)
Use both nametables. While you are showing one in $2000-$23FF, load the other to $2C00-$2FFF, 128 bytes at a time. Then when it's done, switch to the other nametable and its pattern table by changing the value written to PPUCTRL ($2000). Then vice versa.


Top
 Profile  
 
PostPosted: Sun Feb 07, 2016 8:40 pm 
Offline

Joined: Tue Jul 09, 2013 7:13 am
Posts: 61
Quote:
or just the .nam file?

How big are your .nam files? If they're 1024 bytes, the attribute table is included, if not, they'll be 960 bytes.[/quote]

They are 1024. Ok so I can set a counter for 8 frames, load 128 bytes each frame then transfer everything and reset the counter and in theory no flicker?

Nice little project for this week.


Top
 Profile  
 
PostPosted: Sun Feb 07, 2016 9:00 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
You're gonna need some extra variables in order to keep track of the extra state this will require. For example, if the program currently uses a single name table, this is hardcoded into the program. To change this you'll need a variable to indicate which name table is being displayed, so you can toggle this setting as necessary.

You'll also probably need a flag indicating whether a name table is being updated behind the scenes or not. This flag will be used by the NMI handler to decide whether it should transfer a 128-byte chunk of data or not.


Top
 Profile  
 
PostPosted: Sun Feb 07, 2016 9:07 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2156
Location: DIGDUG
I don't mind the flicker. It's one frame of black screen. It doesn't seem so bad to me. Seems like a lot of unnecessary programming just to avoid it.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sun Feb 07, 2016 9:22 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
dougeff wrote:
Seems like a lot of unnecessary programming just to avoid it.

I disagree. For a beginner, it's good practice, and for more experienced coders, it shouldn't take more than 30 minutes to do.


Top
 Profile  
 
PostPosted: Mon Feb 08, 2016 12:01 am 
Offline

Joined: Tue Jul 09, 2013 7:13 am
Posts: 61
Actually, I had a follow up question. If the 2nd name table is being loaded "off screen" why is is necessary to load it 128 bytes at a time?

I totally trust you guys that it IS necessary, I would just clearly like to understand why.


Top
 Profile  
 
PostPosted: Mon Feb 08, 2016 12:32 am 
Offline

Joined: Mon Oct 10, 2011 9:05 am
Posts: 22
Because the register that holds the PPU address is used internally by the PPU when rendering, so the value becomes unstable. This is true even for writing to VRAM that is not being used in the current display. As far as the number of bytes to write to the PPU, since you can only do that in Vblank when the display is on you have about 2300 cycles to do it and depending on how optimized your code is for speed you can write around 128~150ish bytes at a time.


Top
 Profile  
 
PostPosted: Mon Feb 08, 2016 1:24 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6431
Location: Canada
lazerbeat wrote:
Actually, I had a follow up question. If the 2nd name table is being loaded "off screen" why is is necessary to load it 128 bytes at a time?

I totally trust you guys that it IS necessary, I would just clearly like to understand why.


You have a few thousand cycles in vblank where the NES is not drawing the screen. This is the only time you have to access the PPU. Any other time during the frame and the PPU is busy drawing the screen; trying to send data to it while it's doing that will corrupt your nametables and rendering.


Top
 Profile  
 
PostPosted: Mon Feb 08, 2016 7:16 pm 
Offline

Joined: Tue Jul 09, 2013 7:13 am
Posts: 61
Right so even if you are writing to the name table the PPU isn't currently displaying
rainwarrior wrote:
You have a few thousand cycles in vblank where the NES is not drawing the screen. This is the only time you have to access the PPU. Any other time during the frame and the PPU is busy drawing the screen; trying to send data to it while it's doing that will corrupt your nametables and rendering.


Thanks I didn't realize this applied even when writing to the nametable the PPU ISN'T currently displaying.


Top
 Profile  
 
PostPosted: Mon Feb 08, 2016 9:24 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
A hidden name table is still part of the same memory as the visible name table, and that memory cannot be used for anything else while the PPU is rendering the picture.


Top
 Profile  
 
PostPosted: Wed Feb 10, 2016 7:22 am 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 953
Location: Japan
My old demos, Motion / Flame do this nametable double-buffering and flipping, if you want to check out the code for them (though ignore any bad coding practices that you find. ;-D)

http://www.chrismcovell.com/data/anims.zip

Image

_________________
http://www.chrismcovell.com


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

All times are UTC - 7 hours


Who is online

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