## Recommended Posts

##### Share on other sites
I'ld create another thread which were loading the data. Then when it's done loading it'ld set a bool variable to true and close itself, and when the first(rendering) thread sees that this flag has been set it'll go on to the menu screen(or whatever you need after the loading screen).

##### Share on other sites
Firstly have you ever seen a loading screen with smooth refresh? I haven't. Every load screen I know of (ok not every, but 95% of them anyway) jitter up in huge jumps and don't really give you any acurate feedback. BF1942 had a habbit of getting 95% complete in 5 seconds then sitting there for another 3 mins doing nothing in particular, and I think it was Tribes Vengance did the opposite - it would get to about 50% really slowly then suddenly finished. If you get something like fraps which tells you the framerate you'll see that most of them are only redrawn once or twice a second if that.

##### Share on other sites
The loading system I saw for PS2 (where you can't do threads) basically did what the AP suggested. Each loadable item was split into small chunks. Then an OO-version would be:
class LoadableObject{StartLoad();ContinueLoad();EndLoad();}
So the first method did the initilisation, then ContinueLoad would load a small amount of data and finally EndLoad did any tidying.

##### Share on other sites
Quote:
 Original post by d000hgThe loading system I saw for PS2 (where you can't do threads) basically did what the AP suggested. Each loadable item was split into small chunks.

The actual data itself wasn't split into seperate files though (which I think was what the AP wasn't happy with). You just load your one mesh file till either its finished or you've reached your time limit then just pause while loading screen updates then continue loading. So your while loop might looke something like:

while ((pos < fsize) && (time < MAX_LOAD_TIME)){   ... loading code ...}// if we've finished loading say soif (pos >= fsize)   return 1;else if (time >= MAX_LOAD_TIME)   return 0; // still need more loadingelse   return -1; // error or something

so you just keep calling this while rendering the loading screen every time it returns. When you get 1 you move onto your next model till your done. Personally I havent' bothered, but if your loading very large files (which I'm not) then its definatly a good option and much simpler than a second thread.

##### Share on other sites
To have it load smoothly, you're going to have to split the process into two different threads. One thread would be responsible for loading the data and outputing the status of what it's loading while the other would be responsible for displaying the status of the background process. If you have access to the .NET framework, you'll be using the System.Threading namespace.

##### Share on other sites
As already said - you don't need threads for this. But it's prabably easier to use them then rewrite how every different file type is loaded. Because the jobs of the two threads don't need to be related at all, you can escape all the nasty side of multithreaded programming.

##### Share on other sites
From a UI feedback point of view, I think I would argue that a jerky progress meter is actually BETTER than a very smooth one, particularly with long loads (e.g. 20+ seconds). No progress meters are ever continuous, and by now users have been conditioned to expect the jumping. Furthermore, they can hear the hard drive clicking away, and when the progress bar is tied to that clicking it provides a level of reinforcement (yes, this is really doing something, please be patient) that a calmly scrolling bar in the face of intermittent HD activitiy does not have.

It is a problem when games decide that they will assign each file a percentage of the progress bar (20 files, so each one is 5% right?), then load 95% of them in 4% of the time and sit there for 30 seconds without changing. I think it's important to identify which files take longer to load (file size alone may be enough) and assign them larger percentages. It's also important to make sure that the progress bar is never still for more than 5-10 seconds, to reassure people that nothing has frozen.

I've seen some programs (compression and installation programs, for example) that actually use two progress bars - one for the "total progress," and one for the processing of the current file after it's been loaded into memory (like when the program is creating a BSP or unencrypting or whatever). I always thought that that was a particularly effictive bit of UI.

##### Share on other sites
Quote:
 Original post by d000hgBecause the jobs of the two threads don't need to be related at all

Actually they do definatly need to be linked. How do you know what percentage to display if they aren't related at all? Thats also a problem in general that sometimes different things will load at different speeds on different machines. The first time you load a level the IO might be slowest, but then next time its already cached so the IO is pretty quick and its the BSP creator thats slower. So if you've said 50% is IO and 50% is bsp creation then on two different runs of your program the meter will move differently (first time 1st half will be slower, 2nd time 2nd half will be slower). You'll never be able to acuratly say how much of the loading is complete - a good guess is all you have which is why I've never bothered to split up loading into chunks or create another thread. Even if I do all that I still have to just 'best guess' at how much time each section takes so I don't thing you gain anything.

##### Share on other sites
I use threads, and while it can be tricky, I think it is worth it, because if you ever decide you want to stream data in without a loading screen, you can. This is useful to have large continuous worlds without breaking it up every few steps to load the next area. Also, nobody says you really need a percent done indicator on your loading screen. A lot of games don't have them, and really, all you need is some animation to show the program hasn't crashed.

tj963

##### Share on other sites

I have never done threads (haha I need to start learning lol) but I would think using two threads is the best way to go.

##### Share on other sites
Quote:
 Original post by Vern777Well can you use a singleton object that handles the menu loading and refreshing?

Why a singleton? A normal object works just as well (IMHO: alot better), there is absolutely nothing that the singleton will solve in this matter. The problem is to know how much you've loaded and how much is left, as well as render every once in a while.

What I can't really figure out is, how do you know how much is left? Do you insert some extra info in the beginning of the main load file or do you go through the list of all things that need to be loaded, or how do you guys do it?

##### Share on other sites
I posted without much thinking.

But my idea is that you may have different loading code so you can call the singleton object from anywhere. But usually all your loading code belong in the same place...

So you have a loop, you know how many times to loop perhaps, or you know how many vertices you need to load, that would figure into you percentage equation...

##### Share on other sites
Rant! hehe I made it small so you can ignore it:
The singleton is the most misunderstood and missused pattern of all, it has become a "argh I'm to tired to design, let's just make this work!" pattern suddenly. It holds no advantage over being passed around like any other object you need to use. Unless you're force fitting it into something who's architecture / interface you can't / don't want to affect to much. Thus sneaking in a black-box communication system that there is no indication of that's it being used. To give an example of what I mean:

Which one uses the singleton (i.e. which one doesn't hint about using a loading bar?) and which one shows not just to the caller but the implementor of scene.load() that there's a loading bar and it should be used?

I've been thinking about "how do you know how big a step is?". Clearly there are differences in loading times, even for the same object made twice in a row or on two different computers (as pointed out by other posters). So there isn't even a point trying to make one object "worth more" than another. But if we (say 3D game) count triangles or models, when saving the game map this data is saved in a header part (i.e. in the beginning). Then you'd know how much to step after each modell. Other resources like sound and textures has to be taken into account too, of course. Easiest might just be having a "Total resources: 432" in the beginning and a small texture counts as much as a complex model. As mentioned earlier, we've almost come to expect jerky loading bars :)

I'm just speculating here. Has anyone tried this approach?

##### Share on other sites
Here is one approach you can try to make a smooth progress bar.

You need to know a few things about the machine that your app is running on:
1. The amount of data that you are going to be loading, in bytes for example
3. A timer source (eg. in milliseconds)

The gist of this is to do an animation of the progress bar by calculating, on the fly, the spead at which the data is loading.

You can load the first chunk of data and figure out how long it took, and how many bytes were loaded. From this you can calculate the spead (bytes per millisecond, or what ever units you like).

Now that you know the spead at which your data is loading, you can do two things. If you assume that the rest of the data will load with a similar speed, then you can use the calculated spead to animate the progress bar. If not, then you can redo this calculation after each chunk of data is loaded.

To animate the progress bar, you smoothly interpolate it based on how much calculated time is left to load the remainder of the data.

If the platform that you are running your app on blocks during disk IO then you can either take the approach of using theads, or you can try to load data a byte or a few bytes at a time, do your progress bar calculations, and then continue on in a loop. If you write some library routines for doing your disk IO, then try incorporating this sort of progress bar functionality, and perhaps make it configurable for the times when you don't want the overhead of this kind of functionality.

Terry

##### Share on other sites
Quote:

That's not what I meant.

for(int i = 0; i < totalNumOfItems; i++)
{

}

{

//figure out how much each loop is worth in the total progress
//of this item pertange while. So if you have 100 vertes, 1 vert would
//be 1 % on the progress bar
for(int i = 0; i < numOfVerts; i++)
{

}

}

##### Share on other sites

What if I want to traverse a tree and update the progress of my tree traversal I would so something similar maybe.

I'm in no way an expert...

Hope this helps.

##### Share on other sites
Im kinda of partial to those loading messages, definately a good idea :-) Also as posted above is alot of help with debugging.

##### Share on other sites
The singleton pattern does not fit this problem-space well. In order to use a singleton the object:

a) Needs to enforce a single instance.
b) Needs to have global access from the full program.

I would never use a singleton for this problem because it doesn't satisfy the two requirements to use the pattern... it actually doesn't satisfy either of them.

##### Share on other sites
It won’t be a linear progress bar but it will be accurate which is more important.
Another bonus is as multi core processors is coming the loading and decoding of data can be very efficient. Since I’m also using .Net the threading support should be sufficient for this layout I hope. But I may also be over my head here.

My to cents.

Jarle

##### Share on other sites
Although the idea of a background loading thread is quite cool, and probably a good way, properly optimized, to eliminate loading screens as much as possible, if you want to avoid using multiple threads, I'd recommend using coroutines.

##### Share on other sites
Quote:
Original post by kaysik
Quote:
 Original post by d000hgBecause the jobs of the two threads don't need to be related at all

Actually they do definatly need to be linked. How do you know what percentage to display if they aren't related at all? Thats also a problem in general that sometimes different things will load at different speeds on different machines. The first time you load a level the IO might be slowest, but then next time its already cached so the IO is pretty quick and its the BSP creator thats slower. So if you've said 50% is IO and 50% is bsp creation then on two different runs of your program the meter will move differently (first time 1st half will be slower, 2nd time 2nd half will be slower). You'll never be able to acuratly say how much of the loading is complete - a good guess is all you have which is why I've never bothered to split up loading into chunks or create another thread. Even if I do all that I still have to just 'best guess' at how much time each section takes so I don't thing you gain anything.
I don't show a % complete, I just show a repeating animation (a bit like on the KnightRider car) to show something is happening. But even if I did, it's not much data overlap and probably not the kind which can cause problems. Either way it's simple as multithreaded applications go!

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628378
• Total Posts
2982347

• 10
• 9
• 15
• 24
• 11