Why does Super Mario Bros 3 have background scrolling artifacts on the right side of the screen* when Super Mario Bros 1 and 2 don't?
*I remember finding an explanation for the artifacts, but I can't remember where it was.
Smb3 uses horizontal mirroring (vertical arrangement of nametables) so it can update the entire vertical area as it scrolls.
The NES can only have an offscreen buffer to update tiles/attribute bytes(These control the palette the background tiles use) on one axis. (The programmer chooses which axis)
Super Mario Bros. only scrolls on one axis, so it can update the attributes before they're on screen. Super Mario Bros. 2 only scrolls on one axis at a time (if I recall correctly), so it can always update the attributes before they're on screen. Same with Metroid.
But Super Mario Bros. 3 is capable of scrolling on both axises in the same frame. It is set up to have its offscreen buffer for vertical scrolling, but not horizontal scrolling. That is why the player can see the palette changing by the right edge of the screen.
Like the others said, it's because of the type of scrolling it uses. Since the NES only gives you 2 screens (name tables) to work with, you can organize them either vertically or horizontally (by selecting horizontal or vertical mirroring), so you only get a hidden area where you can perform screen updates seamlessly in one axis.
For games that only scroll in one direction this is not a problem, but once you scroll in both you have to pick a place for the scrolling artifacts. There are ways to get rid of those artifacts, of course, but the programmers of SMB3 probably didn't think that was important.
Quote:
For games that only scroll in one direction this is not a problem, but once you scroll in both you have to pick a place for the scrolling artifacts. There are ways to get rid of those artifacts, of course, but the programmers of SMB3 probably didn't think that was important.
There is no way to COMPLETELY get rid of them, but there is a way to come pretty close. However Nintendo really went pretty lame with SMB3 because there is up to 10+ garbage pixels on the right, while it's possible to have only at max 3 on the left and 4 on the right (never simultaneously) which is much less noticeable such as seen here.
I show hot it *could* have looked if Nintendo's programmers were better in this totally shitty unfinished scrolling demo
here.
Also SMB3's border looks bad because of the light blue (or wathever other) color bands vertically, especially on NTSC where the horizontally "underscan" area is filled with the BG color.
Bregalad wrote:
I show hot it *could* have looked if Nintendo's programmers were better in this totally shitty unfinished scrolling demo
here.
But it only scrolls horizontally? The reason there's artifacts if because the way they stacked the screen. This isn't stacked and doesn't scroll up. Although I have a feeling that's why it's unfinished....cool demo though.
Bregalad wrote:
There is no way to COMPLETELY get rid of them
Isn't the additional nametable RAM to have four nametables is the way?
Shiru wrote:
Bregalad wrote:
There is no way to COMPLETELY get rid of them
Isn't the additional nametable RAM to have four nametables is the way?
And the A/B/B/A diagonal mirroring would get off of lots of NTSC systems, although they'd exist on pal. But only on the corners.
Bregalad wrote:
There is no way to COMPLETELY get rid of them
Of course there is, four-screen mirroring being the most obvious way. But even if you're stuck with only 2 name tables, there are a few techniques to completely blank the otherwise glitched areas. Since it uses an MMC3, SMB3 could very well have used interrupts to hide the top and bottom 8 scanlines, and vertical mirroring instead of horizontal (exactly like Jurassic Park does).
You guys are right there is a lot of ways to completely get rid of them but they aren't "convenient".
1) 4-screen VRAM (really a waste if hiding the artifacts is the ONLY think that made you use additional VRAM)
2) Using a vertical bar of solid black sprites (then you're stuck with only 7 sprites per line for gameplay...)
3) Using raster split to use a completely blank CHR-bank (needs timed code or IRQs + a blank CHR-blank)
etc...
Also Jurassic Park does not have a status bar so that method wouldn't work for SMB3. It would have to use the complex method used in Krusty's Fun House.
Quote:
But it only scrolls horizontally? The reason there's artifacts if because the way they stacked the screen. This isn't stacked and doesn't scroll up. Although I have a feeling that's why it's unfinished....
You bet it. I was going to du a multi-directional scroll demo with a single screen of VRAM used. Not sure if I'll finish it someday but multi-directional scroll is really evil to get working.
I actually always thought it was somewhat lazy of SMB3 to have tile glitches. You can see actual tiles that are not updated at the right for a pixel or two, but there's no reason for that when you're hiding the left eight pixels. That stuff can be completely hidden.
Bregalad wrote:
Not sure if I'll finish it someday but multi-directional scroll is really evil to get working.
I'm more curious to know how the attribute glitches seem to only show a max of 3ish wrong colored pixels instead of a max of 8 at the right.
I've got multidirection scrolling working, and have had it working forever, but I still have a max of 8 pixels at the trailing edge of the screen.
Edit: OOooh. Clever little trick. I just read more into your posts. So it shows wrong colors attributes on BOTH sides, so there are less of them. I may think about doing that, but I think I prefer to just keep it all at the trailing edge of the screen Kirby style.
Then again... the demo shows that it seems pretty rare that BOTH sides of the screen will have glitches at the same time. And considering I didn't even notice it was doing stuff on the left until I really checked... hmmm...
Kasumi wrote:
I actually always thought it was somewhat lazy of SMB3 to have tile glitches. You can see actual tiles that are not updated at the right for a pixel or two, but there's no reason for that when you're hiding the left eight pixels. That stuff can be completely hidden.
easy to say that 25 years later
they were probably happy with 4 way scrolling at that time
and it certainly doesnt seem to have hurt game sales much
This scrolling artifact, along with other artifacts such as the shadows behind blocks, lead me to believe that SMB3 for NES was an amateur retelling of SMB3 for Super NES. See
explanation at TV Tropes.
But in a way, keeping attribute artifacts at the right side might be the best policy because the right side is more likely to be within overscan.
tepples wrote:
the right side is more likely to be within overscan.
Really? My TVs all gave me the exact opposite impression.
I believe that with the knowledge and tools we have today we have little excuse to program free scrolling engines with visual glitches, so I do everything I can to avoid those on the software level.
EDIT:
tepples wrote:
BTW, I didn't find this funny at all...
tokumaru wrote:
BTW, I didn't find this funny at all...
yeah.. doesnt help the image references is a dead link too :-p
I honestly hate horizontal mirroring... I think since our eyes are side by side, we have a more panoramic vision, and thus notice the glitches on the left and right edges of the screen more so than we would on the top and bottom. Also, I seem to remember talking about this a year or so ago, and I think Bregalad made a note that glitches are more noticeable if they occur in the direction you are scrolling. This is a good point too.
I hardly ever see vertical glitches; maybe it's just my TV. Like others said, they're also easier to mask by blanking out scanlines.
Vertical mirroring is probably ideal if your status bar is sprite-based. But if your status bar is background, you'll probably need to use a mapper IRQ to skip the rows of the map dedicated to the status bar.
tepples wrote:
Vertical mirroring is probably ideal if your status bar is sprite-based. But if your status bar is background, you'll probably need to use a mapper IRQ to skip the rows of the map dedicated to the status bar.
If you want free scrolling and a background status bar, the easiest solution is single-screen mirroring, but that comes with color artifacts on the sides, like in SMB3.
An option I have considered but never actually used because I never had the need for a background status bar is to draw the status bar every frame in a safe place. Sounds a little extreme, but with highly optimized/unrolled code it should be possible to draw it in 8 scanlines or so... That would be done during the visible frame, so it wouldn't steal any VBlank time. One day I might try this.
tokumaru wrote:
An option I have considered but never actually used because I never had the need for a background status bar is to draw the status bar every frame in a safe place. Sounds a little extreme, but with highly optimized/unrolled code it should be possible to draw it in 8 scanlines or so... That would be done during the visible frame, so it wouldn't steal any VBlank time. One day I might try this.
Interesting idea.
Could be used with mappers like UNROM to get multidirectional scrolling and a background based status bar on top. Wouldn't even waste cycles for the status bar area if some static timed task could be run there... I might give this a try.
thefox wrote:
Could be used with mappers like UNROM to get multidirectional scrolling and a background based status bar on top. Wouldn't even waste cycles for the status bar area if some static timed task could be run there... I might give this a try.
I imagined using the first few scanlines of the frame to draw the status bar (since those scanlines are outside the safe area you wouldn't want any information there anyway) and then a sprite hit would indicate the end of the status bar. At that point you might need to blank a few more scanlines, in order to avoid vertical scrolling glitches. Please let us know if you code something like this!
tokumaru wrote:
thefox wrote:
Could be used with mappers like UNROM to get multidirectional scrolling and a background based status bar on top. Wouldn't even waste cycles for the status bar area if some static timed task could be run there... I might give this a try.
I imagined using the first few scanlines of the frame to draw the status bar (since those scanlines are outside the safe area you wouldn't want any information there anyway) and then a sprite hit would indicate the end of the status bar. At that point you might need to blank a few more scanlines, in order to avoid vertical scrolling glitches. Please let us know if you code something like this!
True, I forgot about sprite 0 hit (although the polling would still waste some cycles, but at least it'd allow running some variable timed task during the status bar as long as its worst case run time is known). I'll keep you posted.
Quote:
I honestly hate horizontal mirroring... I think since our eyes are side by side, we have a more panoramic vision, and thus notice the glitches on the left and right edges of the screen more so than we would on the top and bottom.
I understand your point, and that's your opinion.
However have you checked my unfinished demo against the real SMB3 ? You'd notice the attribute glitches are MUCH less noticeable in my demo in fact if you didn't KNOW they were there you are likely not to ever notice them. Even more so on PAL hardware where 2 pixels aren't rendered on the right edge (and on the left too but it's hidden by $2001 masking anyways).
Quote:
I hardly ever see vertical glitches; maybe it's just my TV. Like others said, they're also easier to mask by blanking out scanlines.
You should play Final Fantasy in Nintendulator and you'll definitely have a hard time NOT so see them.
By the way it's good to see you're back.
Bregalad wrote:
Celius wrote:
I hardly ever see vertical glitches; maybe it's just my TV. Like others said, they're also easier to mask by blanking out scanlines.
You should play Final Fantasy in Nintendulator
Nintendulator doesn't emulate NTSC overscan. It shows the entire picture that the emulated RGB PPU generates.
I've found another technique to make mirroring glitches harder to see: draw blank tiles in the row of tiles that crosses the seam. A blank tile never has the wrong attribute. I use this for the scrolling text in Concentration Room and my multicart engine.
tepples wrote:
Nintendulator doesn't emulate NTSC overscan. It shows the entire picture that the emulated RGB PPU generates.
Absolutely, that's exactly why I was saying that. Sorry I forgot to mention it at first
Quote:
I've found another technique to make mirroring glitches harder to see: draw blank tiles in the row of tiles that crosses the seam. A blank tile never has the wrong attribute. I use this for the scrolling text in Concentration Room and my multicart engine.
This is an interesting technique. It will probably work wonders for scrolling text (hem hem... such as the Power Pak Menu which currently looks terrible on my PAL NES). However for a scrolling level it might be just as noticeable if tiles "pops" in and out when scrolling. If would work fine in a game with overall dark graphics, but not so good with a game with overall bright graphics.
Also it would add unnecessary tile updates for scrolling.
That being said I'd still consider doing this as it's better than showing the wrong tiles.
I just happened to be watching the ending to Bubble Bobble 2 when I noticed it has the same artifacts, but vertically.
http://www.youtube.com/watch?v=FOMg5kL1Dxg&feature=related
Happens about half way through the video, when scrolls upward.
You shouldn't be surprised, a lot of NES games suffer from that. I'd guess that 98% of the games with 8-way scrolling have glitches either vertically or horizontally, and a good portion of the games that scroll in only one axis have them too, without any good excuse.
Many of the Mega Man games for example have scrolling glitches, even though they only scroll in one axis at a time. There's no (real) excuse for that, since they use a mapper with mirroring control. I believe that the reason they simulate 1-screen mirroring is to always have one free name table for the in-game menus. With just a little extra work (i.e. allowing the menu to be split across both name tables or even re-rendering the whole background when leaving the menu) they could have avoided the glitches.
Mega Man 1 used UNROM which has not mirroring control. On the vertical scrolls you will see some glitching at the bottom. I honestly think they just reused that same engine for at least the next game and did not mess with the scrolling.
Maybe someone more familiar with the code of the Mega Man series can comment.
qbradq wrote:
Mega Man 1 used UNROM which has not mirroring control.
Yeah, I know. It doesn't have glitches when scrolling horizontally though, which the later games have. I was mainly talking about them, the MMC3 ones.
Ah, OK. I have really only played Mega Man 2 extensively, so I was confused
Some TVs cut off a lot of vertical space, horizontal too but not to such a degree. For example, the TV a friend and I played NES on all the time, didn't have a problem with it until we tried Legacy of the Wizard and you couldn't really see where the ladders are on the bottom of the screen (maybe only 1 or 2 rows of pixels visible).
Same goes for the top 8 scanlines, you can see it an every emulator pretty much, but on any TV that I've seen, it's not visible at all. Maybe that's why it's so obvious in that Bubble Bobble 2 video.
I noticed that FCEUX 2.something seems to cut off the top eight pixels. I have to constantly remind myself about the overscan areas when developing with Nintendulator
By default, FCEUX displays lines 8 to 231. This can be changed in the GUI (Windows) or at the command line (others).
As a godlen rule you should avoid putting important information in the first 12 lines and the last 12 lines. It's also best to avoid putting some really ugly glitches there.
Most emus cut 8/8 but I've heard actual TVs might cut even more, while PAL TVs will definitely cut nothing !
For left/right, it's pretty much the same, you should avoid putting important information in the left/right 8 pixels or so as they might be invisible. The left/right 2 pixels will always be cut of on PAL TVs too (they aren't even rendered).
I always configure all emulators to show all scanlines.
What I meant is, for development purposes, you should ideally make the game looks "allright" both with all scanlines visible, and with all the scanlines that could be cropped, not visible.
In other words if you always have all scanlines visible like toku, you could end up putting important information in the edges by forgetting this could be hidded.
If you always have all borders masked, you would end up with sprites popping (which is in fact inevitable) and BG scrolling glitches.
Bregalad wrote:
In other words if you always have all scanlines visible like toku, you could end up putting important information in the edges by forgetting this could be hidded.
Note to self: add an option to an emulator to render the safe area markers on top of the emulated image (FCEUX can already do this with LUA..).
Bregalad wrote:
What I meant is, for development purposes, you should ideally make the game looks "allright" both with all scanlines visible, and with all the scanlines that could be cropped, not visible.
Ah, sure. I was just saying I don't like programs hiding things from me (the very first thing I do after installing Windows is configure it to display file extensions, hidden folders/files and system folders/files), so I configure my emulators to show all scanlines. But of course, I avoid placing important info too close to the edges.
Quote:
If you always have all borders masked, you would end up with sprites popping (which is in fact inevitable)
They're not really inevitable... If you mask the top of the screen to hide scrolling glitches, and mask the left of the screen using the built-in PPU feature, you can have sprites enter/leave the screen smoothly in any direction.
In my game I do mask the top of the screen, but not the left. Having that area blanked (and reducing the horizontal resolution from a nice 256 pixels to an odd 248) bothers me more than sprites popping! =)
Oh you're right it's not inevitable, but you see what I mean... If you use a game with a simple mapper and don't want to have headaches, you're not going to avoid that.
In fact there is 3 ways this can be avoided :
- Waste one CHR-ROM bank, make it all blank and use it on all banks to hide the top 8 scanlines. Of course if you use CNROM you won't be wasting 8KB of your 32kb CHR just for that
- Do it the Battletoads way, but restrict the forced blanking area to 8 scanlines. However I'm not a huge fan of this method for some reason, I just don't like forced blanking being used other than during game transitions.
- Disable BG but not sprites via $2001, and use 8 blank high-priority sprites to hide sprites. This is the most economical way as it only waste 1 tile and 8 sprites
Anyways all 3 ways requires timed code, and you're likely to have to deal with the constant VBlank timing stuff if you want them, which is really not my cup of tea.
Bregalad wrote:
Of course if you use CNROM you won't be wasting 8KB of your 32kb CHR just for that
True... But with CNROM you can actually get away with 4KB of blank tiles if you make sprites and background use tiles from the same pattern table. Even if you use 8x16 sprites from both pattern tables you can temporarily set them to 8x8 to force them to fetch patterns from the blank pattern table, and after the masked area you can set them back to 8x16. 4KB of CHR-ROM is still a lot of what's available in CNROM, but it's a lot better than 8KB.
Well you are right that 4KB wouldn't be nearly as bad.
Anyway I don't see any reason to do this over the third method I mentioned.
Unless you absolutely need all 64 sprites to be displayed and can't allow to be restricted to only 56. Or if you use 8x16 sprites (I never do) and don't want to hide lines 8-15.
tokumaru wrote:
I imagined using the first few scanlines of the frame to draw the status bar (since those scanlines are outside the safe area you wouldn't want any information there anyway) and then a sprite hit would indicate the end of the status bar. At that point you might need to blank a few more scanlines, in order to avoid vertical scrolling glitches. Please let us know if you code something like this!
I did a little proof of concept about this as well:
http://kkfos.aspekt.fi/downloads/status-bar.zip. The ROM is set to FME-7 but doesn't use IRQs or anything. It uses vertical mirroring. Still needs some tweaking to make it look better (and to actually have something in the status bar instead of blank tiles) but anyway I think it's a really nice little technique. It's great to be able to have glitch free multiway scrolling + status bar on simple configs such as UxROM!
Pretty cool. I guess this is a perfectly valid way to have a status bar and free scrolling. And in the process you even get rid of scrolling artifacts.
thefox wrote:
I did a little proof of concept about this as well:
http://kkfos.aspekt.fi/downloads/status-bar.zip. The ROM is set to FME-7 but doesn't use IRQs or anything. It uses vertical mirroring. Still needs some tweaking to make it look better (and to actually have something in the status bar instead of blank tiles) but anyway I think it's a really nice little technique. It's great to be able to have glitch free multiway scrolling + status bar on simple configs such as UxROM!
I don't think your proof of concept proofs anything... It's likely way too much work to update the whole status bar every time your cross a tile horizontally (potentially every frame).
You'd say that if the status bar is small enough and if you blank extra lines this might become possible but then why not do it like Jungle Book instead, which seems more clever.
Bregalad wrote:
I don't think your proof of concept proofs anything... It's likely way too much work to update the whole status bar every time your cross a tile horizontally (potentially every frame).
You'd say that if the status bar is small enough and if you blank extra lines this might become possible but then why not do it like Jungle Book instead, which seems more clever.
The code already handles nametable crossing. I also made it better today so that it actually displays something meaningless (altho I forgot to update the attributes, so I need to find CPU time to write 8 more bytes). The extra blanking is not a problem for me.
How does Jungle Book do it? I can't make sense out of it because it sets the palette to black in the bottom of the screen so the nametable viewers of emulators are almost useless. It seems to keep the status bar always in the first nametable but I don't understand how that can work with vertical mirroring...
EDIT: Ah, I think I got it (when I was trying to figure it out on paper I was wrongly thinking that the visible (playfield) area is 256x240). So you're right, moving the status bar vertically is better (CPU usage wise) than moving it horizontally, which I was doing in my example. For what it's worth, here's my latest attempt:
http://kkfos.aspekt.fi/downloads/status-bar2.zip. It displays some actual text, but doesn't update attributes yet. (FYI the player character starts behind the status bar.)
thefox wrote:
How does Jungle Book do it?
From what I can see, it's the same basic idea, but instead of redrawing the entire thing every frame it progressively draws stacked copies of the status bar as the vertical scroll changes. That way, even if he playfield overwrites one of the copies, at least one copy will be usable at any given time.
The advantage is that it requires less VRAM updates, at the expense of a significant area of the status bar, since the area that would normally be occupied by one has to be used for two, so it can't be as tall.
Quote:
So you're right, moving the status bar vertically is better (CPU usage wise) than moving it horizontally, which I was doing in my example.
I came to the same conclusion after seeing your first demo. The main advantage is that you have to set the VRAM address fewer times.
Quote:
For what it's worth, here's my latest attempt:
Looks great.
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.
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.
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.
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.
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"
I traced through this in Nintendulator's debugger. The NMI handler appears to do the following:
- Set the background color to black.
- DMA-copy the display list to OAM.
- 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).
- 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.
- Set the scroll position to the top of the status bar.
- Wait for the bottom of the status bar. The demo uses timed code, but something else could use sprite 0.
- 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.
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:
- 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...
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.
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.
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.
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?
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?