It is currently Wed Oct 18, 2017 9:54 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Sat Jul 22, 2017 10:22 am 
Offline

Joined: Sun Jun 25, 2017 3:32 pm
Posts: 10
Hello again all.

I'm getting to a point in my game where I'm considering adding a status bar, and even though I haven't dug into writing the code for it yet I'm foreseeing some issues.

I read the Advanced Nerdy Nights tutorial on using the sprite 0 hit to determine the scanline where you want to change your scroll. What I'm worried about is that it seems like when you do that you're spending a significant amount of time in your NMI handler just waiting for that sprite 0 hit. Now, I'm not totally sure how long it takes my main program loop to execute, or if there is even a way to know. But I recently incorporated horizontal scrolling into my program, and I'm noticing an intermittent lack of smoothness in the scrolling, and I'm not sure the cause, but I think it could be that my main loop is taking longer than one frame to execute at times, so you can understand why I'd be concerned about the waiting time for the sprite 0 hit.

So, what's the solution? There's a throwaway line in the NesDev wiki article about using an IRQ to track your scanline (I guess if you're using a mapper that does that). I know that an IRQ is a type of interrupt, but I'm not really familiar with what exactly it is or what causes it, or how you would go about setting it up. But in my head I'm imagining:

1. Interrupt when your status bar is completely drawn.
2. Interrupt handler changes the PPU scroll value.
3. Return to main loop.

Is that a good way to do it? How would you go about it? Am I worrying too much about the time for the sprite 0 hit? Is there a way to track the execution time of your main logic? Is there some other solution I'm not thinking of? Sorry I couldn't boil this down to a single question, but if someone can give some advice or direct me to some post or tutorial that would be great. Thanks in advance for your help!


Top
 Profile  
 
PostPosted: Sat Jul 22, 2017 11:27 am 
Offline

Joined: Sun Jun 25, 2017 3:32 pm
Posts: 10
Just as an update to my questions: I found a thread (on the front page even, but it looks like an old thread that was dug up pretty recently) that talks about setting the monochrome bit on the PPU to determine approximately how long your code is taking to execute. I set my program to toggle that bit at the end of the main loop execution and it looks like my code is taking about a third of the frame to execute, max (most of the time it's like a tenth, but if the main character is moving, jumping, and colliding with an object all at once it takes longer). So maybe my concern about waiting for sprite 0 isn't warranted yet. I'm still curious though, if anyone wants to share.


Top
 Profile  
 
PostPosted: Sat Jul 22, 2017 11:51 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10052
Location: Rio de Janeiro - Brazil
Many emulators have problems with refresh rate synchronization, so that may be the reason the scroll doesn't look as smooth as you expected.

Anyway, if you plan on using IRQs for other effects and also taking advantage of other features of a more complex/expensive mapper such as the MMC3, then yeah, switching your project to such a mapper might be a good idea. If all you need is a status bar though, mapper IRQs sound like overkill to me.

It's true that waiting for a sprite 0 hit wastes CPU time, but it's not like you can't do *anything* while you wait for the hit... You can do a lot of useful things, like running the sound engine, clearing buffers, reading the controllers... As long as you know for sure that the time taken by these tasks won't be longer than the time before the hit.


Top
 Profile  
 
PostPosted: Sat Jul 22, 2017 2:36 pm 
Offline

Joined: Sun Jun 25, 2017 3:32 pm
Posts: 10
Thanks for your reply. I think I get what you're saying as far as other tasks, I'm already doing a few things at the bottom of my NMI handler after I do everything that needs to be done during vblank. Basically anything that happens between vblank and the sprite 0 hit would be using some of that time, yes?

Right now I'm not doing any music code (because I haven't implemented any sound yet), and I'm reading the controllers at the beginning of the main loop, so maybe I can move that to the NMI handler and gain some efficiency. But I'm clearing the buffers...and I just looked and that's really all I'm doing, so maybe there are other tasks I can move as well.


Top
 Profile  
 
PostPosted: Sat Jul 22, 2017 6:53 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
If you do read input in the NMI handler, do so only when the main loop requests reading input, such as if it has finalized update packets to send to OAM and VRAM. Otherwise, if you have a lag frame, it may miss presses when the "button was just pressed" bit maintained by your input code turns on and off before the game logic can see it.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Lucradan and 6 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