Skip to main content
gamedev.net
🔒 Locked

Real Time Loading Screen

Started by simotix Jan 23, 2008 at 11:51 AM 4 replies 1k views
Original Post
simotix
simotix
I am looking to make a loading screen that would be done in real time, not a loading screen that would just add 5% after things are added. The way I can see how to do this is to create another thread and then some how find out the file size of the assets. Is this the best way to do so and if so is there a tutorial on somewhere on how to do what I want to do?
stonemetal
stonemetal
Ok so say you have a second thread looking at file size. How does it know where the other thread is in the file? The best way to do it is have your file loading code report how far along it is. You can make that as fine grained as you like.
MJP
MJP
I agree with stonemetal, your best approach is probably to just have your loading thread report it's progress as it goes. With enough sampling points, it should look relatively smooth. Otherwise your option is to interpolate between these sampling points, and that would require you to estimate some sort of "speed" at which assets are loaded and then update the progress bar (or percentage, or whatver) based on the size of assets remaining.
janta
janta
Also I would add that I find totally pointless (end-user wise) to show a progress bar indicating the amount of data that has been loaded so far, if the loading time isn't proportional to the amount of data. I've seen to many progress bar go from 0 to 95% in like ten seconds and then be stuck there for another 2 minutes before eventually completing. I'm interested in knowing how much longer I'm going to have to wait, if it takes 10 seconds to reach 50%, then I want to be able to assume that I'll be done loading in another 10 seconds.

JA
don
don
The progress bar is used to denote how much of the task has been completed - not how long it will take until the entire task is done.

The former is simple to do (which is probably why this method is used so frequently). You just divide the task up into a number of subtasks and then update the position of the progress bar as each subtask completes. The problem mentioned by janta (which pisses me off as well) is because the app developer didn't break task into the appropriate number of subtasks, each of which, ideally, should take approximately the same time to complete. When a subtask takes a larger amount of time to complete the user sees no update on the progress bar and thinks the machine is hung. The subtask finally completes and the progress bar jumps across the screen, denoting that a larger part of the process has completed.

Displaying an indicator as to the amount of time left to complete the task is more difficult since you usually have no guarantee on how long the task will take on any particular machine. Progress bars aren't really the proper way to display timing information - most choose an animated clock face or hour glass, or simply display the estimated time remaining to complete the task.

janta
janta
Quote:
Original post by don
Displaying an indicator as to the amount of time left to complete the task is more difficult since you usually have no guarantee on how long the task will take on any particular machine.

You're right that the total time is machine dependant which is why displaying a timer with a number of seconds remaining would be quite difficult (perhaps an estimate with extrapolation?) but if at east the ammount of time remaining would be *proportionnal* to the ammount of progress bar remaining that would be great. In the context of a game, I think that the ammount (in terms of megabytes, number of objects, etc.) is of no interest to the player. A progress bar should IMHO indicate the relative amount of processing time remaining, not the absolute time (seconds, whatever) remaining.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.