Quoted from @DiscostewSM:
"As one of the contributors to blargSNES, the only reason why it can run many games at 60fps on an o3DS is because it is not only heavily cycle-inaccurate, but it is also using the GPU for hardware rendering. Nintendo is using software-rendering, which is the most accurate, yet, process-intensive method.
Hardware rendering works by rendering each and every map tile and sprite (each split into 8x8 pixels cels, because that's how the SNES works) as a pair of polygons. Each "unique" tile scanned (from left to right, top scanline to bottom of the frame) has to be converted from the SNES's 2/4/8-bitplane form into a 16-bit direct-color, z-order curve format (because the GPU lacks paletted texture support), and stored into a texture cache. Changing of hte palette means any tiles that used the palette in that range has to be reconverted. The lack of paletted textures means that palette effects that show mid-frame can't happen (excludes the "background color). DKC's first level shows this with the trees, though more recent blargSNES builds has the background color gradient working, not the trees. There are other numerous effects that are missing, but we continue looking for alternatives (but RL has been in the way).
In a worst-case scenario for non-hi-res modes, you're looking at around 14.8k polygons per BG per frame when there is scanline alterations being done. Most games use Mode 1, which has 3 BG layers, so a worst-case scenario there would be ~2.66 million polygons per second. Seem like something the 3DS can handle, but take into account that the polygon list has to be generated per frame, which means the list can't reside in VRAM (nor can the texture cache), so it's all running off the main RAM.
Be aware that while we may not care for inaccuracies for free stuff, we do care when it comes to paying for them."
Best Explanation I've ever seen so far.
"As one of the contributors to blargSNES, the only reason why it can run many games at 60fps on an o3DS is because it is not only heavily cycle-inaccurate, but it is also using the GPU for hardware rendering. Nintendo is using software-rendering, which is the most accurate, yet, process-intensive method.
Hardware rendering works by rendering each and every map tile and sprite (each split into 8x8 pixels cels, because that's how the SNES works) as a pair of polygons. Each "unique" tile scanned (from left to right, top scanline to bottom of the frame) has to be converted from the SNES's 2/4/8-bitplane form into a 16-bit direct-color, z-order curve format (because the GPU lacks paletted texture support), and stored into a texture cache. Changing of hte palette means any tiles that used the palette in that range has to be reconverted. The lack of paletted textures means that palette effects that show mid-frame can't happen (excludes the "background color). DKC's first level shows this with the trees, though more recent blargSNES builds has the background color gradient working, not the trees. There are other numerous effects that are missing, but we continue looking for alternatives (but RL has been in the way).
In a worst-case scenario for non-hi-res modes, you're looking at around 14.8k polygons per BG per frame when there is scanline alterations being done. Most games use Mode 1, which has 3 BG layers, so a worst-case scenario there would be ~2.66 million polygons per second. Seem like something the 3DS can handle, but take into account that the polygon list has to be generated per frame, which means the list can't reside in VRAM (nor can the texture cache), so it's all running off the main RAM.
Be aware that while we may not care for inaccuracies for free stuff, we do care when it comes to paying for them."
Best Explanation I've ever seen so far.
