Arqade is a question and answer site for passionate videogamers on all platforms. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
42  
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. – Ashley Nunn Feb 8 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... – DangerZone Feb 8 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 Feb 8 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 – user297876 Feb 8 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. – DangerZone Feb 8 at 21:46
up vote 85 down vote accepted

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.

share|improve this answer
    
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. – user297876 Feb 8 at 21:20
    
It's not like this changed, of course - modern games don't keep all their world in the memory at once either, much less render it. We always find better things to do with the extra memory and CPU than waste it on drawing things that aren't visible anyway :D – Luaan Feb 9 at 13:21
15  
"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. – duskwuff Feb 9 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 Feb 9 at 21:11
11  
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 Feb 9 at 21:40

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.

SMB1

Super Mario Bros. © 1985 Nintendo
Animation of newly revealed areas in WORLD 1-2, taken from "PPU scrolling" on NESdev Wiki. Video memory is at top; the rendered background is at bottom. The red bracket shows the current scroll position.

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.

share|improve this answer
8  
+1 because I love the technical references. Thank you kindly. – TOOGAM Feb 9 at 0:03
1  
Side note: The dollar signs in the animation indicate hexadecimal memory addresses, not dollars. – immibis Feb 11 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 Feb 11 at 20:36
    
@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. – Damian Yerrick Feb 11 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 Feb 12 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.)

share|improve this answer
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. :) – user297876 Feb 9 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 Feb 9 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.

share|improve this answer
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 Feb 9 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 Feb 9 at 21:30
1  
In LoL they may also be worried about unfair advantages while using multiple monitors. – Nate Diamond Feb 11 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 Feb 12 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 Feb 12 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.)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.