improve game loop time count; update loop without game time

[ArchDemons]

what changed:

1. Separated GameContoller and Thread management
2. Smart threads sleep (until it need to update)
3. Global Game Timer - own component

[tonihele]

Well, first of all, welcome back! We have missed you.

Secondly, about this PR. Could you please separate this to two different PRs? KWD file changes have nothing to do with the loops as far as I can understand the code. And that is what I've been mostly focusing now. Both PRs then could use some introduction as well. I have little bit difficulties in understanding all of the changes.

The KWD file thingie. It took me a couple of days to understand what problems you are trying to solve. I assume:

1. Places that load KWD files have copy pasted folder handling code
2. KwdFile itself has this design flaw(ish) that it requires to be initialized before fully used, unlike all the other DK2 resource readers/storages

If my assumptions are correct. I think you are firing a fly with an orbital laser or a nuke. Creating a proxy with reflection and having to have construct a loader state to parse KWD files. While it is kinda clever to have the proxy to prevent misuse (using partially loaded KWD), it complicates and slows down our code. I mean a generated proxy/facade would have done the job without the performance penalty. But still, that complicates things.

In my opinion the 1. point can be solved using a util method etc. There are not many places that read these anyway and basically these all can be shared and cached even. I think we had a MapSelector kinda to do this role. But any real shared caches should be separated and purposefully build.

2. point is, I admit, a potential pitfall, a bad API. But it is really a minor thing. By default KWD files are loaded fully. And there are only few places where the actual loading happens. After that the KwdFile is just tossed to all the dependencies, and at this point it should exist, like you did, as an interface with only the getters and no load method, fully loaded already. So for this problem, I would do nothing but the interface to use downstream.

[ArchDemons]

2. KwdFile itself has this design flaw(ish) that it requires to be initialized before fully used, unlike all the other DK2 resource readers/storages

KwdFile has 2 responsibilities: data storage and data loading. And this happens because of partial data loading. KwdFile should be like a POJO class. It should not load data at all.

2. point is, I admit, a potential pitfall, a bad API. But it is really a minor thing. By default KWD files are loaded fully. And there are only few places where the actual loading happens. After that the KwdFile is just tossed to all the dependencies, and at this point it should exist, like you did, as an interface with only the getters and no load method, fully loaded already. So for this problem, I would do nothing but the interface to use downstream.

Because KwdFile can load partialy, we must use Proxy to preserve transparency and code cleanliness. Other way - use external loader and check fully loading state manualy. Or made KwdFile child of base class that contain only part of data (kwd and map data), and use base class directly in some case (without loading other data part).

[ArchDemons]

Because KwdFile can load partialy, we must use Proxy to preserve transparency and code cleanliness. Other way - use external loader and check fully loading state manualy. Or made KwdFile child of base class that contain only part of data (kwd and map data), and use base class directly in some case (without loading other data part).

Or... When game starts, we can load all maps. Memory overhead, but KwdFile will a POJO class

[tonihele]

We should have these in a map instead of all the time traverse the whole collection... But I'm unsure is this called only on the initialization phase.

[tonihele]

2. Smart threads sleep (until it need to update)

This might have some adverse effects on the accuracy. The current implementation is optimized for high precision. Having it sleep more probably breaks this.

[ArchDemons]

If we feel a decrease in accuracy, we can increase it. But I don't think that's going to happen.

[tonihele]

If we feel a decrease in accuracy, we can increase it. But I don't think that's going to happen.

Well, there is going to be. The question is then, does it matter. That is the thing. sleep is not very accurate.

[tonihele]

You can merge, I approved. There is some stuff on DeepSource also if you want to take a look https://app.deepsource.com/gh/tonihele/OpenKeeper/run/212063d7-4fc8-4036-8534-d8340fd6ee39/java/