It is currently Tue Oct 16, 2018 7:44 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 57 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
 Post subject:
PostPosted: Thu Jul 07, 2011 8:12 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3132
Location: Tampere, Finland
For completeness sake here's a 3rd version that moves the status bar vertically (still no attributes, though): http://kkfos.aspekt.fi/downloads/status-bar3.zip

1) It was much easier to implement than horizontal movement.
2) It's about twice as fast to upload (taking ~9 scanlines), and can still be optimized a little bit (by doing LDA, STA, STA, STA etc for the empty areas -- currently it just copies 128 bytes from RAM).
3) When doing it horizontally, I needed to place sprites on the right side of the status bar to hide glitches from the map (since the active area of the map is 256+16 pixels, so we only have 240 pixels horizontally for the status bar). Those sprites are not wasted when moving vertically, which is nice.

As for Jungle Book, I think the "stacking" is just a side effect of the method, and doesn't have any purpose per se.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 08, 2011 10:37 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10893
Location: Rio de Janeiro - Brazil
thefox wrote:
As for Jungle Book, I think the "stacking" is just a side effect of the method, and doesn't have any purpose per se.

It has a purpose. If there was no stacking, when the gameplay started overwriting the current status bar you wouldn't have a full status bar to show unless a whole new one was drawn (like in your demos). Using the "stacked" method, the game progressively prepares the next status bar that will be shown once the current one starts to be overwritten.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 08, 2011 3:22 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3132
Location: Tampere, Finland
tokumaru wrote:
thefox wrote:
As for Jungle Book, I think the "stacking" is just a side effect of the method, and doesn't have any purpose per se.

It has a purpose. If there was no stacking, when the gameplay started overwriting the current status bar you wouldn't have a full status bar to show unless a whole new one was drawn (like in your demos). Using the "stacked" method, the game progressively prepares the next status bar that will be shown once the current one starts to be overwritten.

OK, I'll take your word for it.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 08, 2011 6:23 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10893
Location: Rio de Janeiro - Brazil
I don't want you to take my word, I want you to understand how it works and agree with me based on logic! =)

Even though I suck at explaining things, I would like to eventually compile a "guide" with tricks such as this.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 08, 2011 6:46 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3132
Location: Tampere, Finland
tokumaru wrote:
I don't want you to take my word, I want you to understand how it works and agree with me based on logic! =)

Even though I suck at explaining things, I would like to eventually compile a "guide" with tricks such as this.

What I meant was I understand the logic, but I couldn't bother to verify it by tracing Jungle Book. :)

E: In other words: "I'll take your word that it's done like this Jungle Book"


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 08, 2011 8:37 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20660
Location: NE Indiana, USA (NTSC)
I traced through this in Nintendulator's debugger. The NMI handler appears to do the following:
  1. Set the background color to black.
  2. DMA-copy the display list to OAM.
  3. Wait for the end of vertical blanking. The demo uses timed code, but something else could use the sprite 0 hit flag (which turns off during the pre-render line).
  4. With the screen still force-blanked, copy the status bar into VRAM just below the seam with an unrolled loop. This could be fully unrolled as in the demo or partially unrolled as in something else. You have about 16 lines to finish this.
  5. Set the scroll position to the top of the status bar.
  6. Wait for the bottom of the status bar. The demo uses timed code, but something else could use sprite 0.
  7. Change the background color and scroll position to the playfield.

The demo is structured to run entirely in NMI (a so-called "superloop" like SMB1). This has the advantage of reducing NMI timing jitter from 7 to 3 cycles. The occasional writes to $4040 must be some debug timer on a mapper, I guess.

Because the status bar is updated every frame, the nametable data must always be stored literally in RAM, unlike the traditional solution where it can get constructed dynamically and use one of the transfer slots.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 08, 2011 9:35 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3132
Location: Tampere, Finland
tepples wrote:
I traced through this in Nintendulator's debugger.

Why? ;) Anyways, you got it mostly right.

Quote:
The NMI handler appears to do the following:
  1. Wait for the end of vertical blanking. The demo uses timed code, but something else could use the sprite 0 hit flag (which turns off during the pre-render line).

It doesn't wait for the end of vblank exactly but a little longer (it needs forced vblank for the worst case of scenario of map updates, so the routine was written to take constant time, so that it's possible to enable rendering at a known position.

Quote:
Because the status bar is updated every frame, the nametable data must always be stored literally in RAM, unlike the traditional solution where it can get constructed dynamically and use one of the transfer slots.

Currently it hogs 128 bytes of RAM needlessly, in reality the static parts of the status bar wouldn't have to be stored there (could be changed to lda #imm sta $2007 in the unrolled loop).

And yes, $4040 writes are leftovers from NintendulatorDX debug timers...


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 09, 2011 9:50 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7546
Location: Chexbres, VD, Switzerland
I guess what Jungle Book does is much closer to the "traditional" solution where the status bar is uploaded dynamically.
I'm not sure how it does "stacking", but as new information can be written to the status bar basically anytime, it has to either :
- Write a whole status bar when it's needed (takes most non-extended VBlank time typically, I did it that way in my game)
- Do it as tokumaru mentions, one line at a time, but then if new information is updated it has to be updated in both copies of the status bar. Probably a little more complex to code but saves some potentially precious VBlank time.

The stacking technique is nothing new, variants of it are used in all 3 Double Dragon games, Raida Senki, Conquest of the Crystal Palace, Gradius II, Parodius, etc...

What is so special about Jungle Book is that it does it with vertical mirroring, while all the games I mentioned do it with horizontal mirroring. This is possible because the status bar is small, and a significant area is unused/forced blanked (I guess via blank character banks but could also be done with $2001) on the top and bottom on the screen. That was it's possible to have all displayed tiles + 2 times the status bar total to 30 tiles.

For example if the status bar is 4 tiles, there remains exactly 22 tiles for display, but because you don't want artifacts that makes 21 actually usable tiles. So for a reult this allows you to disaply 21 playfield tiles, 4 status bar tiles, and you have to force-blank 5 tiles on the top and bottom (including both ovescan ones), which is significant but reasonable.

If you wanted a larger status bar, for example 6 tiles, you'd have to reserve 12 tiles just for that in the nametable, so only 18 (in practice 17) tiles for display. With 17 tiles to show and 6 for the status bar, this makes 23 used tiles and you'd have to force-blank 7 tiles, which would be a really HUGE part of the screen, likely you'd give up this method and use another one which allows you not to waste so much playfield.

I find the first method used by thefox very interesting, because it's the first time I see it. I personally already have considered the theorcal possibility of it, but through it would never be feasible because of how much updates are needed.

Here the only reason parts of the screen are forced-blanked is to be able to do really heavy VRAM updates. I wonder if there would be a way to work arround this (and so make this method be better than the Jungle Book one) in some situations.
For example if the scrolling speeds are always low such as in a RPG, you could know exactly when the screen will cross a 8-pixel boundary and when the status bar will have to be entierely rewritten to VRAM.
If you do it in a nice unrolled loop, this could fit exactly the remaining VBlank time after Sprite-DMA, so that if no updates are ever needed on those particular frames, your game will work fine without having to use any type of forced blanking.
Basically it means you have to do the scrolling updates just one frame before you update the status bar but it sounds really feasible. In fact it's already what thefox's 2nd demo already does !

Eventually there is the technique used in "Krusty's Fun House" which should be considered as well... You have no need for extra blanking, no limit in scrolling speed nor status bar size, and can scroll without color artefacts... but you need TWO splitpoints per frame, one for the status bar and another variable one to handle "overflows" in the playfield (i.e. when the status bar is about to be displayed it forces it to show the next row of the playfield).
This method also only works for a constant sized status bar.

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 11, 2011 5:25 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10893
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Do it as tokumaru mentions, one line at a time, but then if new information is updated it has to be updated in both copies of the status bar.

You can get away with updating the new information only in the status bar that's being currently used. I haven't personally checked the game's code, but I imagine that it progressively draws rows with the static parts of the status bars but always updates the dynamic parts in the one that's currently being used.

Quote:
The stacking technique is nothing new, variants of it are used in all 3 Double Dragon games, Raida Senki, Conquest of the Crystal Palace, Gradius II, Parodius, etc..

If I'm not mistaken, the stacking is the exact same thing Kirby's Adventure does, except that it stacks the gameplay window, not the status bar. The idea is exactly the same though: if you have to copies, you can switch to the other one once a clash is about to happen.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jul 19, 2011 8:09 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7546
Location: Chexbres, VD, Switzerland
Quote:
If I'm not mistaken, the stacking is the exact same thing Kirby's Adventure does, except that it stacks the gameplay window, not the status bar. The idea is exactly the same though: if you have to copies, you can switch to the other one once a clash is about to happen.

Yes, this is basically the same. You have to "stack" two status bars OR two playfields, both can work well. And both have the inconvenient that you have to not only update not only the "active" playfield or bar, but also the "reserved" ones, so all changes must be done twice.

If you choose to stack the playfield, typically you see a part of the top one and a part of the bottom one at a time, but if you choose to stack the status bars, then you just see one of the status bars.

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


Top
 Profile  
 
PostPosted: Sat Jan 06, 2018 5:53 am 
Offline

Joined: Sat Jan 06, 2018 5:49 am
Posts: 1
Why didn't they just keep vertical mirroring the entire game? Vertical scroll is much less used than horizontal. Is it because of the HUD?


Top
 Profile  
 
PostPosted: Sat Jan 06, 2018 8:07 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1437
Switch_Z wrote:
Why didn't they just keep vertical mirroring the entire game? Vertical scroll is much less used than horizontal. Is it because of the HUD?


Because horizontally scrolling stages (which make up the vast majority of the game) are exactly 2 screens tall (minus the status bar), and that way they didn't have to do any VRAM updates during vertical scrolling.

Also, did you really need to resurrect a six year old thread to ask that question?

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


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

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