Re: [GD-General] worker threads, level loading and progress bars

[Javier A. <ja...@py...>]

My approach has always been to have a global subsystem with the following
API:

ProgressBar::Init()
ProgressBar::StartSection(percent, numTicks)
ProgressBar::Progress()
   which calls ProgressBar::Render()

Then spread calls to Progress() around the calls that load stuff. This is
probably the callback mechanism Ignacio mentioned, but I don't like the idea
of passing the "ProgressCallback" object around these calls - it makes the
API uglier without need.

Proper adjustment of the "percent" and "numTicks" of each section for each
level, can make it quite smooth. (Log times and number of actual calls, for
each level load, then put those into the config file, log again to check and
you're set). Advancing the progress bar based on some realtime clock will
give you trouble.

Render() decides if it's a good time to update the visual progress bar
depending on how frequently do you . (Note: when optimizing load times on
"Commandos: Beyond The Call Of Duty", this one showed up as taking 50% of
the load time - it wasn't being smart about when to update and was causing
1000's of PageFlip()s)

This system is terribly simple, doesn't require any fancy technologies, plus
it doesn't bind knowledge of the internals of any subsystem to any other, so
it's architecturaly as clean as you can get. Fancy solutions like
multithreading may be more interesting but are so much less practical in all
respects...

If you want a console-style continuously animated progress bar then you need
either more calls to Progress() or a secondary thread. The single-threaded
approach may be slightly less efficient, but much easier and safer to
implement.

Thatcher Ulrich <tu...@tu...> wrote:
> I took a stab at this (loading in a background thread) in Soul Ride.
> In Win32, it's pretty easy to set up a new OpenGL render context, and
> use wglShareLists() so that textures defined in one thread are usable
> in the other thread.
>
> In captivity it worked, pretty well in fact.  But at the time
> (early/mid 2000, IIRC) it was highly vulnerable to bugs in driver
> thread support, so I gave up and fell back on the DoWork() pattern.
>
> Under X, there seems to be a way to share textures across threads, but
> I never got around to trying it.  Nowadays I try to use SDL for all
> video setup & config, and it does not have a facility like
> wglShareLists :(
>
> The worker queue thing works as well; my Chunked LOD demo uses this
> pattern -- I load the image data in the loader thread, and bind it in
> the foreground thread.  But it still means some extra, unnecessary
> work for the foreground thread; plus the coding work.
>
> -Thatcher
>
> On Aug 07, 2002 at 04:44 +0200, Ignacio Casta?o wrote:
>> Hmm... it seems to my now, that the problem with the multiple
>> threads could be easily solved.
>>
>> The only OpenGL operation performed by the worker thread is to upload
>> textures, so my texture manager could have a list of textures
>> waiting to be uploaded, and I could process them on each game loop.
>>
>> Anyway, I still would like to hear how others have solve this
>> problem.
>>
>>
>> Ignacio Casta?o
>> cas...@ya...
>>
>>
>> Ignacio Casta?o wrote:
>>> Hi,
>>> to display a progress bar during the level loads, I've always used
>>> somekind of callback mechanism, or a simple 'DoWork' function that
>>> performs a little part of the work in each call and returns a
>>> special value when the work has been finished. Those approaches
>>> worked ok, but the progress of the bar wasn't smooth and the
>>> resulting code was not very clean: ...
>>
>>
>> _______________________________________________________________
>> Copa del Mundo de la FIFA 2002
>> El ?nico lugar de Internet con v?deos de los 64 partidos.
>> ?Ap?ntante ya! en http://fifaworldcup.yahoo.com/fc/es/
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Gamedevlists-general mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557


  Javier Arevalo
  Pyro Studios