Emulating SNES games hits us right in the nostalgic feels, but playing SNES games on an 1920×1080 monitor is a painful reminder of the limitations of SNES hardware. [DerKoun] felt the same consternation, and decided to do something about it. He realized that some SNES games have much higher resolution textures that weren’t being taken advantage of. The SNES had a revolutionary video mode, mode 7, that allowed a game to set a relatively high resolution background, and then rotate and scale that background during gameplay.
This pseudo 3d effect was amazing for its time, but taking a high resolution image and squashing it into a 320 by 240 pixel viewport makes for some painful artefacts. This is where [DerKoun]’s hack comes in. He wrote a modification to the bsnes emulator, allowing those rotations and scaling to happen in full resolution, vastly improving the visuals of mode 7 games.
The latest teaser for what’s to come is shown above, mapping the mode 7 backgrounds onto a widescreen viewport, as well as HD.
Come back after the break for some mind blowing SNES HD PilotWings action!
Update: Development discussion has continued in a new thread. Start with link above to get origin story and continue to the new dev thread for recent updates.
Via Ars Technica
The explanation is somewhat off here. What’s actually happening is greater oversampling on the Mode-7 texture prior to transformation. So when performing an arbitrary rotation, instead of each pixel being divided into (say) 16 subpixels, it’s being split into more like 256. This makes the resulting rotations and scales much higher precision.
This post on ResetEra does a great job of explaining it visually:
https://www.resetera.com/threads/bsnes-emulator-mod-allows-for-hd-rendering-of-mode7-games.111715/page-2#post-19876078
The HD output at the end is nice, but it’s also possible to enable downscaling after the fact. This results in the same 320×240 viewport (well, 256×240 really, SNES has non-square pixels) so the sprites don’t look out of place, BUT because of the improved accuracy of the underlying transformations, the result looks much better without sparkly pixels etc
The sort of give and take of hardware acceleration with intent-based interfaces (“rotate and scale this bitmap and use it as a backdrop”) vs. exactly specified functions which may generally be used for one thing but don’t encode specific intent is always interesting in games (especially consoles or fixed-hardware platforms like the Amiga 500).
On one hand the intent-based approach allows future generations of the platform (or emulators much later) to implement the represented intent differently or even better than was possible with the original.
On the other hand the exact effect with no implied intent is often leveraged in games and demos to implement wild ground-breaking effects by cleverly using the hardware for purposes other than the common expected ones (e.g.pallet animation letting you trade some color depth to animate a bitmap in a way that would otherwise challenge memory or memory bandwidth) but it does generally preclude improving on the implementation from “outside” like this.
For the sake of argument, if someone had worked backwards the artifact to rotation and scaling space in detail and written a game that contained a specially encoded bitmap and set the rotation to a seemingly disjointed set of angles to cause it to look like driving sleet for instance (abusing the specific implementation of an intent based interface for its artifacts) that game would look very bad with this applied.
The number of games that break when emulation is imperfect (fails to contain glitches and artifacts the original platform had unintentionally or whatever) suggests that a fair amount of that kind of hackery went into many games. It’s just so neat…
does it work with star fox?
No, Starfox uses the Super FX chip (basically a software-defined math coprocessor) and doesn’t benefit from Mode 7 enhancements. This is for things like Mario Kart, F-Zero, Pilotwings, overworld maps in a lot of RPGs, etc.
er, well, “math coprocessor” is kind of underselling it… it’s a full RISC processor with its own work RAM, a 512 byte instruction cache, and some fast math functions not found on the SNES primary CPU. Games that used it would load code to do things like sprite rotation, polygon render, etc. It can run in parallel to the primary CPU and write to a shared framebuffer or RAM area.
Because its operation is software-defined (SuperFX code is stored in the game cartridge and loaded at boot) it can’t really be HLE’d, and so accelerating or upscaling that would require game-specific hacks… Unlike this Mode7 change, which is a feature of the SNES S-PPU “picture processing unit” (the hardware render interface).
https://en.wikibooks.org/wiki/Super_NES_Programming/Super_FX_tutorial
i was kind of under the impression that the fx chip only handled polygon rendering with mode 7 handling the horizon and sky.
I would have thought doing anything on 1920×1080 would be painfull..
Get off my lawn!
To me, the coolest part isn’t the higher resolution. It’s trivial to re-use the matrix transformation coefficients and get higher horizontal resolution, and it’s straightforward to interpolate from scanline to scanline to get more vertical resolution…
To me, the coolest part is finding the HDMA tables that change the projection from scanline to scanline, backing out what the intended 3D projection had been, and re-drawing the texture based on that.