Oddly, I just got done implementing a progress control in my windowing UI, so...

The easiest way to do it is to draw two rectangles; one for the progress control box, and one for the actual meter.

The outer rectangle is your "control" that contains the meter.

You'll need a "position" value. Clamp it to the range 0.0f to 1.0f (I'll show why in a sec).

The second rectangle should be the same size or close to the same size as the first box. This is your actual progress meter. Draw this inner box inside of the original box. Here's where the clamped position value comes in. To easily do the inner box, use glScalef and set the x parameter of the call as your position value. This will grow the box horizontally as the position value counts up to 1.0f

You'll end up with something like the following ProgrammerArt(tm):

0.0f+----------------------+|                      ||                      ||                      |+----------------------+0.25f+----------------------+| +-----+              || |     |              || +-----+              |+----------------------+0.5f+----------------------+| +----------+         || |          |         || +----------+         |+----------------------+0.75f+----------------------+| +---------------+    || |               |    || +---------------+    |+----------------------+1.0f+----------------------+| +------------------+ || |                  | || +------------------+ |+----------------------+

And for some code (untested and uncompiled...):



Now for the obligatory warnings... the position must never be outside of the range 0.0f to 1.0f. If it's less than 0.0f, the inner box will spread to the left of the container box. If it's larger than 1.0f, the inner box will extend past the right side of the container box.

Hope that works out for you. The one I did was a lot more complicated, but that's essentially what I started with as a proof of concept.

Good luck!

vr

I don't think his problem lies in drawing the progress bar; anyone could do that.

I think his problem is in knowing when stuff is being updated behind the scenes so he knows when and how to update the progress bar.

In my game, I just load the font I'll need, and then start drawing the loading screen; to update my progress bar, I have a method which forces a redraw and adds onto the progress bar percentage. I call this method after each "step." So my code would look something like this (albeit a lot cleaner, and probably in a ton more classes without global variables):
You could probably make this more fine grained inside your initialization functions if you wanted to make the progress bar more smooth and accurate; mine is sort of choppy but it's to be expected.

Stuff only disappears from your window once you 'present' over it, so you can afford to render to it only so often.

You have to do some work before you can put up the loading screen (such as loading fonts and such) and then you can do the actual loading and present the new frames of the loading screen when you have time.

To make sure I understand the question, do you want to know how to sectionalize your game so you could have, for instance, a loading screen followed by an intro screen and then the game? I use structures of function pointers for that (if you want to see code, let me know and I'll post some.)

Much like medevilenemy, I track the position of the progress bar by how much I've done divided by how much I need to do, and update it as I go along.

Usually, I end up with something like this:

int tot_step = 43;
int cur_step = 0;

// do something
cur_step++;

// do something
cur_step++;

On each update frame, I then set the position of the progress bar to cur_step/(float)tot_step.

vr

Idea: grab the size of each stuff you are loading and calculate the progress using it, instead of number of things to load. You will avoid that kind of loading that takes 10 seconds before 30% and then load the rest in less than half a second.

Size doesn't always relate directly to the amount of time is required to load something. Sure, loading the actual data is size-based, but a lot of data needs processed, which is a step that can add significantly to the amount of time required to load a particular resource. For example, creating the graph to use for navigation when loading map data. It's not always practical to precompute those, and it's not always possible to predict exactly how complicated the graph will turn out [to predict how long it will take to generate].

Good news is that people won't generally fault you for your loading bar being a bit jerky, since these things are generally understood.