Finally got CN in the mail, and the first thing I did after installing the ninjhax was try this emu. It works rather well, especially the hardware-accelerated version (even if it is unofficial).
I'm just going to throw out this idea, but first, how fast can the system render polygons, and how many do you think it can do in a frame's worth of time? Can it do multi-texturing on a single polygon? The problem with dealing with graphic rendering of the SNES is that graphics (excluding those designed for Mode-7) are organized in bit-plane form. StapleButter has done a great job with the tile-cache method to generate tiles of the appropriate 16-bit format usable by the hardware, but this recent development of palettes changing on the H-Blank would mess with this approach. Now, onto some things regarding my idea (that I'll get to afterwards).
From what I understand, you are able to set a polygon's color (in a similar fashion that glColor does in OpenGL), in that if it is set to full white, a non-textured polygon will also be white and a textured one will have the texture act like no color alterations were made. When set to 50% for each color component, the non-textured will be grey and the textured one will be dimmed by 50%. And black, well, both will be black. Now, imagine a 2-bit paletted-texture applied to a polygon (with color 0 being transparent). On the texture, there are only 3 colors. Imagine that you separated those colors and placed them on individual textures. Now, set all those "filled" pixels to complete white. Now, take 3 quad polygons, assign one of these unique textures to each, and overlap them in the same spot. A white silhouette of the original texture. Now, for each polygon, assign the color (like with glColor) to what the textures originally were colored with. What you have now is, with the use of multiple textures and polygons, a representation of a 2-bit paletted texture without actually having paletted-texture support. If a color of the original palette changes, you just change the color to the corresponding polygon, and voila. If you need a visual representation of what I'm talking about, here's a shoddy example that I made when thinking of porting my Megaman 2 PTC project to the 3DS SmileBasic (which does not have paletted support)
So, here's my question. Does the 3DS GPU have enough polygonal power to do something like this for background layers and sprites? I'm just thinking of 15 textures that are of the size of the SNES VRAM (in 16-bit form) that contains all white but various pixels are set as 0 (for the alpha) to represent the 2/4-bit graphics (8-bit would require 127 of these textures, and I think that's too much, both in 3DS VRAM usage and polygons to render per tile). When the emulator writes to the SNES VRAM sections, the emulator would also set the pixels for the various textures to be either on or off (if the area being written is related to graphic cels). Then, during the actual render phase, polygons are rendered using these textures and having them set with the glColor equivalent to match the color palette row (3 polygons for 2-bit and 15 polygons for 4-bit, no need to render one for color 0). If multi-texturing is supported, it could reduce the number of polygons that would need to be rendered.
....does this make any sense, and if it does, is it even a plausible idea?