I was wondering how others manage loading their large system data
(images, etc), while displaying a progress bar?
I understand that I cannot load images in a thread other than the
initial SDL main process, so I am at a loss as to how I can update
a progress bar and still separately load image data.
Well, I think you could, if you have a global lock or something that
must be held while using SDL surface manipulation calls from anywhere
in your code while loading. (Which basically means it affects only
the loader and the rendering code that’s used while loading.)
solution I could think of was to load a single image every loop,
until all are loaded.
That’s what I do in Kobo Deluxe, and I think that’s the most common
solution. It’s simple and robust, though the code gets ugly if you
don’t have some kind of loading subsystem you can hook into…
As it is, loading is just a long list of calls, with progress(…);
calls in between each operation. If that part of the graphics engine
was slightly more sophisticated, I could just send it a list of files
and parameters, and the progress bar would be driven through a
callback from a loop somewhere inside the engine instead.
With a centralized approach like that, one could record the loading
time in some file to make the progress bar more accurate for
subsequent loads, and that sort of stuff.
That would of course work fine, but I’d like
a nice generalised system where I didn’t have to have code that
tracks which item I’m up to loading.
You could try wrapping the relevant SDL calls with something that uses
a global lock to make sure that only one thread at a time is using
those calls. That way you can at least have the loader thread use s/w
blitters and stuff like that, while the main loop updates the
progress bar a few times a second or so.
Of course, there’s no way to avoid that progress logic, but at least,
this would avoid having the loader actually drive the progress bar
However, it would be much easier to just have those SDL call wrappers
update the progress bar directly, and run the loader in the main
It doesn’t really make a difference how you implement it, since you
can’t get “fractional file” resolution without explicit support in
the loader anyway.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 31 May 2004 00.33, Rob Sadedin wrote: