Animated Loading Screen while Loading Game

[ItsYaBoiWesley]

Hi everyone! Coding question incoming...

I have a number of loading functions (asset loading, world generation, things like that) and I want to have a loading screen running while loading. Something like a loading spinner or progress bar. But here's the thing, I understand JavaScript is single-threaded. So, how do I do simultaneous visuals and loading? Is there some way to run both tasks in parallel? Can I somehow create a CSS loading spinner and overlay it onto my JS canavs? (I have no experience with CSS) 

Thanks!

-Wesley

[ItsYaBoiWesley]

Sorry, hate to bump posts... But does anyone have any idea how to do this?

[DrSnuggles]

Good that you bumped it.
Have a look here: https://github.com/DrSnuggles/Decruncher/tree/ldr

This was first intended for showing the decrunching process in Amiga style but then i made this branch to also show the loading process.
The display is not a fancy spinner more a oldskool interlace lined data display but it's canvas and should help you.

[mattstyles]

On paper, the easy way is to load a tiny JS script, totally decoupled from your main application, and have that power a loading screen. However, as you mentioned, the whole single-threaded thing will typically cause jank, often not too much (depending how exactly you are loading things) but sometimes an unacceptable amount.

Just search for CSS loading spinner, such as https://loading.io/css/, then copy-paste one you like if you don't want to create one yourself. Unless your target market is a browser many many many years old, CSS animations get their own thread well away from JS, so they won't jank.

You can use JS to control CSS animations or transitions to do a progress bar if you want. The CSS transition that moves the element (or resizes it) will be jank-free and you won't notice when JS is blocked to control that CSS as a loading progress bar is not expected to be smooth anyway.

You can even go all fancy and stuff and dump loading in to a web worker, which kind-of gets its own thread, so your main thread can do the animation, which is pretty normal for non-JS platforms. However, depending on what you're doing, this won't always work anyway. Plus, its taking a sledgehammer to stick a tack in the wall. But, it is _an_ option.

I don't think the above answer solves your problem, apologies if I'm wrong but, having poked through the code, it looks all JS powered and will be susceptible to block-jank.

Also, be aware, your loading operations will be mostly asynchronous (unless you've really mucked things up), you might do some synchronous work to manage the asset after load, but, typically that is a tiny bit of work (edit: oh, you mention world gen, yeah, that'll block things up).

Also also, try it under typical conditions. Depending on your visual style, a little bit of jank in a loading screen is often acceptable to a user. The real trick, of course, is to work out a way you don't need that loading screen at all, and, if you can't, make it absolutely as short as it can possibly be.

A trick for world gen (again, this sounds like overkill most of the time), or any long-running task, can be to use generator functions and then bail out every 16ms of so to let stuff animating actually animate to 60fps. As crazy as this sounds, React (a popular front-end rendering library) has a scheduler now that basically does this very thing (its called Fiber and I don't think it doesn't use generators, but the architecture and theory is the same to the concept above of 'bailing' out occasionally). I've done this with line-of-sight operations, but, it quickly proved more trouble than it was worth. Still, it is _another_ option.

[ItsYaBoiWesley]

On 5/10/2019 at 6:16 PM, mattstyles said:

On paper, the easy way is to load a tiny JS script, totally decoupled from your main application, and have that power a loading screen. However, as you mentioned, the whole single-threaded thing will typically cause jank, often not too much (depending how exactly you are loading things) but sometimes an unacceptable amount.

Just search for CSS loading spinner, such as https://loading.io/css/, then copy-paste one you like if you don't want to create one yourself. Unless your target market is a browser many many many years old, CSS animations get their own thread well away from JS, so they won't jank.

You can use JS to control CSS animations or transitions to do a progress bar if you want. The CSS transition that moves the element (or resizes it) will be jank-free and you won't notice when JS is blocked to control that CSS as a loading progress bar is not expected to be smooth anyway.

You can even go all fancy and stuff and dump loading in to a web worker, which kind-of gets its own thread, so your main thread can do the animation, which is pretty normal for non-JS platforms. However, depending on what you're doing, this won't always work anyway. Plus, its taking a sledgehammer to stick a tack in the wall. But, it is _an_ option.

I don't think the above answer solves your problem, apologies if I'm wrong but, having poked through the code, it looks all JS powered and will be susceptible to block-jank.

Also, be aware, your loading operations will be mostly asynchronous (unless you've really mucked things up), you might do some synchronous work to manage the asset after load, but, typically that is a tiny bit of work (edit: oh, you mention world gen, yeah, that'll block things up).

Also also, try it under typical conditions. Depending on your visual style, a little bit of jank in a loading screen is often acceptable to a user. The real trick, of course, is to work out a way you don't need that loading screen at all, and, if you can't, make it absolutely as short as it can possibly be.

A trick for world gen (again, this sounds like overkill most of the time), or any long-running task, can be to use generator functions and then bail out every 16ms of so to let stuff animating actually animate to 60fps. As crazy as this sounds, React (a popular front-end rendering library) has a scheduler now that basically does this very thing (its called Fiber and I don't think it doesn't use generators, but the architecture and theory is the same to the concept above of 'bailing' out occasionally). I've done this with line-of-sight operations, but, it quickly proved more trouble than it was worth. Still, it is _another_ option.

I'm going to do a CSS spinner.

I know this is a stupid question, but how does one overly such a spinner on top of an HTML5 canvas? That's where my game is. And how do you control it with JS

[mattstyles]

8 hours ago, ItsYaBoiWesley said:

I know this is a stupid question, but how does one overly such a spinner on top of an HTML5 canvas?

Not a stupid question! 

This is the web and JS so there are, of course, multiple ways of skinning this cat.

https://codepen.io/personalurban/pen/dBQQaK here is one way I knocked up.

Its a canvas element on the page, with the spinner element also in the DOM. The order of the DOM dictates rendering order, but you could apply z-index via CSS if your DOM structure was different.

The CSS is copy-pasted from https://projects.lukehaas.me/css-loaders/ after a brief google search for CSS spinners, there must be several thousand of these such sites.

I've used a couple of set timeouts, down the bottom of the JS file, to control the loading spinner. After a set amount of time I've applied a class to fade it out, then, using a different timeout I've removed it from the DOM. You don't need the fade if you don't want it. You could also use element handlers to get an event when the fade has finished, but, they're unreliable cross-browser and it's easier to just know the length of the transition and use a timeout to deal with the next action you want (in this case, remove the element).

Hope that helps.