   loading screen
  I've been reading some old threads on this forum in which people say that you should do all your DirectX calls from the same thread. This is all fine and good, but if you can only call DirectX routines from one thread then how do I do a loading screen?I had spawned a thread that just goes into a sleep, Present() loop and renders a simple progress bar while in the main thread I'm generating textures, loading textures, and so forth. This approach fails randomly: sometimes I run the application and it works fine, other times the progress bar will be garbled, other times nothing appears on the screen -- I'm guessing this is because of unsafe multithreading. So I'm going to rip out this implementation of a loading screen, but what should I replace it with?   
  Hi,I'm not interested with loading screens. But I can give you an idea.Run Fraps software and look FPS data when a game enters "Loading..." loop. You'll see that FPS data changes if and only if the progress bar moves.So, I can say:Suppose you've 50 textures, 20 models and you want to load all of'em, say, in 35 frames. Then, for example, load 2 textures and 1 model per frame. Then make a simple quad with variable width, and render it as a progress bar. Can it be?   ;  Yup, I did something similar as programci_84 suggests.But my load-screen prints the successfully loaded stuff. After every loaded texture/mesh/bunch_of_related_init_stuff the screen prints a new line. Since loading / building resources always will be the bottleneck, this "linear" approach doesn't slow things noticeably (I guess, if it does, still better than sitting and having no idea how the loading procedure goes).   ;  Another option is to do all the rendering from the main thread as usual, and spawn a worker thread to load the resources. The worker thread should read the resources from disk, and convert them if needed (E.g. unpack PNG files into raw pixel data). The main thread can then create the resource, lock it, memcpy() into it, and unlock it (Which shouldn't cause much of a stall).Alternatively, you could have the worker thread signal to the main thread that it needs a resource created (Taking a resource type and dimensions), the main thread can then create and lock the resource, and the worker thread can unpack into that locked pointer, and then signal the main thread which can unlock the resource.   ;  I would go for the first solution. Some drivers show strange behaviors (from a performances point of view) if you hold a lock of a resources over a frame border. To keep your FPS high during this you can add everything that is ready for creation in a queue. For each present you can take entries from this queue until you reached the time limit for the current frame. This works pretty well and the only object that needs to be multithread safe is the queue.   ;  Thanks everyone. I ended up doing it all in a single thread in a very straight-forward manner. I just had to refactor some classes so that for every resource that needs to be loaded/created there's a public function that I can call to do the load. Then in a global LoadResources function, I just call all of these functions, calling an incrementProgBar member function of a LoadingScreen object, after each one. The loading screen object is local to LoadResources() and cleans itself up via RAII. If the project grows this approach might not scale but it works for now.[Edited by - jwezorek on May 17, 2010 1:27:12 PM]