It is currently Mon Dec 18, 2017 7:56 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: More VBlank time
PostPosted: Sun Apr 30, 2006 11:58 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10173
Location: Rio de Janeiro - Brazil
I'm thinking about the best way to reduce the number of displayed scanlines to get a little more Vblank time.

I'm on a mapper with no IRQ's, meaning it is hard to turn the screen off early, as I'd have to force a sprite 0 hit (draw garbage on the background) and make sure the game logic does not go beyond the hit point or it'd be all screwed up.

Maybe I could turn the screen on a few scanlines late... but I remembered of an issue with the scanline that is 1 cycle shorter, that it isn't shorter when the screen is off, isn't it? Would that cause any problems?

I just want some new perspective on this. Thanks for the help.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 30, 2006 12:26 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7320
Location: Chexbres, VD, Switzerland
The NTSC version of Battletoads turn the screen on late, so this is possible to manage.
However, I'd prefer do it the other way arround myself, turning the screen off early. It is easier to have a sprite zero hit detect and turn the screen off after it than monkey with timed VBlank code.
Of course, you'll have to be sure that the programm that writes to the PPU on the bottom of the screen doesn't make too long and be overlapped by the VBlank NMI, nor having the main programm that takes too long to perform its frame calculation and miss the sprite zero hit, causing the game to slow down and the bottom of the screen flicker in the best case.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 30, 2006 1:16 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
Of course, you'll have to be sure that the programm that writes to the PPU on the bottom of the screen doesn't make too long and be overlapped by the VBlank NMI,


Eh? If you were turning off rendering early each frame, you wouldn't be using NMI at all. You could also use the sprite overflow flag ($2002 bit 5) and even set up a DMC interrupt to occur a few scanlines before it, eliminating the problem of the main code taking too long (if it took too long, the game would just slow down rather than have any graphical glitches).


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 30, 2006 6:51 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10173
Location: Rio de Janeiro - Brazil
Bregalad wrote:
The NTSC version of Battletoads turn the screen on late, so this is possible to manage.

Yeah, I thought so too, I was just wondering what kind of difference would it make if that one scanline never happend to be 1 cycle short. I mean, that must happen for a reason...

Quote:
However, I'd prefer do it the other way arround myself, turning the screen off early.

That's my first option too. A blank bar at the bottom of the screen is less strange than one at the top.

Quote:
It is easier to have a sprite zero hit detect and turn the screen off after it than monkey with timed VBlank code.

It does get a bit annoying when you scroll vertically too, since you have to place a solid (non color 0) tile by the corner to force a hit, and that tile may look like a visual glitch.

Quote:
Of course, you'll have to be sure that the programm that writes to the PPU on the bottom of the screen doesn't make too long and be overlapped by the VBlank NMI, nor having the main programm that takes too long to perform its frame calculation and miss the sprite zero hit, causing the game to slow down and the bottom of the screen flicker in the best case.


blargg wrote:
Eh? If you were turning off rendering early each frame, you wouldn't be using NMI at all.

That's what I was going to say. Once you turned rendering off after the hit, you're already inside your forced VBlank, se there is no need to expect the NMI. Unless you wanted to use it to time something... But even then you could wait for the hit flag to clear as a timing point, right?

Quote:
You could also use the sprite overflow flag ($2002 bit 5)

I still don't understand the logic behind that flag. And as far as I know, it could accidently go off early, depending on what the sprites are doing.

Quote:
and even set up a DMC interrupt to occur a few scanlines before it

Unfortunately I don't know anything about sound programming yet, but I heard that getting the time right with DMC IRQ's is pretty hard. Although this would be a combination of DMC IRQ and sprite 0 hit, so the timing wouldn't need to be so precise. I think I heard that to use DMC IRQ's you'd need large ammounts of data... is that right?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Apr 30, 2006 8:23 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
Yeah, I thought so too, I was just wondering what kind of difference would it make if that one scanline never happend to be 1 cycle short. I mean, that must happen for a reason...


It makes the color burst artifacts toggle between two appearances rather than three. The latest Nestopia with the NTSC filter enabled emulates this if you have your monitor set to 60 Hz and field merging off. Compare Battletoads during game play (not the cutscenes) with another game. You should see a faint pattern moving up the screen in Battletoads.

Quote:
I still don't understand the logic behind that flag [sprite overflow]. And as far as I know, it could accidently go off early, depending on what the sprites are doing.


Sorry, I wasn't thinking of having any other sprites on screen. Yes, it'd be unreliable for end-of-screen events. Sprite #0 hit would be necessary.

Quote:
I heard that getting the time right with DMC IRQ's is pretty hard. Although this would be a combination of DMC IRQ and sprite 0 hit, so the timing wouldn't need to be so precise.


You have the right idea. The DMC IRQ occurs at approximately the right place (and always a few scanlines early), then you constantly poll $2002 until the sprite #0 hit flag is raised.

Quote:
I think I heard that to use DMC IRQ's you'd need large ammounts of data... is that right?


In the NES book viewers discussed recently, I only needed a 17-byte DMC sample (of all zero to make it silent), which I restarted at NMI every frame. Once the last byte is read, the IRQ occurs. Adjusting the DMC timing is a matter of setting the DMC pitch in $4010. To calibrate it you just have it enable something like color emphasis so you can see where it's occurring on scren, then try each pitch. I'll post some code if you want to try this.


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: No registered users and 7 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