Shrinking BGs down to 2/3 size using mid-scanline scrolling?

This is something I recently thought of. Although it's easy to shrink a BG layer vertically using HDMA, it's not really possible to do the same horizontally, or at least I had always assumed. I was thinking about 93143's full color picture and how it constantly changed the color every 4 pixels, and it got me wondering if the same could be done for a BG layer's x-scroll position. If you're only scrolling the part that is initially visible (as in 256 pixels wide) than you should only need to mess with the low byte of the scroll value, and because that's half of the amount of data in one color on the SNES, the granularity of changing the position should be half, shouldn't it? About the only being 256 pixels wide, I mean that it would just kind of drag the sides with it and they wouldn't be shrunk. 2/3 comes from the fact that you're effectively masking a pixel every two pixels. One thing though, I'm assuming you could have it change the horizontal scroll value in 3 or 5 pixels or something like that, just as long as it's not under 2? Obviously, this would only be used for a title screen or a cut scene or something where there's next to no processing being done.

The S-PPU has mode 7, you know

I knew that was coming.

The problem is if you want to shrink something that uses more than 256 tiles, or if you want an extra BG or something in the background. It's not very practical, but I can think of some uses. If you wanted to scale this thing past 2/3, you'd need to have another one prerendered (or shrunk in software) and shrink that in the same way. (Anything using multiple palettes could definitely be messed up though). Vram bandwidth is just such a pain, because if it weren't that, nothing would be stopping you from having prerendered shrunken copies, although that'd be a huge amount of space.

You can't just write the low byte repeatedly. It's an 8-bit dual-write register, so the second write is always the high byte.

Also, depending on how exactly the scroll caching works, it may not be possible to do much scaling this way. I know it takes at least a couple of columns for a scroll change to 'take', but I haven't tested the effect of multiple changes in rapid succession.

Furthermore, there's the DRAM refresh down the middle of the screen, and I can't think of a good way to cache scroll values like I did with colours in CGRAM...

Well, it was a stupid idea anyway.

This definitely won't work. Think about it: in order to "shrink" a layer horizontally, the PPU would have to somehow fetch more than the usual 33 tiles in one scanline. Where is the bandwidth for that going to come from? It doesn't matter that only some of the pixels in those tiles are ultimately visible; the PPU can only fetch 8-pixel slivers, not random individual pixels.

Mode 7 uses a different data format precisely so that random pixels in VRAM can be addressed.

Wow, now I feel stupid.

I wonder what would happen though... (obviously not the intended result)

I've always wondered if there was a way to fake a 320x224 tile map layer using 512x224 mode. I'm thinking that it could be arranged in 48x16 metatiles that represent 32x16 metatiles, and dynamically allocating new metatiles as it scrolls or change.