psycopathicteen wrote:
Not normally, but if every 8x8 tile consists of 2 solid colored halves, then you can pull off a 4bpp packed pixel 256x128 window.
In other words, you can use the S-CPU to render into what is essentially an untiled version of Mega Drive VDP format, and use the result as your tilemap.
Only catch is, you don't have any space left over for any other colours in CGRAM. Unless you use direct colour mode for the Mode 7 layer, and since you're rendering to the map and not the tiles, there's no reason you couldn't do this. It just limits you to 8-bit RGB, which is kinda bad, but eh... EDIT: see below.
Furthermore, 256x128 is the absolute limit of what you can cover with 16x16 sprites, meaning you can't do seamless backdrop tilting or even scroll unless you use 32x32 - or possibly 16x32...? The non-square PAR might let you get away with more vertical skew than horizontal, but then it wouldn't match the rendered layer unless you applied a transform to one of the axes every time you computed a projection, which would be expensive, and hidden penalties like that are best avoided if you're trying to prove something about CPU power... maybe the Corneria background wouldn't be all that bad; it doesn't have much in the way of verticality...
...just thought of something: I believe the MD Star Fox mockup uses column scroll to tilt the rendered layer, in order to avoid the extra rotation transform. Technically tilting a Mode 7 layer should be trivial, but if you're already at 256x128 there's no wiggle room...
One final issue is that if you're rendering into Mode 7, you can't use the PPU multiplier during the display period. This could be a serious obstacle to doing decent 3D on a stock SNES. I haven't looked into this much, but I think there are a bunch of tricks that have been used in the past to do fast bitplane rendering of polygons on a 65xx. If you can render more than one or two pixels at a time, because most polygons are untextured, the bitplane format isn't such a crushing disadvantage. Plus you can set up the VRAM gate to take linear bitplane and distribute it into tiles in VRAM, so you don't need to worry about tiled rendering either way...
...
I actually used this same packed-tile Mode 7 idea for a background for my port, except I used it as a compression technique. With a brute force optimizer in Matlab, plus a bit of hand-tuning, I managed to get a 128x128 image with over a hundred colours into 24 KB of VRAM (well, 12 KB of tile data and 8 KB for the map). The result is virtually indistinguishable from the uncompressed image, and as a bonus, rotation is a lot smoother at the same zoom level, because it's basically doing sub-texel positioning.
Unfortunately, the success of this compression method seems to be highly material-dependent. I tried it again on a different image (a larger one - 128x192) and had to back it all the way down to 14 colours to fit it in 192 tiles with acceptable levels of artifacting.