Squishy Tia wrote:
I'm actually surprised the SNES had enough horsepower to dynamically switch resolutions like that without either slowdown or the flashing I'm seeing. Unfortunately, a real SNES and BSNES/9x as well, have the input lag associated with such switches
I'm not an expert in SNES, but my general architectural sense is that resolution
switching on early consoles and PCs like the Apple II should actually require less "horsepower" than modern PCs. It was likely only one bit of a register that determined what pixel clock to use and how much VRAM to address. Modern graphics cards have a whole pipeline that needs to be updated and buffers that need to be reallocated from a gratuitously larger memory bank. Hence, while the hardware could probably do the switch transparently in a single opcode by design, any emulation needs to clear out the entire render pipe and rebuild it at the new resolution.
Also, since I would believe aspect-ratio correction is just an OpenGL stretch of the render texture, forcing hi/lo-res shouldn't complicate anything. Blitters might get a bit confused, but last I actually used them, iirc blitters didn't like high-res mode anyway. Again keeping in mind that the SNES and early consoles accessed VRAM in a fairly direct and hardcoded fashion, I'd imagine SuperFX and other specialty chips would still only write to the regions they were created to write to, even if the screen space itself is interpreted differently, although that could easily depend on how high-res graphics mode works (i.e. are pixel-writes just auto-doubled in lo-res mode with the same VRAM and scan timing used either way, or does hi-res actually double the buffer size and pixel clock).
Resolution
filling, on the other hand, will take proportionally more time either way, which is likely why the SNES chugs when it's running hi-res.