It is currently Mon Oct 23, 2017 3:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 41 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 12:22 am 
Offline
User avatar

Joined: Wed Jun 26, 2013 12:35 pm
Posts: 116
Location: Baltimore
I was thinking, to get some extra VBLANK I can disable the PPU at line 200 or whereabouts and effectively start an early VBLANK, right? What if I also want to start the next frame late like at line 16 or 32? Is that possible? I'm going for a letterbox effect.

_________________
sonder


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 1:06 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
Yes it's possible. However there is many disadvantages in doing so, but regardless, it's perfectly possible.

If you use a mapper that relies on a CPU cycle timer like Konami VRCs mapper, FME-7 or the Famicom Disk System it'll be relatively easy, otherwise it'll be a headache to get working.


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 1:12 am 
Offline
User avatar

Joined: Wed Jun 26, 2013 12:35 pm
Posts: 116
Location: Baltimore
It's NROM-256. Will it be too hard? :/ I'm prepared to do some trickery. Just nothing that prohibits doing other things... can you explain how you would do it? What are the disadvantages?

_________________
sonder


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 1:15 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
sonder wrote:
I was thinking, to get some extra VBLANK I can disable the PPU at line 200 or whereabouts and effectively start an early VBLANK, right?

Yes, but be careful when disabling rendering during an scanline that contains sprites, as that might result in corrupt sprites on the next frame. Apparently there's a certain window of time when it's safe to turn rendering off.

Quote:
What if I also want to start the next frame late like at line 16 or 32? Is that possible?

Yes, it's possible. But you have to find a way get the time exactly right every frame, or it will look "jumpy", and since rendering is off you can't use sprite 0 to help you with the timing... it will have to be pure cycle counting (or a mapper that does the cycle counting for you - scanline counters won't work, because they also need rendering to work). Also, if you make use of $2006/$2007 past the end of VBlank, you'll need to set the scroll with combined $2005/$2006 writes, instead of the usual $2005/$2000 writes.


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 1:24 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
sonder wrote:
It's NROM-256. Will it be too hard?

If you are not scrolling vertically, not so much, because you can use sprite 0 hits.

Quote:
can you explain how you would do it?

The simplest way to do it would be to set up a sprite 0 hit at the point where you want to turn rendering off. Once you do it, you are free to use the PPU as if VBlank had started. When you're done, wait for the sprite hit flag to clear - this will tell you when VBlank has ended, so you can start counting cycles in order to enable rendering at the correct point.

If you don't need to use $2006/$2007 after VBlank has ended, you can set the scroll normally before waiting for the frame to start, otherwise you will need to use the $2005/$2006 trick to set the scroll before enabling rendering.


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 7:34 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
tokumaru wrote:
Yes, but be careful when disabling rendering during an scanline that contains sprites, as that might result in corrupt sprites on the next frame. Apparently there's a certain window of time when it's safe to turn rendering off.


If you don't refresh the sprites the data may start to degrade, or even if you do an OAM DMA too early, but if you do the DMA after the true vblank begins you should be fine, AFAIK? Or is there another issue there besides the dynamic RAM problem?


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 8:36 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
The problem as I understand it is that the state of a pair of sprites is kept in the OAM refresh mechanism, and this state might be restored to the wrong sprites.


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 9:23 am 
Offline
User avatar

Joined: Wed Jun 26, 2013 12:35 pm
Posts: 116
Location: Baltimore
tokumaru wrote:
sonder wrote:
It's NROM-256. Will it be too hard?

If you are not scrolling vertically, not so much, because you can use sprite 0 hits.

The simplest way to do it would be to set up a sprite 0 hit at the point where you want to turn rendering off. Once you do it, you are free to use the PPU as if VBlank had started. When you're done, wait for the sprite hit flag to clear - this will tell you when VBlank has ended, so you can start counting cycles in order to enable rendering at the correct point.

If you don't need to use $2006/$2007 after VBlank has ended, you can set the scroll normally before waiting for the frame to start, otherwise you will need to use the $2005/$2006 trick to set the scroll before enabling rendering.


Well, we were going to use vertical scrolling, but we may use horizontal scrolling. I'm thinking we put black tiles at the bottom of the screen to help hide glitches since I read that Sprite 0 Hit is imprecise.

Sounds like the bottom black bar, aka early vblank, is the easy part. And honestly ~20 extra lines may be good enough. I think that rather than try to start rendering late, I'd use a split-screen technique - manipulate the scroll values to show the bottom black bar again. Perhaps we can show a black bar from the other nametable - and us it as a place to show text - though text is a thing we're thinking of abandoning since our CHR ROM is so precious (though I have a mind to beg mham to upgrade us to UxROM, but we're trying to see how far we can get with NROM)

_________________
sonder


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 11:37 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
sonder wrote:
Well, we were going to use vertical scrolling, but we may use horizontal scrolling.

What? Are you changing the design of your game? Anyway, you can still use vertical scrolling as long as you can guarantee that non-transparent pixels in sprite 0 will overlap non-transparent pixels in the background every frame. Sometimes vertical scrolling gets in the way of that, but not always. Depends on how you design your background.

Quote:
I'm thinking we put black tiles at the bottom of the screen to help hide glitches since I read that Sprite 0 Hit is imprecise.

You will definitely need a sprite 0 hit to put a black bar at the bottom of the screen, unless you are not scrolling vertically, in which case you can just put black tiles there. You will not be able to use that time for extra VRAM transfers, of course, since rendering will still be enabled.

Quote:
Sounds like the bottom black bar, aka early vblank, is the easy part.

Quite the opposite! Disabling rendering early can introduce the sprite glitches we talked about, and it's harder to synchronize with PPU after your game logic (needs sprite 0 hit or mapper IRQ). Blanking scanlines at the top of the screen is easier, because you have 2 possible sync points nearby (start and end of VBlank), so all you need is a bit of timed code to enable rendering at the correct scanline.

Quote:
I think that rather than try to start rendering late, I'd use a split-screen technique - manipulate the scroll values to show the bottom black bar again. Perhaps we can show a black bar from the other nametable

I think we need to know more about the type of scrolling you're using and why you need to display a letterboxed image in order to suggest the best approach.


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 11:50 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
Quote:
Anyway, you can still use vertical scrolling as long as you can guarantee that non-transparent pixels in sprite 0 will overlap non-transparent pixels in the background every frame.

Yes, but this has nothing to do with horizonal or vertical scrolling.

Quote:
Quite the opposite! Disabling rendering early can introduce the sprite glitches we talked about, and it's harder to synchronize with PPU after your game logic (needs sprite 0 hit or mapper IRQ). Blanking scanlines at the top of the screen is easier, because you have 2 possible sync points nearby (start and end of VBlank), so all you need is a bit of timed code to enable rendering at the correct scanline.

This, and I'd also say that extra VBlank is overrated in general. Not that it'd bad, but it's just not that good. Normal VBlank is enough for most applications, really. Unless you want to do something REALLY crazy like updating 20+ tiles every frame, there is no need for extra VBlank.


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 12:07 pm 
Offline
User avatar

Joined: Wed Jun 26, 2013 12:35 pm
Posts: 116
Location: Baltimore
No, not changing the design of the game... just how the map is broken up. We have decided to create a top-down adventure. We are bouncing lots of ideas around at the moment so really it's going to be somewhat of a compromise between design and technical power. We are working hard on the R&D side of things to push the conventional boundary of what the NES is thought of being capable of. Well, really, just me. I'm an obsessive perfectionist.

The main reason for wanting to have more VBLANK right now is this http://slack.net/~ant/misc/nes-saw/

I want to use this trick to add an extra voice during non-interactive moments. But we also want to do time-of-day palette updates. The combo makes me think that the CPU will be taxed because of the IRQ so having more time to update the palette will help avoid glitches. Alternatively I've been thinking about using the IRQ to do more frequent music updates (better time resolution so more freedom with tempo). Maybe one or the other depending on the context.

As for which mirroring mode we'll use ... right now I'm not sure but we know that the map will be divided into "rooms" much like Zelda (rooms is just a term ... it may be mainly an outdoor overworld.) I was going to use vertical scrolling to create "big" rooms but Mike brought up horizontal scrolling "corridors" (like Metroid or Goonies) and I might like that better, but we'd have to rework the map format (which is just in the sketching stage). Or we might have no scrolling at all. But I think that having some scrolling would add more impact.

_________________
sonder


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 12:43 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Yes, but this has nothing to do with horizonal or vertical scrolling.

Not directly, but since you need the hit to happen at the same scanline every frame, getting the scanline right is harder when the background is moving up and down (since the solid pixels you're supposed the hit against are moving away from the sprite). With horizontal scrolling it's much easier to provide a straight solid line.

Quote:
This, and I'd also say that extra VBlank is overrated in general. Not that it'd bad, but it's just not that good. Normal VBlank is enough for most applications, really.

Yeah, if you optimize the shit out of the code that writes data to VRAM you can do a lot in the standard 20 or so scanlines of VBlank. You can easily scroll in both directions at once while also updating the sprites and the palettes, which is enough for most games. What complicates things a bit are pattern animations... those can really eat a lot of your VBlank time, and is the only real excuse I can think of to need extra VBlank time.

sonder wrote:
But we also want to do time-of-day palette updates.

Palette updates are ridiculously quick if you pre-calculate all the data (as should be done with EVERY piece of data you write to VRAM). If you use code similar to this:

Code:
;set up the destination address (12 cycles)
lda #$3f
sta $2006
lda #$00
sta $2006

;prepare to reuse the background color (3 or 4 cycles)
ldx BackgroundColor

;write the first palette (25 or 28)
stx $2007
lda Palette0Color1
sta $2007
lda Palette0Color2
sta $2007
lda Palette0Color3
sta $2007

;now write the remaining 7 palettes in the same way...

It will take only 240 (colors loaded with absolute addressing) or 215 (colors loaded with ZP addressing) cycles to update all the colors... that's about 10% of the regular VBlank time, there's still enough time to update many other things. If your game is screen-by-screen, you definitely don't need any extra VBlank time unless you're animating several tiles in the pattern tables (which can't be the case since you're using CHR-ROM).

Quote:
Or we might have no scrolling at all. But I think that having some scrolling would add more impact.

No scrolling definitely helps with blanking portions of the screen. If you're only using scroll for "impact", quickly scrolling from one room to the next rather than smoothly following the player, I suggest you either drop the scrolling or do a very controlled/scripted one (like the vertical scroll in Mega Man 1, that does something purely visual before returning control to the horizontal scrolling engine) that won't get in the way of your letterboxing scheme.


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Sat Jul 27, 2013 12:58 pm 
Offline
User avatar

Joined: Wed Jun 26, 2013 12:35 pm
Posts: 116
Location: Baltimore
To save ROM space I may do a combination of tables and calculation. But if all tables / unrolled loops would take a mere 10% then maybe it won't be so necessary to get extra vblank. I just figure that having a smaller viewport for the playfield is a decent price to pay just to have a little more technical freedom, and it could as a side effect give the game a more cinematic feel. Where can I read about the topic of extending vblank in more detail?

_________________
sonder


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Tue Jul 30, 2013 11:26 am 
Offline
User avatar

Joined: Fri Mar 08, 2013 9:55 pm
Posts: 349
Location: Linköping, Sweden
As no one seemed to mention it: Battletoads does keep rendering disabled for 20 or so (iirc) scanlines into the frame, showing that some commercial games did it at least (maybe lots of games did, but I only know of that one). This is what makes it tricky to emulate, as the current screen position needs to be within a certain interval when rendering is turned on for a sprite zero hit to happen. If that sprite zero hit does not happen, the game freezes.

As others have said, you'd need to set up the scroll yourself via $2006 writes before you turn on rendering if you keep rendering disabled on the pre-render line. The reason is that the "vert(v) = vert(t)" (copy vertical scrolling bits from t to v) operation in http://wiki.nesdev.com/w/images/4/4f/Ppu.svg does not happen with rendering disabled. If you turn off rendering near the end of the frame instead and turn it on before the pre-render line, you would not need to use $2006 writes.


Top
 Profile  
 
 Post subject: Re: Getting extra VBLANK
PostPosted: Tue Jul 30, 2013 11:39 am 
Offline
User avatar

Joined: Wed Jun 26, 2013 12:35 pm
Posts: 116
Location: Baltimore
ulfalizer wrote:
As no one seemed to mention it: Battletoads does keep rendering disabled for 20 or so (iirc) scanlines into the frame, showing that some commercial games did it at least (maybe lots of games did, but I only know of that one). This is what makes it tricky to emulate, as the current screen position needs to be within a certain interval when rendering is turned on for a sprite zero hit to happen. If that sprite zero hit does not happen, the game freezes.

As others have said, you'd need to set up the scroll yourself via $2006 writes before you turn on rendering if you keep rendering disabled on the pre-render line. The reason is that the "vert(v) = vert(t)" (copy vertical scrolling bits from t to v) operation in http://wiki.nesdev.com/w/images/4/4f/Ppu.svg does not happen with rendering disabled. If you turn off rendering near the end of the frame instead and turn it on before the pre-render line, you would not need to use $2006 writes.


Thanks for adding your explanation ... though despite that I admit I'm still a bit lost.

How does the sprite 0 hit factor into this? It would have to be used strictly to disable rendering at the bottom of the frame, right? So no splitscreen without scanline hardware of some kind, or tricky-as-hell cycle counting, right?

How does Battletoads know when to re-enable rendering at the right scanline? Scanline hardware?

Everyone keeps mentioning $2006 writes for setting up the scroll. How does that work? But it only matters if rendering hasn't been enabled by the "first" scanline (the pre-render scanline as you referred to it). If it's not a big deal to do the scroll through $2006 then that's not a detractor.

I still don't have a clear idea of what it will take to accomplish this in say, an NROM game. People say cycle counting but it seems to me like I could easily disable rendering at line 200 on sprite 0 hit and just make sure to re-enable it after my vblank routine. Anyone please confirm if my thinking's right on this or not though.

_________________
sonder


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: lidnariq and 8 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