Archived

This topic is now archived and is closed to further replies.

DevLiquidKnight

What happens during a "loading" screen?

Recommended Posts

Lots of games have them those screens that say "Loading..." I know they load textures and other things. But how exactly do they do this and update a % complete control? I''ve made a few engines in direct3d and it seems like it takes forever to get the application to finish being executed after I execute it i sit there and wait about 5-10 seconds before anything even appears, which is kinda slow so I was wondering how exactly do you make one and use one in a game so that it effectively displays a screen but allows the user to know whats going on as it loads. It may be a stupid question but just wondering

Share this post


Link to post
Share on other sites
You''ve been duped. The only purpose of the "loading" screen is to give the player suspense - no loading is ever actually involved since loading is always instantaneous. All those screens are doing is updating the % bar with some sleeps in between inside a for loop. The really clever ones try to make you think its actually loading something by writing (which isn''t instantaneous) bits of random information to the hard drive, then deleting it just before they decide to launch into the game. The length of time a game stays in the loading screen is completely arbitrary, but most designers seem to follow a pattern of making the duration proportional to the likelyhood of the player being killed in the next screen. This adds to the suspense as the player must reload his last save game and wait excitedly during the "loading" screen.

Share this post


Link to post
Share on other sites
Hi!

Like Manip said, you could use multi-threading, but I''d do it different (in fact, I know quite alot of games that do it this way, IL-2 Sturmovik, to name one). I''d go and define steps. For example, when the world is loaded, the loading is 30% done. You then interrupt the loading and update the loading screen to 30%. Then, when the next thing is loaded (for example, the vehicles), update the loading screen to 50%, and so on.

I''ve never done that, but as I said, this is the way I''d do it. Hope it helps!

cya,
Drag0n

-----------------------------
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning..." -- Rich Cook

Share this post


Link to post
Share on other sites
i doubt professional games do what doc says
loading is not instantaneous

instead of a loop you do this

// draw loading screen with 0% bar
// load a file
// redraw bar at 2%
// load a file
// redraw bar at 8%
// etc...

so if your using d3d you would end up calling IDirect3DDevice9::Clear and IDirect3DDevice9:resent after every time you load one, two, or more files to update the bar

you could even take the total number of files needed to load and calculate the percentage that way

Share this post


Link to post
Share on other sites
What Doc is saying is complete rubbish. As a programmer you should know it might take some time to load the maps, models, textures, script actions, etc.

These aren''t loaded into memory directly by opening the file or something. They require time to be opened, loaded into memory and then parsed into the correct memory format. Or do zip files unpack instantly and the progress bar is there because the programmer of the zip app likes to waste precious time on developing an progress dialog so it can waste the time of the user? Haha, funny man!

Back to thread:
Usually during the loading screen an extra thread is fired off which reads the files into memory and parses those. For each file it writes to nPercentage = nNewPercentage. As long as the boolean "Loading" is set to true, the load screen updates itself. When the value of loading is set to false, the thread kills itself and then the load screen jumps over into the menu/game.

Toolmaker



-Earth is 98% full. Please delete anybody you can.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What I''ve done is find the size of all the files at the beginning of the load and as each file is read in I update the bar by the appropriate percentage.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If any of you did take Doc''s post seriously, the joke''s on YOU! It was quite funny, actually.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You bank account is being hacked... they just put that screen up so you don''t get suspicious.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Doc
You''ve been duped. The only purpose of the "loading" screen is to give the player suspense - no loading is ever actually involved since loading is always instantaneous. All those screens are doing is updating the % bar with some sleeps in between inside a for loop. The really clever ones try to make you think its actually loading something by writing (which isn''t instantaneous) bits of random information to the hard drive, then deleting it just before they decide to launch into the game. The length of time a game stays in the loading screen is completely arbitrary, but most designers seem to follow a pattern of making the duration proportional to the likelyhood of the player being killed in the next screen. This adds to the suspense as the player must reload his last save game and wait excitedly during the "loading" screen.


This is True! RTCW ''accidently'' forgot to do the load time for the save games and the game loaded instantaneously!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by eFoDay
i doubt professional games do what doc says
loading is not instantaneous

instead of a loop you do this

// draw loading screen with 0% bar
// load a file
// redraw bar at 2%
// load a file
// redraw bar at 8%
// etc...




Actually, I was writing an article to this effect loading using an iterative state machine.

Basically, to keep the game from freezing up the processor, I would call a single iteration of each loop and then return.

The advantage is the updating of the progress bar and not dead locking the system (a common problem with large iterative or while loops).

The disadvantage is longer load times. Some developers counter this by loading all of their resources at once in a huge file and read large chunks each iteration.

The problem is that this method requires a known memory size, but adds an advantage of easier memory use and defragmentation. This brings me to console apps.

This is pretty much the loading technique of consoles. The advantage of a console is the lack of other programs that require processor time. This means that the load screen doesn''t even have return control to the OS for any length of time.

This whole disussion leads into memory managers.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Yeah, doc''s totally right!

Same''s true for downloading stuff from the internet!!!
If you download a 500 MBs demo, "the mysterious they" just make you wait 5 hours out of pure evil minded malevolence! oh, and to raise the suspense, of course...

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
If any of you did take Doc''s post seriously, the joke''s on YOU! It was quite funny, actually.


Although we did actually consider it for our last project because the load was too fast.

Normally its done by multi-threading but there are other options. You could have a script of files that need loading and update the progress bar inbetween.

Share this post


Link to post
Share on other sites
1. Calculate the total size of the files needed to be loaded.
2. Calculate the percentage of each of the file''s sizes in the total size.
3. Pass the list of files to be loaded to the resource manager (or just load them one by one in the loading screen code)
4. After each resource is loaded update the loading bar and flip / swap buffers.

That''s just one way to do it.

Share this post


Link to post
Share on other sites
As the other posters said, updating the screen and user interface is usually handled by multithreading.

It seems like a lot of games sort of fake the load screen since getting an accurate percentage of how far along the load proccess is isn''t easy. Obviously there isn''t an intentional delay, but any sort of percentage you see is almost always a very very vague approximation of how far along it actually is, which is why in a lot of games you see the load bar get to 25%, and then all of the sudden jump to the finished state or whatnot.

----------------------------------------
"Before criticizing someone, walk a mile in their shoes.
Then, when you do criticize them, you will be a mile away and have their shoes." -- Deep Thoughts
"If you have any trouble sounding condescending, find a Unix user to show you how it''s done." - Scott Adams
FaceHat Software -- Wear the hat.

Share this post


Link to post
Share on other sites
quote:
Original post by The Senshi
It seems like a lot of games sort of fake the load screen since getting an accurate percentage of how far along the load proccess is isn''t easy.
Or important.

The quickest thing to do is to increment in fixed steps for each resource loaded. If you have 1000 resources to load, you increment by 1% ever 10 resources. Setting this up is trivial, and it yields a fairly smooth progress bar.

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
quote:
Original post by The Senshi
It seems like a lot of games sort of fake the load screen since getting an accurate percentage of how far along the load proccess is isn''t easy.
Or important.

The quickest thing to do is to increment in fixed steps for each resource loaded. If you have 1000 resources to load, you increment by 1% ever 10 resources. Setting this up is trivial, and it yields a fairly smooth progress bar.


Only if all the files are of a similar size.

Share this post


Link to post
Share on other sites
quote:
Original post by Doc
You''ve been duped. The only purpose of the "loading" screen is to give the player suspense - no loading is ever actually involved since loading is always instantaneous. All those screens are doing is updating the % bar with some sleeps in between inside a for loop. The really clever ones try to make you think its actually loading something by writing (which isn''t instantaneous) bits of random information to the hard drive, then deleting it just before they decide to launch into the game. The length of time a game stays in the loading screen is completely arbitrary, but most designers seem to follow a pattern of making the duration proportional to the likelyhood of the player being killed in the next screen. This adds to the suspense as the player must reload his last save game and wait excitedly during the "loading" screen.


HAHA, i did that once for a school assignment once in grade 12. The best thing was that it got slower and slower as the progress bar approched 100%. However, my teacher put a not on my assignment saying that if i do that again i will get docked marks

Anyway, there have been lots of good suggestions on how to solve this problem. If you havent picked on yet then just take the one that you think will be easiest to implement.

Share this post


Link to post
Share on other sites
quote:
Original post by Kafeen
Only if all the files are of a similar size.
You missed the point. Perfectly proportional advancement is unimportant (and who''s to say that percentage of resource files loaded isn''t a valid measure) and too much work for no benefit. The sole purpose of a progress bar is to assure the user the program has not crashed and that entertainment is imminent. Some implementations of the progress bar augument the percentage count/bar with text indicating what category of resource is being loaded.

Go for the 90% solution.

Share this post


Link to post
Share on other sites
It''s probably worth doing a little profiling on the progress bar. Have it write out a timestamp to a file showing how quick it loads the different resources. Then you can calibrate the control so that it''s roughly evenly paced.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Share this post


Link to post
Share on other sites
Since I have my data pre-processed in a single file, ("Fast Data Load Trick", from one of the Game Programming Gems books) loading is pretty much just reading things into straight memory and performing trivial processing on them. This way my progress bar is incremented proportionally to the where in the file it''s reading from.

Is multi-threading really necessary for this? I just call the drawing routine periodically during the load. MT would be more useful for background loading, which may be used in games if you have an expansive terrain or use network streaming.

Tom

Share this post


Link to post
Share on other sites
quote:
Original post by Doc
You''ve been duped. The only purpose of the "loading" screen is to give the player suspense - no loading is ever actually involved since loading is always instantaneous. All those screens are doing is updating the % bar with some sleeps in between inside a for loop. The really clever ones try to make you think its actually loading something by writing (which isn''t instantaneous) bits of random information to the hard drive, then deleting it just before they decide to launch into the game. The length of time a game stays in the loading screen is completely arbitrary, but most designers seem to follow a pattern of making the duration proportional to the likelyhood of the player being killed in the next screen. This adds to the suspense as the player must reload his last save game and wait excitedly during the "loading" screen.


[ offtopic ]
I suppose this could contain some merit.

An extended load time (especially for a particularly difficult section) could increase suspense and increase the perceived difficulty of the section - and hence, increase the reward the player feels upon finally completing it.

Of course, long loading times often tend to get picked out by gaming reviewers. Maybe give the player something fun to do while loading?
[ /offtopic ]

Share this post


Link to post
Share on other sites