DRW wrote:
I did the CNROM chapter from the Nerdy Nights tutorial, but this one was nothing more than switching between two sets of graphics data.
Well, all that CNROM can do is switch between 8KB CHR sets, so...
Quote:
Is there a similar explanation that teaches you how to do UNROM? I mean, I know how to do NES programming in general.
UNROM is very simple because it only has one register, which selects a 16KB PRG-ROM page at $8000-$BFFF, while $C000-$FFFF is hardwired to the last bank in the ROM. Having a hardwired bank is very convenient, it serves as a safe place to put the stuff that must be available at all times, such as the CPU vectors, and the interrupt handlers, as well as the code that manages the switchable slot. Stuff like music code and data, graphics, maps, etc. would be switched into $8000-$BFFF as necessary. Even parts of the engine can go into switchable banks if the hardwired bank isn't enough, but this is something you're gonna have to design carefully. No document/tutorial will teach you how to organize your code and data across different PRG-ROM banks.
Another significant difference compared to NROM is that UNROM uses CHR-RAM, so you have to upload any tiles you're gonna use to VRAM yourself (using $2006/$2007, exactly like you do when writing to the name tables), but you can easily simulate NROM-style CHR-ROM by only uploading 8KB chunks of CHR if that makes you more comfortable than if you had to manage smaller chunks more dynamically.
DRW wrote:
If I cannot switch the mirroring, vertical scrolling will produce graphical artifacts because I write the new data on the currently visible screen. And in this case, there's not status bar to hide it.
Yes, that might be a problem. Not a big one if you're doing delayed scrolling like in Zelda or Mega Man. If you scroll 16-pixels per frame, you can do it without glitches. If you want smooth scrolling though, then yeah, there will be visible glitches at the top and/or bottom of the screen.
Quote:
I know that this might not be visible due to a TV's overscan, but I still prefer to hide these artifcats.
Me too.
Quote:
What are the best ways to do this?
There are several ways to implement glitch-free 8-way scrolling. Here are 2 techniques used by commercial games:
Jurassic Park: Uses IRQs to blank the background at the top and bottom 8 scanlines, effectively creating a 16-scanline area where to hide the scroll seam. You don't have IRQs with NROM or UNROM, but you can still mask scanlines at the top of the screen without much trouble.
Alfred Chicken: Uses horizontal mirroring, so that there are no vertical glitches, and hides horizontal glitches by masking the leftmost 8 pixels (the PPU can do this if you tell it to) and covering the rightmost 8 pixels using a column of sprites that spans the entire height of the screen. Yeah, it sucks to use that many sprites for this, and it sucks that your sprites-per-scanline limit is effectively reduced to 7, but it works. Felix the Cat is another example of a game that hides scrolling glitches that way, and it still manages to have pretty big sprites throughout the game.
For a long time, my preferred technique for implementing glitch-free 8-way scrolling consisted in putting 9 high priority 8x16 sprites at the very top of the screen, and starting the frame with background rendering disabled. The high priority sprites served 2 purposes: mask any other sprites that eventually went up there, and trigger the overflow flag so I could tell when the frame started, so I could start timing the 16 scanlines it'd take until it was time to turn background rendering on.
This technique worked pretty well, but many people found the 16 blank scanlines unappealing, and I was basically wasting 9 sprites and some CPU time that could otherwise be spent on the actual game. So I ultimately decided to use a 4-screen layout (no NT mirroring) and do away with all the complications. In emulation, all you have to do is set a flag in the iNES header and there you have it, 4 name tables available for glorious 8-way scrolling, without the need for any tricks. On actual hardware, it's also pretty simple if you're using CHR-RAM, and it's practically free since nowadays you can't really buy 8KB RAM chips anymore, so the memory that would normally be wasted can be used for name tables instead. If you want my honest advice, go with a 4-screen layout and forget about all the tricks.
4-screen is definitely overkill if you're only doing delayed Zelda-like scrolling, but it's the most versatile NT layout you can get since there are lots of off-screen areas where to hide all sorts of updates.
Bregalad wrote:
I know some (especially Tokumary) will disagree, but my personal opinion is that the "best way" is, by far, to do like 98% of the NES games out there : To ignore this non-issue. It is just an accepted standard to have some minour glitches on the sides of the screen, ESPECIALLY at the top and bottom.
I do indeed find scrolling glitches terribly distracting. In all TVs I played NES games on, these glitches were very apparent and kept distracting me from the gameplay, no matter if they were horizontal or vertical.