It is currently Tue Oct 17, 2017 12:01 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Jun 19, 2016 5:27 am 
Offline

Joined: Tue Sep 27, 2011 8:20 pm
Posts: 23
Hey guys,

I'm continuing my quest to gain more knowledge about scrolling and the associated techniques.

This time, I'm looking at various techniques I can use to mask the transition between vertical mirroring and horizontal mirroring. In games like Metroid and Mega Man, doors and ladders add a nice aesthetic to the game, but of course as developers, we know that they also mask the transition between scrolling axes.

Some games don't have any smooth transition, they just instantly change areas. Some of this is seen in parts of Air Fortress.

Can you guys think of any other techniques used to transition between h/v mirroring?


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 5:48 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3941
Some games just don't transition between mirrorings, and keep scrolling in four directions using the same setting.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 6:58 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
I don't think Megaman ever transitions between directions, if I recall correctly all vertical motion is fast (which hides the mirroring issue). Vertical movement was only ever added in the post-NES games I think.

Most of the games that just swap between screens also happen to be using the nametable for the HUD, where keeping the HUD in place would interfere with thtat. Zelda is the only exception to the rule that comes to my mind (has both HUD and vertical motion), but vertical motion looks jerky (as it's done by just moving tiles instead of scrolling), especially in dungeons where it's slower.


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 8:53 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7224
Location: Chexbres, VD, Switzerland
Games which choose to change mirroring between H and V will do so when the scrolling is equal to (0, 0) so that they can change the mirroring without affecting the displayed screen.

Megaman 3-6 indeed change the mirroring when scrolling direction changes, however it's more to similate one-screen mirroring (only one nametable is used as the main one) rather than to hide scrolling glitches (which would require they to do it the oposite way).


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 10:39 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
I'm of the opinion that a solid 8-way scrolling engine is a much better investment than a clunky 4-way system that has to worry about a bunch of conditions and limitations. Make a good 8-way scrolling system and you can reuse it for practically any kind of scrolling NES game.

It's possible to get glitch-free 8-way scrolling on the NES using only the 2 built-in name tables, but you have to jump through some hoops to accomplish this, specially if you don't have mapper IRQs. For this reason, in my current project I decided to use 4 screens (i.e. no mirroring) and not worry about glitches or special tricks. Adding extra name table RAM to a cartridge is extremely simple if you use CHR-RAM, and is essentially free nowadays because 8KB RAM chips are harder to find than 16KB or 32KB ones, so the memory will often be in the cartridge anyway, and using the extra memory for name tables is just a matter of changing a single wire.


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 11:43 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7224
Location: Chexbres, VD, Switzerland
As someone who wrote a game relying on a "cluncky 4-way scrolling system", I have to disagree with your 1st statement. It really depends on the game. I think the majority of available NES games do not have free 8-way scrolling implemented in them, because this is complex, expensive in terms of memory/ressources, and very error prone. Especially with a status bar.


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 12:02 pm 
Offline

Joined: Tue Sep 27, 2011 8:20 pm
Posts: 23
In reading on the various scrolling methods, I've noticed that there are always accommodations for the status bar. Why does the status bar complicate scrolling in any setting?


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 12:11 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19086
Location: NE Indiana, USA (NTSC)
The map for a status bar requires its own video memory. In a typical 512x240 pixel (horizontal arrangement/vertical mirroring) or 256x480 pixel (vertical arrangement/horizontal mirroring) nametable layout, the visible region may cross the part of video memory devoted to the status bar. Workarounds:
  • Super Mario Bros. 3 levels that aren't vertical are 480 - 48 = 432 pixels tall, to leave room for the status bar at the bottom of a 256x480 pixel nametable.
  • A few games (Little Nemo and Kirby's Adventure) write all changes to both the first and second half of a 256x480 nametable, so that whenever the scroll is about to hit the status bar, it jumps to the other copy.
  • A few games use 256x480 and redraw the status bar between the bottom of one nametable to the bottom of the other nametable whenever the scroll is about to hit the status bar.
  • Most games developed by Rare use 1-screen mirroring, which divides video memory into two independent 256x240 pixel pages.
  • Crystalis uses 256x480 but uses an IRQ at the bottom of 240 pixels to wrap around to the top, simulating 1-screen mirroring mode.


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 12:25 pm 
Offline

Joined: Tue Sep 27, 2011 8:20 pm
Posts: 23
tepples wrote:
The map for a status bar requires its own video memory. In a typical 512x240 pixel (horizontal arrangement/vertical mirroring) or 256x480 pixel (vertical arrangement/horizontal mirroring) nametable layout, the visible region may cross the part of video memory devoted to the status bar. Workarounds:
  • Super Mario Bros. 3 levels that aren't vertical are 480 - 48 = 432 pixels tall, to leave room for the status bar at the bottom of a 256x480 pixel nametable.
  • A few games (Little Nemo and Kirby's Adventure) write all changes to both the first and second half of a 256x480 nametable, so that whenever the scroll is about to hit the status bar, it jumps to the other copy.
  • A few games use 256x480 and redraw the status bar between the bottom of one nametable to the bottom of the other nametable whenever the scroll is about to hit the status bar.
  • Most games developed by Rare use 1-screen mirroring, which divides video memory into two independent 256x240 pixel pages.
  • Crystalis uses 256x480 but uses an IRQ at the bottom of 240 pixels to wrap around to the top, simulating 1-screen mirroring mode.

Hmm, I can see why using a status bar would complicate things.

Bregalad wrote:
Games which choose to change mirroring between H and V will do so when the scrolling is equal to (0, 0) so that they can change the mirroring without affecting the displayed screen.

Megaman 3-6 indeed change the mirroring when scrolling direction changes, however it's more to similate one-screen mirroring (only one nametable is used as the main one) rather than to hide scrolling glitches (which would require they to do it the oposite way).

Can you elaborate a bit on how MM3 uses the h/v mirroring to simulate one-screen mirroring?


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 12:35 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7224
Location: Chexbres, VD, Switzerland
MM3 (as well as 4, 5 and 6) uses horizontal mirroring when scrolling horizontally and vertical mirroring when scrolling vertically. In other term, they use vertical nametable arrangement when scrolling horizontally, and horizontal nametable arrangement when scrolling vertically. They only switch when the scroll is aligned with the screen, obviously.

This means they basically just use the same 32x30 tile map, and the second always remains unused. There is scrolling glitches in all cases, when scrolling horizontally and vertically. They use it for the menu in MM3 and for special effects and minibosses in MM4-6 (but only in some stages).

Doing the exact opposite (switch H/V in a way which reflects the direction the game is scrolling) allows to suppress all scrolling glitches. However, it doesn't allow for any special effects. It doesn't sound like suppressing scrolling glitches was Capcom's priority. Nor anyone else's really, they are standard on NES games, even of late in the console's life.


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 1:00 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
Bregalad wrote:
I think the majority of available NES games do not have free 8-way scrolling implemented in them

I didn't say that most games have it, I said that if you're gonna invest time into coding anything more complex than a side scroller, it's better to invest in an 8-way scrolling engine, because it's more versatile and can accommodate most types of scrolling.

Quote:
because this is complex

More than a side scroller, but not significantly more than a 4-way scroller.

Quote:
expensive in terms of memory/ressources

Depends on how you code it.

Quote:
and very error prone.

If you plan it will well and code it solidly, the result should be as stable as any other engine. Not being able to come up with code to do something doesn't make something "error prone", it just means the programmer didn't find a good way to implement it.

Quote:
Especially with a status bar.

Granted, a status bar will complicate things, but that's the case with any type of vertical scrolling, not just 8-way. If you want free scrolling and a status bar, the easiest solution is to use 1-screen mirroring, unfortunately that comes with artifacts on the sides...


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 1:27 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7224
Location: Chexbres, VD, Switzerland
Ok, I got to admit, I suck at writing 8-way scrolling engine. Both of my attempts failed, since they had glitches on some occasions when changing the scroll direction too much. Thanks god this is hardly necessary for most game styles.

Quote:
Granted, a status bar will complicate things, but that's the case with any type of vertical scrolling, not just 8-way.

Yep. But with 8-way it's updating the rows/column without each getting in the way of themselves which is complicated. Add in combining the status' bar shared attribute data, and it's a nightmare.


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 2:19 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Both of my attempts failed, since they had glitches on some occasions when changing the scroll direction too much.

I have coded a number of 8-way scrolling engines, and based on previous experience, I'd guess this is because of handling one axis entirely before doing the other. For example, if you handle the horizontal scroll first, buffer the new column, and then handle the vertical scroll, you might have problems if you need a new row as well, because the column you prepared before will be vertically off by 1 unit relative to the final position of the camera, which could result in a wrong block overwriting a correct block or in a spot that needed a new block not being updated.

The trick is to move the camera both vertically and horizontally, validate both movements, and only then buffer rows and columns as necessary. This will guarantee that both the row and the column will be aligned to the final position of the camera, so you won't miss any spots or overwrite anything.

Handling one axis entirely before doing the other would be a perfectly valid solution in a system where you can update the map immediately, but since map updates are delayed until the vertical blank on the NES, you have to make sure that all map updates are based on the final state of the camera, to avoid inconsistencies.


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 3:06 pm 
Online
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2961
Location: Tampere, Finland
xgamer wrote:
Hmm, I can see why using a status bar would complicate things.

There's one more, simple, way that tepples didn't mention: using sprites (although it's not really a "status bar" anymore at that point). A lot of 8-way scrolling Imagineering games did this (Bart vs the World, Swamp Thing, Home Alone 2, Bartman Meets Radioactive Man, ...)

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


Top
 Profile  
 
PostPosted: Sun Jun 19, 2016 3:21 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3941
The imagineering games also used DxROM instead of MMC3 since they didn't need IRQs.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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