eugeneloza / decoherence

Project moved to https://gitlab.com/EugeneLoza/decoherence
GNU General Public License v3.0
10 stars 7 forks source link

Threads #470

Open eugeneloza opened 6 years ago

eugeneloza commented 6 years ago

Yes, again. Thinking about which parts of the game may be off-loaded to a Thread. There are several issues impossible to fix, and some of them are so critical that we can't just allow something to work in the main thread. So.

Safe: Non-accurate Timer. up and working Off-sync world manager (prioritizing the tasks). I am unsure how efficient this will be, because to make it thread-safe, we have to copy the data it'd operate or use CriticalSection to safe-guard them from accident access. If off-sync world manager determines it's time to stop and load stuff from HDD or free scene elements, it will kindly ask to do this in a main thread. World generation as it can work on its own datasets which don't do anything except reporting current status to progress bar Loading from HDD into memory to safely speed up non-threaded loading process. E.g. we call "prepare" object to load, and then only initialize it. Not sure if that may give any speed boost except for music (see below)

Unsafe: Music most operations working in a thread (like managing and loading music) only seldom synchronizing to the main thread to launch/stop or adapt to changed situations. While hardly it's safe, that's the risk we can't avoid unless we want a few seconds pauses at each combat start/end or track end or a dramatic memory overuse.

Of course such optimizations must go together with profiling and made in such a way, that it's easy to change it from a thread-based to main-thread-based (e.g. by flipping just one compiler directive). Mostly it's the question of "whether the speed gain worth the instability risk".

eugeneloza commented 6 years ago

Try include AI and actor management in Threads. Important thing is to manage SimpleActors and their spawning in thread, as they may be lot's of.