Getting into multi-threading.

[JonnyGingerKid]

@PandaMoniumHUN

Making a separate thread for file reading/parsing is completely fine, in fact, that’s how you should do it.
You can use something like a callback system to keep track of which files are loaded already and increase the loading bar accordingly.

Sweet! thank you for including info about how to do the loading bar btw!

@PandaMoniumHUN

There are more “multithreaded OpenGL tricks” like texture streaming, but that’s a bit of an advanced topic, look into it if you feel like it.

Thanks for bringing up texture streaming. I was actually looking at this tutorial: http://www.java-gaming.org/index.php?topic=32571.0 by theagentd and I was very interested. I’ll try it out and hopefully I can handle it.

[gene9]

@JonnyGingerKid

Hello! I was digging around online and heard something about multi-threaded game loops. Right now mine are single-threaded, and I wanted to know if multi-threading them is the way to go. And if it is, how would I do it?

• Async programming is generally faster than multithreading. Generalize both and you have parallelization.
• Parallelization is critical for server programming. For games, almost everything you write should be thread agnostic.
• Most hobbyist developers expressing interest in parallelization are more interested in the tech itself rather than the applied value.
• If your focus is really games, get your game mostly finished or at least playable. Then if you really want some extra runtime performance, try parallelization techniques.
• If you are really just more interested in threading/async tech than games, then go that direction: in the Java ecosystem I’d suggest understanding Future/Callable/ExecutorService really well. Then ForkJoinPool, understand the Scala extensions to Future/ExecutorService. Understand how you can use flatMap with a Future and then the for comprehension sugar. Understand async vs multithreading. Understand Akka.

[Roquen]

async normally is interrupt based and orthogonal to single/multithreading. Likewise for actor based and coroutines. Any similarity is superficial.

[philfrei]

I think princec’s statement about restricting multithreading to situations that don’t require synchronization or have dependencies is a good one. What I want to add is the point that if you learn more about “functional programming” techniques and use them, the set of possible situations that do not require synchronization or dependencies will grow, creating more situations where multithreading can be used without the synchronization headaches or complications.

Example of functional programming strategy: using an immutable object, from the Java Tutorials:
http://docs.oracle.com/javase/tutorial/essential/concurrency/imstrat.html
I often use a construction almost identical to this, collecting variables into one object. It’s helpful, among other things, for keeping objects subject to multithreading in consistent states, and can work well with the paradigm of separating data/models/presentation.