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:

Super Mario Bros 1-1 Full level map

I know the image from above is photoshopped (I guess), but can an emulator do that, and then still be able to play?

  • 47
    I'd guess not, because the games themselves weren't designed to be played that way, so I suspect there will be actual technical limitations that prevent that from being a possibility - it's not really just a case of like...zooming out.
    – user11502
    Commented Feb 8, 2016 at 21:08
  • 6
    Agreed with what @AshleyNunn said. Emulators are to built to emulate, not modify the way the game works. The definition of emulate is basically reproducing (matching or even exceeding) the function of some sort of system. Although I should say some "cheat" and with framerate altering, save states, etc... Commented Feb 8, 2016 at 21:14
  • 2
    Where would one even find a monitor/screen wide enough to display everything at once like that? Otherwise I would imagine the vertical render would be way too small to even see. o_O
    – C-dizzle
    Commented Feb 8, 2016 at 21:21
  • 2
    Well, I didn't wanted to see the hole level. I just wanted to adjust emulator's screen, but the game elements (e.g Mario) should occupy the same size. Therefore, emulator window size should not influence game resolution
    – Vlad Sandu
    Commented Feb 8, 2016 at 21:35
  • 2
    I'm confused... You want to adjust the size of things but not their resolution? Either way, there is no emulator I am aware of that currently does this. Commented Feb 8, 2016 at 21:46

6 Answers 6


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.

  • Thank you for your answer. You're right, for an emulator to be able to do this kind of "zoom-out" it has to know how the game was written. Therefore, an emulator should be built for any game to be able to do that, and it's a waste of time.
    – Vlad Sandu
    Commented Feb 8, 2016 at 21:20
  • 18
    "in SMB1, enemies that are off-screen don't move" - It'd be more accurate to say that enemies don't exist at all until they come on-screen.
    – user86277
    Commented Feb 9, 2016 at 21:00
  • 3
    @duskwuff : False. Bowser breathes his flames. (Even if the sprite doesn't exist on a technical level, according to storyline theory he clearly is there at that point.) And I would say the Piranha Plants exist before they are visible. Hmm... let's see if I can come up with some others real quick. I suspect Lukitu might (briefly) as well. If bricks get created column by column, then the swimming area just above the pipe (original release) doesn't become potentially fatal for Super Mario until the next column is created.
    – TOOGAM
    Commented Feb 9, 2016 at 21:11
  • 16
    That's not correct either. Dusk is right that the enemies "do not exist" until they're close enough to the camera and spawn into the world. Story wise, yes, Bowser is shooting fire at you and those Priana are hiding in the pipes, but from a memory standpoint: Those Priana exist on top of the pipes, and the "animation" is just their hitbox disappearing while they disappear on their cell. Likewise, Bowser's fire in castle levels are auto generated until Bowser is spawn, in which case it uses his sprite as reference.
    – NBN-Alex
    Commented Feb 9, 2016 at 21:40
  • 2
    As a side note, porting an SMB1 level to Super Mario Maker makes enemies more sooner because SMM has a wider screen.
    – Powerlord
    Commented Mar 23, 2017 at 18:20

There are two ways to do this: one generic and one game-specific.

Watching the scroll seam

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

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.

Reverse engineering

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.

  • 8
    +1 because I love the technical references. Thank you kindly.
    – TOOGAM
    Commented Feb 9, 2016 at 0:03
  • 1
    Side note: The dollar signs in the animation indicate hexadecimal memory addresses, not dollars. Commented Feb 11, 2016 at 19:07
  • So to answer the question then, "Is it possible to scale an emulator's video to see more of the level?" what are you saying? Which emulator can the OP use?
    – Octopus
    Commented Feb 11, 2016 at 20:36
  • 1
    @Octopus I'm saying an emulator with this feature could be created, not that any particular emulator with this feature is available to the public. Commented Feb 11, 2016 at 21:24
  • This has been applied to have 8 players time-based sequentially coop play NES games on a 360° screen: see article and paper
    – Lloeki
    Commented Feb 12, 2016 at 13:27

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:

  • a real NES
  • real NES controllers
  • custom hardware, which combined input from multiple NES controllers
  • hardware that processed the video that gets displayed

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:

  • Super Mario Bros. (1)
  • Super Mario Bros. 2 (American release) (a.k.a. "Super Mario USA")
  • Super Mario Bros. 3
  • Probotector (re-skinned version of "Contra", as released in Europe)
  • Castlevania
  • Life Force
  • ExciteBike

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.)

  • 2
    Thank you for your feedback ! All this discussion from a simple question makes me think a little bit more about how games are made, especially those on cartridges. I'd love to have a cours about this at computer science faculty. :)
    – Vlad Sandu
    Commented Feb 9, 2016 at 9:12
  • 1
    I reccomend "Racing the Beam", early history of Atari from the MIT "platform studies" group. mitpress.mit.edu/books/racing-beam
    – pjc50
    Commented Feb 9, 2016 at 12:05

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.

  • 14
    I would NOT call it "lazy" to not worry about properly handling things that are by design not going to be used. It's like calling an automobile engineer "lazy" for not designing a Chevy Cobalt for interdimensional travel.
    – krillgar
    Commented Feb 9, 2016 at 20:54
  • 1
    Well maybe on emulated games it isn't since they are meant for specific hardware and output resolutions, it is on PC games though. Like for example League of Legends if I put it on 3 monitors the background that surrounds the map isn't big enough and it ends leaving everything just black. The game supports 5760x1080 without mods so they know people will do it and they could have just made the background image a bit bigger but they were too lazy to do it.
    – Probst
    Commented Feb 9, 2016 at 21:30
  • 1
    In LoL they may also be worried about unfair advantages while using multiple monitors. Commented Feb 11, 2016 at 23:31
  • Consoles like the Wii are designed to be hooked up to a single display with a specific maximum resolution. There is no need for the game developer to design the engine to render well-defined content outside the 854x480 viewport of the Wii. There may be more data outside the viewport in the framebuffer but you shouldn't expect it to be well-defined.
    – bwDraco
    Commented Feb 12, 2016 at 6:20
  • "on emulated games it isn't since they are meant for specific hardware and output resolutions, it is on PC games though" I literally just said that, but thanks anyways...
    – Probst
    Commented Feb 12, 2016 at 15:14

This isn't possible under live emulation of the NES.

  • 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .