   Another n00b question: Loading screens
  Ok, so, I'm in the middle of writing out my design-plan for the game I want to program, and I suddenly realize that I'm going to need the traditional form of transition between Menu-World-Menu implementation: I need loading screens. However, I have not yet seen any tutorials or similar on how to implement a loading screen. Could anyone point me in the right direction, or send me a link to a tutorial or two?Thanks in advance.   
  the reason you haven't found any tutorials is because this is kind of a trivial thing. i think what you really probably need a tutorial on is how to manage your program's state, as in what the program is doing right now and what it will switch to next etc etc.you could google finite state machines and then google around the best way to implement them. if your more wondering how to load assets int your game, then i dunno. it really depends on the game.;  Nope, that's what I was looking for. Thanks.   Yeah, that makes sense. I will try and find them, although I'll probably end up coding my own: it's more like I want concept direction for the programming.Thanks   ;  Well, loading screens aren't completely trivial, since doing it well will require threading.   ;Quote:Original post by TelastynWell, loading screens aren't completely trivial, since doing it well will require threading.Why would a loading screen require threading? You just display the graphics, do what you want to do, then if you have some kind of progress indicator, update it, and remove it when you're done loading. I would avoid multithreading like a plague unless you really already know how to do it well. There are too many things that can go wrong -- prefer pipelining over multithreading unless you are very experienced (i.e. keep everything in one thread and just use state to keep track of what's going on). Spawning a new thread to do something is usually a waste of time anyway (and you have to keep track of the thread get rid of the memory it was using when it's finished, and make sure that it's not still running when you're really through with it).   ;Quote:Original post by nathandelaneQuote:Original post by TelastynWell, loading screens aren't completely trivial, since doing it well will require threading.Why would a loading screen require threading? You just display the graphics, do what you want to do, then if you have some kind of progress indicator, update it, and remove it when you're done loading. I would avoid multithreading like a plague unless you really already know how to do it well. There are too many things that can go wrong -- prefer pipelining over multithreading unless you are very experienced (i.e. keep everything in one thread and just use state to keep track of what's going on). Spawning a new thread to do something is usually a waste of time anyway (and you have to keep track of the thread get rid of the memory it was using when it's finished, and make sure that it's not still running when you're really through with it).It doesn't have to require threading, but it usually does. Loading a map for instance could take a considerable time (A few seconds), and may be difficult to spread over several frames. It's much easier to shove the work in a separate thread and then just render as normal, checking a "progress" variable set by the thread and using that to display a progress bar.   ;  Well a "loading screen" implies that one is in the process of loading content, and most every game today has a separate thread that deals with loading content so the main system isn't reliant on the content to finish loading. really depends on the game and the content being loaded, and of course the programming environment. No need to make an elaborate loading system if you are loading stick figures...   ;Quote:Original post by Evil SteveIt doesn't have to require threading, but it usually does. Loading a map for instance could take a considerable time (A few seconds), and may be difficult to spread over several frames. It's much easier to shove the work in a separate thread and then just render as normal, checking a "progress" variable set by the thread and using that to display a progress bar.That still seems like overkill for most games. Even a bunch of commercial titles don't update loading screens in realtime. A lot just load stuff in predefined chunks (first the map, then the doodads, then the units...), and update the progress bar after each chunk.Darwinia's loading screens with the software raytracer are certainly cool, but they are really pretty unnecessary.   ;Quote:Original post by nathandelaneWhy would a loading screen require threading? How exactly are you going to update the progress indicator (or more importantly, process windows messages) from the middle of a loading function (or map generator, or server connection function)? Especially since those methods shouldn't give a rat's ass about any sort of rendering.Can it be done without? Sometimes.Should most people avoid multithreading? Yeah.My hobby game isn't the most complex thing in the world, but the map generation still runs long enough to require a multithreaded loading screen. Not too difficult to implement. If you're using C#, you could probably just get away with some of the concurrency library bits to do the async loading for you.   ;Quote:Original post by TelastynQuote:Original post by nathandelaneWhy would a loading screen require threading? How exactly are you going to update the progress indicator (or more importantly, process windows messages) from the middle of a loading function (or map generator, or server connection function)? Especially since those methods shouldn't give a rat's ass about any sort of rendering.Notifications to a callback function or class? You need that in the multithreaded case as well if you want to update the loading bar. And if you don't want that, well, then there's no problem in the single-threaded case either.