3

I'm from the AS3, JavaScript, and similar "web languages" where loading means the code is being downloaded from the server, and can't run reliably until enough has been fetched to the user's computer.

However, what happens during a loading screen in software and games in which all the information already exists on the user's computer? (especially now that the information can be stored on a "quick to read and write" harddrive, rather than slow floppies or CDs)

Does this differ from the loading pauses that sometimes may occur in the middle of a game?

IQAndreas
  • 2,675

2 Answers2

5

There are several things what a program might process during the loading screen.
Bring primarily an AS3 developer myself, I can surely say that it's not limited to any specific platform in general. AS3 developers need to do it too.

Here's a small list of what a typical app does during the Loading stage:

  • Pre-calculation. A very broad explanation, but usually it's calculating paths for pathfinding, rendering vector graphics into the raster, saving pre-calculated (baked) byte data to a local storage path, loading data from local storage into memory (RAM).
  • Initialization. Larger apps need to create more objects than smaller apps before they can start. It's even slower when some frameworks with large footprint are being used. The application is heavily loaded at that time and isn't responsive. For that reason, it's better to show a loading screen that outputs some info on why the app isn't working yet.
  • Object pooling. Similar to Initialization process, a set of objects that are going to be reused are created. Since there are a lot of these objects, it may take some time to create them all. Better to do that on a loading screen to avoid lag.
  • Downloading external data. Some apps require assets, such as sounds, art, data (text translations, level info, prices etc). If these assets are subject to change or new ones can be added it makes sense to keep them on the server and download them when needed.
  • Garbage collection. Since resources are limited, unused memory needs to be released to create new objects in its place. But garbage collection is a very heavy CPU time-consuming process. Better to do that on a loading screen to avoid lag.

This list is not complete by any means. There are some specifics to each platform, API, programming language even. Just a rule of thumb - if something takes a lot of processing time - put it on the loading screen.

Community
  • 1
Creative Magic
  • 530
  • Do you mean that some applications need garbage collection as soon as startup? – mouviciel Jan 21 '14 at 08:54
  • 1
    Why yes, some do. Maybe they have embedded, downloaded vector art. These object are being created, transformed into raster and the vector objects are being garbage collected. It's not obvious, but some objects exist to be processed and garbage collected right after. Example: high quality vector picture scaled to fit smaller screen. A new instance of the smaller/larger bitmap is generated and the vector object - destroyed. – Creative Magic Jan 21 '14 at 08:58
  • 1
    Garbage collection is definitely not "a very heavy CPU time consuming process" to a degree that it would add noticeable delay to the startup of a game. – Michael Borgwardt Jan 21 '14 at 09:00
  • @MichaelBorgwardt, but you don't want it during game-play, would you? It would spike up the CPU usage and you'd see lag.

    Adding to this - loading screen is not limited to application startup. Any new state of app may need a loading screen and garbage collection is required to remove old assets and load new ones. Like when entering a new level of a game.

     – Creative Magic Jan 21 '14 at 09:03
  • 2
    @Creative Magic: if your system is based on garbage collection, it will happen all the time during gameplay. Modern garbage collectors can spread the load out quite well. But most games are still written mainly in C++ and do manual memory management, so there is no garbage collection at all. – Michael Borgwardt Jan 21 '14 at 09:09
  • "But most games are still written mainly in C++" - is there a source to that information? Many games using popular engines use Garbage collection - unity3d, Flash, OpenFL, cocos2d (the Java one, not cocos2dx) and others.

    Not all apps need garbage collection, it's a developers choice what to do on a loading screen or even if they need a loading screen at all. Downloading external data is also not always the case, some apps need that, some apps don't.

     – Creative Magic Jan 21 '14 at 09:15
  • 2
    @MichaelBorgwardt: In addition to the argument that GCed languages are being used to create games which don't suffer from the typical stopping of the world, there's also the point that "garbage collection" doesn't necessarily mean automatic garbage collection. Your C++ game might decide to do all its memory management on loading screens! – Phoshi Jan 21 '14 at 09:39
  • @CreativeMagic both in managed languages and unmanaged languages used for games, most allocations and deallocations are amortized to ~pointer increment. In C++ this is because most objects have automatic storage duration ("on the stack"), in JVM/.NET the jitter can do similar tricks ("new'd on the stack"), and of the other objects, most die between GC passes. – Caleth May 26 '17 at 09:01
3

Hard-drives are still too slow to run complicated calculations directly off of. When games load, they are pulling information into your memory. As in RAM.

Random Access Memory loads hundreds of times faster then most hard-drives. So when a games is loading, it is puling all the information it'll need off of the hard-drive, formatting it to make it useful for the software to use and storing it in ram.

Unfortunately, most people's RAM is still limited. Only 8gb to maybe 32gb. For some games, that isn't enough to load everything into (especially since your operating system and other programs are using some). The end result: the game only loads some of the information into RAM. When you need more, you get a loading screen.

Damien Black
  • 181
  • 2
    Afaik, some games also decompress datafiles during loading and generate shaders etc. – Juha Untinen Jan 21 '14 at 07:51
  • 1
    I think "hundreds" is a significant understatement when you consider that for any given hard drive read it's highly unlikely you're not going to have to reposition the read head, an action which can take on the order of milliseconds to complete! – Phoshi Jan 21 '14 at 09:37