The reason you're not getting any answers is because this is one of the things every game programmer has to solve in their own way, re: the "strategy", and there is no simple way to describe how to do it. It also varies heavily on the type of game you want to do and what you actually want the experience to be. What you're asking about is one of the key parts to an actual game engine.
This is one of the things I struggled with for literally years when starting out doing SNES stuff in the very early 90s. Conceptually it's simple -- "I just need to make sure the sides of the screen (columns of tiles) get updated before I pan the screen left/right" (or for scrolling vertically, updating rows of tiles) -- except actually implementing the "how do I correlate my map with the actual tiles on screen" part is not easy at all. This is further compounded by technical complexities such as the SNES's graphics modes (mode 1 is pretty common, but it all depends on what you want, maybe you'd prefer mode 2 or 3), and then later, intermediary data formats (that make up your "virtual world") and having to convert from that to SC data, handle sprites, collision, layering, etc..
There is not enough PPU RAM (VRAM) for "an entire world" -- there is only enough for essentially 2 horizontal screens and 2 vertical screens of tilemaps (SC data) on a per-background basis (for modes 0, 1, 2, 3, and 4). 2x2 is what you get when you use a screen size of 3 (e.g. bits 1 and 0 of $2107/2108/2019/210A are both set).
The BG scroll MMIO registers essentially let you "pan around" this PPU RAM, but
you yourself have to code the routine that updates the tilemap (SC data), the system does not do it itself. Thus, you yourself end up having to write a bunch of 65816 that updates the non-visible parts, so that when the BG scroll registers pan the screen around, there aren't any visual artefacts.
For starters: do you understand this? If not, then start with trying to understand it. I recommend referring to the developers manual, specifically pages 2-27-4 (describing $2107/2109/2109/210A), combined with page A-10 (SC data format, but also gives a visual of how it all works), and A-21. Don't bother with page A-22, as that's for modes 5 and 6, which will confuse the hell out of you.
If you do understand it: great, then your question is truly "how do I write the code that does all of this?"
A big part of the question is exactly what kind of game you're wanting. Your screenshots seem to imply you want an overhead world RPG-esque type of thing, like Zelda 3. With that game, there are "areas" that have limited size (which span several screens that pan/update smoothly). But if you pay close attention, you'll see that the world is not 100% seamless -- you reach "edges" of an area. The areas themselves are big (several screens in size), but there are still "edges". That's because there's limited system resources in general (RAM, ROM, whatever) and technical limitations; the "edges" are essentially points where new data is loaded and thus a new "area" becomes available. Even "huge" world games like Super Metroid work this way too.
Quite often there's an intermediary format of the data used, i.e. a unique data format that you yourself design that represents all the "stuff" that makes up an area -- not just raw data you can DMA to PPU RAM. Your code has to load/translate that data into SC data, probably reading it from ROM and storing the DMA-able results in RAM (banks $7E/7F somewhere), then DMAing portions as needed. You should not try to DMA
entire screens of SC data every frame -- there isn't enough time to do this. You need to use $2115 to change the PPU RAM increment value into something that can work with columns (e.g. 32) when dealing with panning left/right, or with rows (e.g. 1) when panning up/down.
Essentially you need to track everything that's being done -- everything. Welcome to how complicated video games actually are.
Personal note: I think I spent months writing down code on paper trying to figure out how exactly to go about implementing such a thing. Pretty much every single game does it, so it's not impossible, it's just complicated to think about (IMO).
The overall "strategy" is used identically on the NES as well (though on the NES, unlike the SNES, scrolling both directions is a bit tricky, which is why most games you'd see only pan left-to-right or top-to-bottom and not both simultaneously. This has to do with the limited RAM on the NES), so anyone here who has done it should be able to help talk about the method/model and the overall thought process/implementation would apply to the SNES too. I'll post something in the NES-oriented boards asking folks to look at this thread + describe the models they use (edit:
posted as promised).
I would suggest start with something simple: don't worry about the intermediary data format and what not yet. Start with multiple screens of raw SC data in ROM. Try to figure out a routine that can update rows and columns of screen data, DMAing those relevant portions from ROM into PPU RAM, while letting you pan the background around up/down/left/right using the joypad.
