How do videogames store information offscreen?

Question

I'm trying to make a videogame from scratch, but I'm really new to this and keep running into basic issues. Most importantly, how do videogames store offscreen information? What I mean is, how does the program know what to display next onto the screen? Or even, if the player changes the environment, how does this change remain for the next time it loads onto the screen?

For example, in New Super Mario Bros, if you hit a ? block and then go off screen, and come back, it still remains hit. How is this information kept and then executed the next time the player loads the block? Why doesn't it just reset?

Answer 1

Usually you should separate the logical state of your game environment from the visual representation.

The player might only see a small part of it on their screen, but you still keep the state of the whole level in memory and usually also calculate the game mechanics for the whole level. When your world is so huge that this would require too much ram and/or cpu, you can suspend further away areas to hard drive.

Your rendering subroutine checks which parts of the level are currently on the screen and then only draws those. Whatever is off-screen isn't drawn, but that doesn't mean it isn't updated.

Answer 2

You are going at it backwards.

You start with the logical state of your game and model that. The whole logical state of the entire world will almost certainly be too much to be held in memory at once, so you break it down in smaller parts that can be loaded and saved independently. These parts are often referred to as chunks. These chunks can form a continuous world, but they can also be separate levels/instances. Terminology varies wildly depending on genre and which technique you want to use.

Then you load those parts that are of interest -- that is, chunks that are in the vicinity of the player. Chunks that are too far away are saved to disk/permanent storage and unloaded from memory.

And then, as last step, you determine what is actually visible and create the visual representation of the current game state and render it on the screen.

Of course you would try not to rebuild the entire visual representation every time but cache it and re-use it if you have parts that are already constructed, but that is the main principle.

---

This holds true for any program that has output. If you write a program with a normal GUI, like a text editor, you would likely model the document, and then the GUI would determine the state and visible parts of the document and render it to screen. Or fill form fields appropriately, or else.

The main gist is: Think about where and how you store the data first (probably alongside with how to represent it). Almost every program has to deal with data storage. There is only very few cases in which you don't store any data.

Answer 3

As others have said, you keep a map (e.g. in an array) and draw the visible part of it to the screen, and don't read back from the screen.

But in some older systems you would literally keep data offscreen. There would be, say, 400x300 pixels of video memory for a 320x200 display, and you would define a viewport into that ("start at X=10 Y=30"). So you could scroll the screen by just adjusting a register. You wouldn't have to spend the hundred thousand cycles required to move the bytes around, you just change where the video hardware starts reading them.

The NES has this, combined with a tile-based system: http://wiki.nesdev.com/w/index.php/PPU_scrolling

The NES never constructs the full image in memory, because it doesn't have enough RAM. Instead, there's a RAM array that defines a two-screen-wide set of tiles. One byte per kind of tile. The video hardware looks up the tile and X/Y offset coordinates in order to decide what pixel should appear at any point.

Answer 4

Well, if you are asking this kind of question you are going to have a long road to get to the point where you can make a game. But, getting to the heart of your question, the program can save the state of many different things in variables which are in the back end of your program. Let's look at a couple of examples.

Mario Brothers (or similar) saves the state of the level you are in. that might include how far you have gone before you died, if a block was hit or not. In some a more object oriented sense, the game just says "be a block here" and the block exists. then when you hit the block, the block changes its own internal state to say "I was hit". Data like that can be stored in a variety of ways.

Your word processor saves its data in a data structure. Now there are lots of these and many ways they can be implemented, but probably it uses some form of a tree. In a tree you have at least one node. Anything added before it goes to the left. Anything added after it, goes to the right. After you add three nodes you have two of them hanging off the middle node. And the tree can grow even larger with new pieces being added anywhere and the tree will rebuild itself. Or think about shooter games where your enemy wanders around. Each of them has variables which tracks their location, life, etc. so that when you wound one, it will remember that it was hurt.

All of these things require a knowledge of data structures. It goes way beyond what you see on the screen. I would suggest reading about arrays, lists, hashes (sometimes called dictionaries or maps) and then coming back to your problem.

Here are some good starting materials:

• http://visualgo.net/

Answer 5

To an extent, this is a function of how 3D is rendered. For example, OpenGL will automatically cull geometry outside of the -1.0, +1.0 range in X-Y screen space (Z is more complex but similar). Culled geometry never generates fragments (approximately pixels) and thus is never turned into actual imagery, despite being sent to the system to render. In any case, it's impossible to write to space outside the render window (if everything is working as it should).

In some contexts, it's enough to rely on this behavior as an optimization. However, you still have to pass all your game data through at least one rendering stage (vertex shaders) before the video card can know what is visible. In something like, say, Skyrim, that would be impractical. Not only do you have to send every vertex in the world through the rendering pipeline, but you have to load every vertex into system/video memory. That's inefficient, if even possible.

So, many games will make use of CPU-based culling. They will typically implement some sort of LOD (level of detail) system, where the quality and existence of assets are impacted by how important they are assessed to be in a given context. A pyramidal mesh might be an acceptable approximation for a mountain if you're 50 miles away from it. If you can't see it at all (like it's blocked by other mountains), there's no need to even load it. There are a number of more complex methods for doing this that are topics I don't feel are directly relevant to the depth requested by this question, but look at tessellation for one of the most common examples.

The real gist of this is that the visuals are only the product of the game. The actual data has nothing directly to do with what you are seeing or not seeing most of the time, and the data is filtered by various stages to remove extraneous information before hitting the point where a picture is written to the screen. Depending on the engine design, visuals can be extremely decoupled from the actual game logic, so far as something like having a 2D and 3D interface to the same game is a possibility. It's even possible for many game engines to run with no output what-so-ever; sometimes this is used to test game AI.

That's where things can get complicated, though. In something simple like a Mario game, it is not too prohibitive to calculate the movement of all enemies in the level, even if they are not visible. In modern contexts, what is happening off-screen is an actual question of serious consideration. If there are multiple entire cities of NPCs, how do you handle how they behave when they are completely culled - like when the player is in a different city? Do you really want to be computing hundreds of NPCs' decisions all the way across the map? The answer is usually no, but the exact approach to accomplish not doing so can vary, and it can have some impacts upon the game.

It's important to note that this is how things work now. The old Mario games themselves were likely programmed in very different ways (I can't speak to the exact ways), given the extreme hardware limitations at the time. The concept of 3D did not exist back then; yet today almost all games, even ones which are entirely 2D, use 3D rendering in some form, even if they don't know they do. Modern video hardware is 3D first, and 2D rendering (at least when it makes use of the hardware properly) merely ignores the 3rd dimension.

Answer 6

To answer your question: video games keep the state of the game world in some abstract data structure that has nothing to do with the screen. This is then rendered to the screen as needed (i.e., depending on where the player is).

Games that use the video RAM directly for state purposes were around in the '80s in the 8-bit, maybe even in the 16-bit era, but unless you are developing for that platform or for some µC which counds its RAM in KB instead of GB, forget about it.

That said, you seem to be very new to everything related to programming, or the question would not have come up. I suggest going at it step by step, programming very easy things first; maybe something that has only textual input/output (simple prompts and all that). To be honest, the time when I did that is around 30 years past, so I have no really good resources for you, but your local library might just be better than the internet to give you a really good start in programming.