60
\$\begingroup\$

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?

|improve this question
\$\endgroup\$
  • \$\begingroup\$ Comments are not for extended discussion; this conversation has been moved to chat. \$\endgroup\$ – user1430 Mar 8 '18 at 19:02
  • \$\begingroup\$ John Carmack almost invented the approach on PC to do full screen side scrolling by drawing only the thin vertical slice of the screen that has changed. PCs were simply not able to update full screen display fast enough without this technique. He used this on many 2d games in the early 90s such as Commander Keen. Read "Masters of Doom" for more info. \$\endgroup\$ – Ash Apr 4 at 10:30
68
\$\begingroup\$

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.

|improve this answer
\$\endgroup\$
  • 23
    \$\begingroup\$ It's not just old games. At EA, there was a push to reduce laptop battery usage for certain "casual" games, and one technique was to only redraw portions of the screen. You could sometimes see this in The Sims 3 if you left the camera stationary and a sim walked across the screen, there would sometimes be a bug where the redraw wasn't large enough and you'd see pixels left behind in a line across the screen. You just had to move the camera slightly to force a full redraw and the line would disappear. \$\endgroup\$ – Kevin Fee Mar 5 '18 at 16:26
  • 12
    \$\begingroup\$ Very old.. 1994... I feel old now... \$\endgroup\$ – alseether Mar 6 '18 at 8:10
  • 4
    \$\begingroup\$ @alseether old in gaming terms. Remember we went from 8-bit pixel blobs to photo-realism (in pre-rendered cutscenes if not live action) in just 20~30yrs. \$\endgroup\$ – Jared Smith Mar 6 '18 at 18:03
16
\$\begingroup\$

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.

|improve this answer
\$\endgroup\$
  • 7
    \$\begingroup\$ Vector displays don't even obviously have a "frame". \$\endgroup\$ – hobbs Mar 5 '18 at 0:28
  • 2
    \$\begingroup\$ @hobbs Correct, which makes my answer still correct since the answer to "Are all games made by drawing each frame?" is "No, not even all games draw based on frames." \$\endgroup\$ – Sandy Chapman Mar 5 '18 at 19:51
  • 1
    \$\begingroup\$ however, in a deeper sense, the question was about repeatedly drawing all visible items, not just the items that move, and for most vector displays the answer is still "yes" (image storage tube would be an exception) \$\endgroup\$ – szulat Mar 6 '18 at 18:42
  • \$\begingroup\$ @szulat in a way that's true, but to be fair, it still doesn't draw in the gaps where the display is black. It only refreshes the visible items on the screen. I.e. in Asteroids, it's only redrawing the ship and the remaining asteroids on screen. \$\endgroup\$ – Sandy Chapman Mar 6 '18 at 18:45
  • \$\begingroup\$ @SandyChapman and on another level, there is really little difference. a game updates the screen memory or sprites when something changes. otherwise the corresponding part of the display remains static. this is true for both raster and vector systems - “asteroids” handles the screen refresh from the (vector!) screen memory without bothering the cpu, similarly how zx spectrum hardware generates its raster video signal. whether the real or imaginary crt beam is drawing polygons or scanning the screen in a fixed pattern, is secondary. \$\endgroup\$ – szulat Mar 7 '18 at 16:27
11
\$\begingroup\$

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.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Do you have references to support "the graphics processor on your machine will indeed compute each frame from the ground up" ? \$\endgroup\$ – Kromster says support Monica Mar 5 '18 at 4:47
  • \$\begingroup\$ @Kromster: It's mostly an efficiency thing. As each frame might require a full computation, and it's uncertain exactly which parts don't, you would need an expensive calculation to determine exactly what bits could be saved. Even if it would be a net performance improvement, it would lead to inconsistent frame rates. \$\endgroup\$ – MSalters Mar 5 '18 at 10:59
  • \$\begingroup\$ @MSalters the way it is phrased, contradicts many points in many neighbor answers. \$\endgroup\$ – Kromster says support Monica Mar 5 '18 at 11:08
  • \$\begingroup\$ I'd say the statement "the graphics processor on your machine will indeed compute each frame from the ground up" is technically untrue. The GPU computes exactly what you tell it to. If you want it to reuse the previous frame, then it will (indeed, that's its default). Many modern game engines (and even operating system GUIs) do choose to start from scratch (where the previous frame is only shown if the new frame didn't finish rendering in time), but they don't have to. \$\endgroup\$ – Ove Mar 5 '18 at 19:59
  • \$\begingroup\$ I'm not even sure what would constitute a reference for "the screen has to be cleared", but have a reference for how a frame is rendered in Doom: adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study ; don't forget that a moderately high end graphics card should be able to manage a trillion calculations per second, several thousand per pixel. \$\endgroup\$ – pjc50 Mar 5 '18 at 22:30
2
\$\begingroup\$

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.

|improve this answer
\$\endgroup\$
  • 1
    \$\begingroup\$ I remember the game "Golden Axe". When played on 8086 gameplay was slower and much easier to handle than played on 286 for example where things moved faster. Just FYI. \$\endgroup\$ – akostadinov Mar 6 '18 at 11:47
0
\$\begingroup\$

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.

|improve this answer
\$\endgroup\$
  • 1
    \$\begingroup\$ I reached halfway through this answer and I'm not sure how it's actually answering the question. Your first paragraph is talking about CPUs, XY coordinates, electron beams, bytes of memory, and sprites -- but none of this is visibly about drawing each frame. The second paragraph is talking about display patterns at length, and then it loses me. I think you need to take whatever part of this is about actually redrawing the screen, put it up the top in a clear statement, and then connect whatever else you need to talk about back to that to explain what's going on. \$\endgroup\$ – doppelgreener Mar 6 '18 at 20:24
  • 1
    \$\begingroup\$ @doppelgreener: The notion of "drawing" each frame is a bit vague. Something has to do everything necessary to generate each frame, but there are many ways that work may be divided by the CPU and hardware. Some ways require that the CPU be involved on every frame even with parts of the screen that appear the same between one frame and the next, while others don't. While any LCD or CRT game will ultimately require that something output every non-blank frame [games using E-paper or flip-dot displays might not], the actions needed may or may not be considered "drawing". \$\endgroup\$ – supercat Mar 6 '18 at 21:38
  • \$\begingroup\$ I suggest you start at the straightforward language (whether we do "drawing a frame" constantly) and work back from there explaining more technical details around why that might not be an accurate way to put it -- instead of diving straight deep into the details. Your post needs an Executive Summary, basically, and an Introduction, before you start examining things to the depths you do. \$\endgroup\$ – doppelgreener Mar 6 '18 at 21:43
-11
\$\begingroup\$

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.

|improve this answer
\$\endgroup\$
  • 9
    \$\begingroup\$ This doesn't even make sense against the asked question.. I think you have confused "frame" for something else... are you possibly getting confused with elements of a story board? OP is specifically talking about frames in the context of rendering \$\endgroup\$ – Trotski94 Mar 5 '18 at 8:05

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