Synchronous loading

General Discussions
#1

So far in my Java-based game everything has been single-threaded, including loading. I’m now in the process of finishing everything up and am wondering if I need to make the loading asynchronous. Although this would be a fairly simple application of multithreading, it would add quite a bit of complexity and would make it considerably more difficult to ensure correctness.

Basically, I’m interested in people’s opinions on whether sticking with synchronous loading would be a viable option. The loading for the game takes between 2 and 5 seconds (depending on the machine), there’s a loading bar, and the main thread is never blocked for more than half a second or so.

Does this sound acceptable for a commercial product? Might publishers or game portals reject a game that doesn’t load resources asynchronously?

#2

Loading multiple resources at once is not a good idea. The biggest bottleneck in resource loading is the hard disk read speed, and trying to read two files at once will add overhead because the hard disk has to keep switching the location it reads from instead of reading contiguous chunks.

#3

Thanks for your reply.

[quote]Loading multiple resources at once is not a good idea. The biggest bottleneck in resource loading is the hard disk read speed, and trying to read two files at once will add overhead because the hard disk has to keep switching the location it reads from instead of reading contiguous chunks.
[/quote]
I’m not quite sure what you’re referring to here. Are you talking about e.g. loading one resource in thread A while simultaneously loading another resource in thread B?

If so, that wouldn’t happen even in the multithreaded version. There would only be one extra thread for loading, and all resources would be read in sequence in that thread. Also, the resources are actually stored in an archive that’s read from disk and decompressed in one go, so no matter what there’ll only be one read from disk.

I’m definitely looking for suggestions though, so if I’m misunderstanding you or if it sounds like I’m taking the wrong approach, please let me know.

#4

That’s not true. In our game, a big part of the load time comes from generating VBO vertex data for our 3D models which is entirely CPU/RAM bound. The harddrive portion isn’t that significant. Secondly, reading from multiple threads actually improves the performance of both harddrives and SSDs; harddrives can reduce the total read time by reordering the requests to minimize spindle movement, minimizing latency for small files, while SSDs can actually read from multiple flash cells simultaneously so you may actually get much better performance by threading (more info: Google “queue depth”). That being said, I don’t think that 2-5 seconds is a long enough load time to warrant anything more advanced that single-threaded loading.

EDIT: From your new response, I assume you mean having a separate thread for loading resources while the main thread just takes care of the load screen? In this case, you won’t get any noticeable performance increase as you’re not really splitting up the workload between multiple threads or increasing your queue depth. The additional complexity does not sound worth it.

#5

[quote]From your new response, I assume you mean having a separate thread for loading resources while the main thread just takes care of the load screen? In this case, you won’t get any noticeable performance increase as you’re not really splitting up the workload between multiple threads or increasing your queue depth. The additional complexity does not sound worth it.
[/quote]
Your description is correct; it would just be a single extra thread while the main thread handles the loading screen.

My reason for considering it isn’t performance, since as you mention there’s unlikely to be any gains there. Really, my only concern about the single-threaded version is that it can block the main thread for up to a half-second or so, and, being paranoid, I worry that publishers or end users might view this as poor form.

As far as I know, lots of commercial games have used synchronous loading, so it doesn’t seem like it should be a problem. I’m not completely confident about that though, so I’m just looking for some reassurance on the issue.

Thanks for the feedback so far. Any further thoughts or suggestions are welcome.

#6

Although I have to admit I do kind of judge a game’s stability based on how well it handles loading screens, it still seems redundant in your case. Something that you should look out for though is that some features may interfere with synchronous loading. FTL (Faster Than Light) had a problem in the early versions where the game was essentially loading one tiny resource at a time, then swapping buffers (Display.update()). The loading screen obviously went at an FPS of several 1000s, but if you enabled V-sync the game took almost a minute to load due to the FPS being capped to 60 and hence, 60 resources per second.

#7

[quote]FTL (Faster Than Light) had a problem in the early versions where the game was essentially loading one tiny resource at a time, then swapping buffers (Display.update()). The loading screen obviously went at an FPS of several 1000s, but if you enabled V-sync the game took almost a minute to load due to the FPS being capped to 60 and hence, 60 resources per second.
[/quote]
Yeah, loading one resource per buffer swap doesn’t work for exactly this reason. To avoid this problem I load multiple resources between buffer swaps. With my current setup (with v-sync at 60), loading takes < 3 seconds on a fast machine, and there’s never more than a half-second or so between buffer swaps (and I can easily lower that if needed).

[quote]Although I have to admit I do kind of judge a game’s stability based on how well it handles loading screens, it still seems redundant in your case.
[/quote]
This is my concern. Although it really doesn’t seem like multi-threaded loading is needed here (or even that it would be particularly beneficial), I worry that publishers or end users might evaluate the game as de facto poorly implemented if there’s even a hint that the loading screen isn’t asynchronous.

Anyway, if you or anyone else knows what’s common among commercial games these days (or if anyone would be willing to share what they’re doing in their own projects), I’d be very interested. I’m still hoping to avoid multithreading, but maybe it’s the safest way to go.

#8

In my game after I changed loading many images with

Toolkit.getImage(...)

method from one therad to many threads, the speed of loading them increase about 3 times (I have i7 with 8 cores on my PC), the same situation is on laptop with i3 (4 cores).