Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (769)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (855)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Synchronous loading  (Read 3623 times)
0 Members and 1 Guest are viewing this topic.
Offline Jesse

JGO Coder


Medals: 23



« Posted 2015-04-07 00:56:19 »

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?
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #1 - Posted 2015-04-07 06:15:57 »

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.

Offline Jesse

JGO Coder


Medals: 23



« Reply #2 - Posted 2015-04-07 06:41:22 »

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.

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3 - Posted 2015-04-07 06:55:44 »

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.
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.

Myomyomyo.
Offline Jesse

JGO Coder


Medals: 23



« Reply #4 - Posted 2015-04-07 07:33:50 »

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.

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.
Offline theagentd
« Reply #5 - Posted 2015-04-07 07:47:49 »

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.

Myomyomyo.
Offline Jesse

JGO Coder


Medals: 23



« Reply #6 - Posted 2015-04-07 09:06:11 »

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.

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.

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.
Offline JanuszO
« Reply #7 - Posted 2018-01-06 20:43:36 »

In my game after I changed loading many images with
1  
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).
Pages: [1]
  ignore  |  Print  
 
 

 
EgonOlsen (1572 views)
2018-06-10 19:43:48

EgonOlsen (1632 views)
2018-06-10 19:43:44

EgonOlsen (1144 views)
2018-06-10 19:43:20

DesertCoockie (1569 views)
2018-05-13 18:23:11

nelsongames (1173 views)
2018-04-24 18:15:36

nelsongames (1638 views)
2018-04-24 18:14:32

ivj94 (2395 views)
2018-03-24 14:47:39

ivj94 (1605 views)
2018-03-24 14:46:31

ivj94 (2691 views)
2018-03-24 14:43:53

Solater (882 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!