Are all games made by drawing each frame?

Question

I am a beginner learning about computer animation(for games). So far, the only method that I have come across is drawing each frame, every frame update. So at the start of every frame, the entire frame is erased, and then the things for that are needed that frame are redrawn.

My question is whether or not this method is the only one that is used for making animations and games. It seems like it is a bit inefficient. I also don't quite understand how this method would work for 3d games. Could someone please explain this in more detail?

Answer 1

Very old games used a technique where only those parts of a frame are redrawn that changed on that frame. What I can remember, the game "Little Big Adventure" uses this technique (1994). But you can see that the game has for most of the time a static camera. only when you move out of the visible area the scene is redrawn. If you play the game you would also notice a tiny lag on that frame. On modern GPUs with modern game engines, things have changed. Everything is redrawn on each frame. Depending on the rendering technique, things might even be rendered several times. The computing power of a GPU is just incredibly high when you use it correctly. But reuse is happening. For example an engine could decide to update the shadow map only every 5th frame. Or the lighting is not updated as long as there is no change in the light sources.

Answer 2

No.

At least if you include old games from the 70s which used vector displays.

For example, the widely known game Asteroids, which was originally developed for vector displays which are a fundamentally different way of rendering graphics to a screen.

Vector monitors were also used by some late-1970s to mid-1980s arcade games such as Asteroids, Tempest, and Star Wars. Atariused the term Quadrascan to describe the technology when used in their video game arcades.

https://en.wikipedia.org/wiki/Vector_monitor

Modern day graphics are pretty much 100% made for rasterizaton, which by definition writes the contents of a graphics buffer to the display every frame.

Answer 3

On the lowest level, the graphics processor on your machine will indeed compute each frame from the ground up and send it to your screen. You will only be exposed to this, however, if you manage this low-level stuff yourself [1] Any graphics (and with that, game-) engine however, will handle these things for you, and you are free to express the scene in terms of many entities that you could modify between frames, but will be persistent.

... how this method would work for 3d games ...

The elements in 3D space are persistant, the graphics engine would, again, recompute the image on your screen for any changes that happened (camera movement etc.)

[1] ... for example if you write your own engine [2] with something like OpenGL. Even in that case you would likely store persistent things between frames.

[2] Which is not an option at your current skill level.

Answer 4

Short answer: No.

Long story:

When I learned some game programming in school, we were taught to do the following:

Decide what fps rate we wanted in the game (30 for example).

Write some code that adds 1 to a counter for each interval (33 msec for 30 fps). This code runs concurrently with the game loop.

Then the game loop that does the calculations for the game (game state update) will reduce the same counter by 1 for each frame. But the graphics calculations and drawing to screen will only be done if the counter is at zero.

The outcome is that the graphical frame rate will adjust depending on how well the cpu handles the calculations in game. When not too much is happening in the game, calculations are easy and the graphics frame rate will be higher than the actual game state update (basically wasting cycles since we draw the same game state more than once on screen).

But then a lot is happening in game, the cpu will have more work to do and game state updates will be prioritised over drawing to screen.

Most of the time, the game will keep updating at the intended rate, but will appear "laggy" since you won't see each update on screen. This may be preferrable to the whole game slowing down because you force it do draw each update on the screen.

This was all done with C++ and no game engine, nor graphics card. Everything ran on a single core cpu. We used some libraries for 2d graphics.

Answer 5

Before one can say whether video games "draw" the display every frame, it's first necessary to define what is meant by "draw". There are certainly many video games certainly do not all draw every frame by assembling a bitmap from scratch; indeed, many gaming platforms never assemble full bitmaps at all.

There are a few approaches video games can take to generating a display. A very small number have the CPU turn the electron beam on and off or for every pixel or, for vector-scan games, set the XY coordinate of every dot to be plotted. Most games that do this do so largely for the purpose of demonstrating that the CPU is fast enough. More commonly games will have hardware which, in the absence of CPU involvement, would output some pattern of pixels or vectors to the display repeatedly. This pattern may be produced by reading data sequentially from a region of memory and interpreting each bit or group of bits as a pixel color (this is called a bit-map display). In some cases, hardware may read a byte of memory for each 8x8, 16x16, or other size region of the display and then use that byte to select a range of memory to read for pixel data (this is often called a character-map display). Some hardware platforms can overlay multiple bitmap displays with configurable positions. These are referred to as sprites.

Some platforms do not allow the display pattern to be changed while it is being sent to the screen, but instead require that all updates occur after the beam has finished drawing one frame but before it has started drawing the next. On such platforms, everything that is going to appear on a frame needs to be loaded into the display hardware before the start of that frame, and the display will be limited to showing a pattern that can be set up all at once. If the CPU were to stop running while the frame is being shown, that same frame would keep being shown indefinitely. Other platforms do allow the pattern to be changed or reconfigured while it is being drawn to the screen. This makes it possible to show a screen which is much more complicated than the video circuitry could handle by itself. This may make it possible for a hardware platform which has eight sprites to show a larger number of movable objects by setting the positions of the top eight objects on the screen, waiting for the beam has reached a point somewhere between the bottom of the first object and the top of the ninth, setting the position of the ninth object, waiting for the beam to get between the bottom of the second object and top of the tenth (if it isn't already there), setting the position of the tenth object, etc. Note that this approach would require CPU involvement during every generated frame of video, even if none of the objects visibly move, but the CPU would not be involved with "drawing" each object.

Most personal computer games use hardware configured to draw a single bitmap screen, and then draw onto that screen anything that needs to be different from what's already there. Sometimes it may be easier to draw things without regard for whether it is actually necessary in a particular case, but if code can easily tell that there's no reason for part of the screen to change, performance may be improved by skipping that part. Today's platforms are often fast enough that they could draw the entire screen many times over during the course of a frame, but historically that was not the case. The fastest possible code to write all the pixels on the Apple II computer's high resolution screen, for example, would take more than two frames, and the fastest possible code to copy all of the pixels on the Apple II computer's high resolution screen from another buffer would take twice that. Getting good performance required that games only update things that were actually changing, and that is what good games generally did.

Answer 6

To put it briefly, I would say not all frames are drawn but just the ones required to present your story or theme of game or game-play are. Plus the timing of the things you would want to happen at certain instances would matter.