I don't know if it's possible, but is there a way to tweak the video settings of any emulator to see a level (e.g. Super Mario Bros) from the beginning to the end? Like here:
I know the image from above is photoshopped (I guess), but can an emulator do that, and then still be able to play?
Short answer: No
One thing to keep in mind about older systems (both for video games and home computers) is that memory used to be a luxury. They didn't have gigabytes (or even megabytes) to spare of either storage or RAM. Rendering an entire level when only a small part would be displayed would have been a huge waste of precious computing resources.
Also, there's no reason to assume that every single NES game coded its map the same way. It's very likely that over time they figured out better ways to do it, so even in similar games (SMB1 vs SMB3) the maps would be stored in memory differently. This means that there's no reason to expect an emulator to know how to take a particular game and render the full map for the current level.
There are also a lot of other problems with this - I know that in SMB1, enemies that are off-screen don't move. Would you expect them to be moving the entire time, or only when the active portion of the screen reaches them? The former affects the gameplay of various games, while the latter would require additional logic that currently doesn't exist inside the game code.
Even if you modified the game code, an emulator isn't going to be able to handle it unless you modify the emulator as well. The emulator will need to be able to handle game maps of differing sizes, as well as expecting to give the game more resources.
There are two ways to do this: one generic and one game-specific.
The Nintendo Entertainment System has 2 KiB of video memory in the Control Deck. This is enough for 256x480 pixels or 512x240 pixels of the map, depending on the nametable mirroring mode that the Game Pak chooses. Because the memory in a Game Pak is so small, such as 40 KiB for Super Mario Bros., games store the map compressed and gradually decompress it to video memory as the camera moves through a level.
Nova the Squirrel © 2018 Joshua Hoffman
Animation of newly revealed areas in a scrolling level, taken from "PPU scrolling" on NESdev Wiki. Video memory is at top; the rendered background is at bottom. The orange bracket shows the current scroll position. $2000 and $2400 are the hexadecimal base addresses in video memory of the two tilemaps.
A specially modified emulator could watch for writes to the scroll register and log newly revealed areas of the map. Such a feature would only show visited areas and possibly an approximation of enemy starting positions based on sprites passing through the newly visited area. It would not show unvisited areas at all, in much the same way that a map in a PC real-time strategy game omits unexplored areas. But if a game's map isn't randomized, an emulator can cache the map from a previous play-through of the same level and reveal what is to come.
Though different games use different map data formats, several games have been reverse-engineered in enough detail to allow writing a PC program that decodes an entire map. Often the results of such reverse engineering are posted on RomHacking.net. Some games are understood in such detail that people have created level editors, such as many games in the Mario, Zelda, Metroid, and Mega Man series.
Yes, the requested goal most certainly can be done. This claim isn't just blind theory: Something very similar already has been done.
First of all, I acknowledge the difficulty mentioned by others. Since level data is likely to be stored in different ways for different games (e.g., discussion about Zelda's map data), an emulator would need custom data for each game. Through an expanding collection of plug-ins, that could be done. So I come to the opposite conclusion. It could be done for the finite amount of games that have been commercially released, just as MMCs were added. However, this would be a quite time consuming project due to some substantial difficulty.
There are multiple games with level editors. Such editors know how to read data from the cartridges, and such software has been useful for fans who have sought to have maps that they were confident were completely accurate.
However, let's look at another approach that responds to what was really intended to be asked. Another option is to capture the graphics as they are rendered. You don't get the option to "do that," (make the map), "and then" (in the specified order, after completing the first step) "still be able to play", as the question asked. So this doesn't show the entire map immediately, before the first "play through".
What you do get is a rather automated way to see the map data which was previously on the screen, stitched together rather automatically, which could create maps. (Even if changes were required, having such maps as a starting point might be a while lot easier than trying to make things from scratch.) Since most NES games use map data which is repeated upon a later "play through" (instead of random map data), such maps could be used to look at before playing through again. Based on Question poster's comment, the goal isn't necessarily to see the entire map immediately.
Based on that actual goal, this is definitely a goal that can be achieved (at least with some limited success). A video shows something very similar which has actually been done, by using:
Although map data wasn't stored for long term use, because this project had some slightly different goals, the result showed map data after it was used. I expect that the technique could be modified, rather easily, to save the map data, instead of dismiss the map data. In fact, they have released some partial maps (shown in in a PDF file, and some of which are mentioned on the project's Ars Technical publication). I recall seeing at least the following games, in a video that demonstrates this system:
This is shown by this awesome video: Unfolding The 8-Bit Era (8 bits, 8 players, 8 projectors, and one Nintendo Entertainment System). Prepare to have your jaw drop due to sheer awesomeness. Additional details are provided by the web page referred to in the YouTube video's comments, and also referred to here: Ars Technica article: 8 bits, 8 players, 8 projectors, and one Nintendo Entertainment System.
From the PDF file (distributed by Unfolding the 8-Bit Era): "As our target was 360 degree projection, we focused on side-scrolling games and developed a tracking algorithm designed for this use case. Our method does not currently support vertical scrolling or more complicated camera movement." (I guess people would have had a less interesting experience if they got to far-enough levels in Life Force.)
Yes you can, as you didn't specify an emulator the Dolphin GC/Wii emulator is able to expand the view to be more than the original, I have 3 monitors and I have played several games in Dolphin at 5760x1080. There can be a lot of weird issues with doing this though, often developers and artists are lazy with things that aren't supposed to be on the screen and the things on the outer edges will be distorted, behave strangely or simply won't be there. These issues are somewhat common even in popular PC games.
What you're describing requires that the graphics engine render content that is outside the viewport (the visible screen area). While modern 3D engines do render content outside the viewport into the framebuffer (which would allow the viewport to be expanded to display the extra content), it is not necessary to do this with 2D games of the Super Mario Bros. type nor would doing so be a good way to use the limited hardware resources of the NES.
In fact, the video hardware on the NES does not even have a framebuffer in the modern sense of graphics memory that holds rendered video frames to be displayed on the screen. It stores tiles and sprites in memory and renders them directly to the screen, so what you're describing is not technically possible on the NES. (There were various chips that could augment the capabilities of the graphics hardware but none of these allow the console to render to a framebuffer, let alone provide sufficient memory for one.)
Yes you can. For sure. All the NES (and similar) games that perform scrolling have all the positions of the tiles of everything that can be displayed registered in the ROM memory chip somehow. This information is read by the NES original program only when the scene is visible because the systems of that era had not computational resource to waste. But even when the scene is not alive in the screen running on RAM memory chip, somehow the scene exists anyway on static ROM memory chip. The standard purpose of an emulator is just run the original program as original as possible with very few intention of making things run augmented somehow. However, this is not true for the graphics display. Emulators use to have intention of making some sorts of graphical augmentation somehow. A skillful programmer with the will of doing field of view graphical augmentation on NES emulator can theoretically read the full map on the ROM and place the emulated screen on the top of the full map on the right spot at each frame and show on the monitor a custom window cut off of this full map with the actual emulated original screen occupying a smaller portion of the customized crop that is displayed. In this case, however, objects will almost never move when they are out of the original field of view. Unless another skillful programmer decide to program an artificial intelligence network that can machine learn the tile swapping behavior given the character movements and game time as inputs. If so, many objects will move even when they are out of the original screen space as long as the artificial neural network is smart enough to output a logic to that movement that puts the object on the exact spot when it enters the original screen. The problem is that as far as I now nobody did these things yet.
