Okk wrote:-Some games have four-direction scrolling without artifacts by adding extra memory.
It's also possible to get rid of these artifacts without extra memory, but that usually involves some sort of sacrifice (e.g. a column of sprites at the right of the screen - which wastes sprites and effectively drops the sprites-per-scanline limit to 7 - or a total of 16 blanked scanlines distributed between the top and bottom of the screen). I guess it's probably better for you to go with the extra memory explanation. =)
If I'm understanding correctly, I could normally swap out up to 64 tiles at a time. Is this between scanlines, or just between frames?
That's perfectly safe to do between scanlines.
Are there other limitations on what tiles I can swap out or swap in? Other mappers would allow for more flexibility... do those involve special hardware?
The only real limitation is that the finest chunks an existing mapper can swap are 1KB (i.e. 64 tiles). If you don't want to change 64 tiles at once, you'll have to repeat the tiles you don't want to change across different 1KB chunks, wasting memory. Also, since the registers are 8-bit, they can only index 256 1KB chunks, so you're limited to 16384 tiles for the entire game. Technically this could be circumvented by wrapping the mapper with a second mapper (many pirate games do this), and then you could pick different sets of 16384 tiles, but that wouldn't be very typical.
For the status bar I need to change tilesets, palettes AND scrolling, all between scanlines and at the same time. Is that plausible?
Tilesets and scrolling could easily be done from one scanline to the next without any glitches, but palettes aren't so simple. If you can afford a few blank scanlines (2 or 3 should do it) between the status bar and the game window, you could pretend to be spreading the color updates across multiple HBlanks, which would make the color changes more plausible.
Also, sometimes the upper screen would scroll vertically instead of horizontally.
That's always tough when a status bar is present. There are software-only solutions to fix this though (which involve dynamically relocating the status bar in the name tables according to the vertical scroll) so it's certainly plausible. A bit annoying to code, but you don't have to worry about that, right?