Widescreen NES Emulator

Can someone make an widescreen NES emulator.
Example:

For SMB3, one would have to modify the game to use four display pages --- a worthwhile task even for use with a standard NES emulator, given how ugly the scrolling routine is at the right edge --- otherwise the emulator would have no wide picture to show.

Regardless of modifying the games, you'd still not be able to get sprites outside of the main 256 pixel area.
You'd pretty much have to do it separately for each game, and rewrite the code that draws the background and sprites from the game's state. This doesn't have to be done in 6502 ASM, it could be done today in LUA for FCEUX.

This is definitely not something that can be implemented on the emulator side alone, since the extended picture simply doesn't exist. We could create a new standard that homebrew games could adhere to (e.g. use one of the unused sprite attribute bits for bit 8 of the sprite's X coordinate), but existing games don't have a hidden part of the picture the emulator can simply choose to show.

Each game draws sprites and backgrounds differently, and makes​ use of the width of the viewport for tasks like scrolling and spawning objects, and modifying these systems would require a substantial amount of work for each individual game. There could even be some game-changing side effects, if objects were spawned sooner than normal or boss arenas were resized to occupy the wider screen.

Open matte

Open matte refers to shooting film in one ratio but framing the shot to be cropped to an ratio. A film might be shot in 4:3, cropped to 16:9 for theatrical release, and opened back to 4:3 for TV and home video.

An analogous process can be done with some NES games. If 4:3 is 256 pixels or 32 tiles wide, then 16:9 is about 336 pixels or 42 tiles wide. This is wider by 5 tiles on both sides. The first Super Mario Bros. puts its seam smack in the middle of the offscreen area, meaning the background would always be correct even as sprites pop in 40 pixels from the sides.

But it's not just the nametable and sprites that might not exist around that 256-pixel window. Haunted: Halloween '85 and The Curse of Possum Hollow stream tile data to CHR RAM as the camera follows Donny through the level. Tiles used only in the beginning of an area get replaced with tiles used only later on. If a tile appears only once in a level, it might be loaded for only 33 tiles' worth of camera movement, replacing a different tile and itself replaced by a different tile. It'd be a trivial patch to load enough nametable data to stay 5 tiles ahead of the right side of the screen, even more so in Curse where the seam position is an explicit variable. But that'd still mean a tile might scroll in corrupt before becoming correct or become corrupt before it leaves the screen.

Tilt and scan

Going forward, perhaps a mode more similar to PocketNES's unscaled mode might be warranted. The screen is cropped to 240x160, but it follows a particular RAM or OAM location to find the player's Y position and adjust the vertical center of the crop rectangle. A further enhancement suggested but not (to my knowledge) implement in PocketNES is to declare the useful parts, so that the status bar is excluded from this tilt-and-scan logic, and excess space between the playfield and status bar is also cropped out. For example, Super Mario Bros. 3 has its status bar at Y=192-239, with the useful part at 200-215 or thereabouts.

Recommendations for NTSC or PAL-M TV system:

• Overscanning emulator: Crop to 256x180, pad to 280x180, scale to 16:9 rectangle
• Underscanning emulator: Crop to 256x164, scale to 16:9 rectangle
• Homebrew game enhanced for widescreen TVs: Add a mode that assumes 32-40 lines of overscan at top and bottom. This gives 256x160 title safe and 256x176 action safe. And on Super NES, consider hi-res interlace at 512x352, which looks great through an S-Video cable.*

Reframing

Pixar movies from A Bug's Life through Cars were produced for reframing. To slightly oversimplify: Some shots were composed in 16:9 with the intent to pan and scan to 4:3, others in 4:3 with the intent to tilt and scan to 16:9.

An emulator could load a reframing script along with a game. The script would watch RAM to infer the game state and use that to infer when to use tilt and scan and with what variables and what status bar ranges, and when open matte is more appropriate.

Anamorphic on non-Nintendo fourth generation consoles

The TurboGrafx-16 and Genesis offer a convenient pair of dot clock rates: a 256px mode with pixels the same size as any other TMS9918 derivative (5.37 MHz, 8:7 = 1.143 PAR) and one 25% to 33% faster. This allows a game to offer a 256px mode for 4:3 TVs and an anamorphic mode that squashes the output horizontally to show more of the map at once for 16:9 TVs. Offer a stretched mode for these. On the TG16 (7.16 MHz), you'd stretch 336x224 to 8:7 = 1.143 PAR (e.g. 1152x672). On the Genesis (6.71 MHz), you'd stretch 320x224 to 128:105 = 1.219 PAR (e.g. 1170x672).

Anamorphic modes became easier to build after the transition to 3D platforms, where everything is already being scaled anyway. GoldenEye 007 and some other Nintendo 64 games offer a 16:9 mode that modifies the projection matrix to assume a 160:119 PAR instead of the N64's native 120:119 PAR.


* RGB looks only slightly better if at all than a full-bandwidth S-Video signal, and the NTSC market by and large didn't get SCART.

I kinda want to play Ninja Gaiden in this hypothetical widescreen mode now