Replace world delta time with duration and make systems suspend-friendly.

[ygdrasil-io]

Hello,

I would like to propose a couple of enhancements to the library to improve its functionality and flexibility:

Replace World Delta Time with Duration:
Currently, our ECS library uses a floating-point value to represent the world delta time. While this approach works, it limits the flexibility and precision of time management within the library. I propose replacing this float with a more versatile duration type.

Using a duration type would offer several benefits:

• Flexibility: Durations can be represented in various formats, including floating-point numbers for continuous time and discrete values for fixed time steps. This allows users to choose the most suitable representation for their specific needs.
• Precision: Durations can handle high-precision timing requirements more effectively, ensuring accurate and consistent updates across different systems.
• Adaptability: By supporting different types of durations, the library can better accommodate a wider range of use cases, from real-time simulations to turn-based games.

Support for Coroutines:
Currently, the library does not natively support suspending and resuming systems, which limits its ability to handle asynchronous operations efficiently. I propose enhancing the library to make systems suspend-friendly, enabling support for coroutines.

What do you think about that?

[Quillraven]

For the duration I am not sure how that will feel from a UX point of view. E.g. in LibGDX (my main usage for Fleks) I get a float delta time from the library that can be passed to Fleks. Is the duration thing an object? Because creating an object each frame creates a lot of garbage for the GC. I wonder how that will look like.

For coroutines: would be cool but it adds an extra dependency to the library that not everyone might use. How big is the coroutine dependency?
Also, afaik coroutines do not work very well in the browser (in TeaVM they do not work at all). So might be better as an optional add on library to Fleks?

If you have time and motivation then feel free to make a PR. Then it easier for me to verify what kind of impact it will have by testing it in some of my games.

[konsoletyper]

in TeaVM they do not work at all

That's not true. Coroutines supported in TeaVM. What TeaVM does not support is kotlinx.coroutines library, but you actually don't need this, you can do a lot without this library, using pure coroutines.

[ygdrasil-io]

Regarding Duration, I have created a PR available here: #171.

Regarding coroutines, it's more complicated. There's no absolute need to use external libraries, but functions need to be at least marked as "suspend". Maybe we should publish two versions: a classic one and another with coroutines that allows distributing system updates in a distributed manner. What do you think about having a classic version of Fleks and another with concurrency?

[metaphore]

Duration is a value class, so there is a low overhead

Value class or not it's still a class and in JVM environment it will produce garbage as usual. As far as it looks there's no way to reuse Duration instance somehow, right? It's really hard to justify that downside when working with frame by frame game engine updates.

There's probably another way around. All in all, having delta time value in system update is in fact not necessary. There are good examples of engines where you retrieve the delta time value from a publicly available "Time" data provider (like in Unity Engine). In theory this might allow for more flexible system configuration, where you are not obligated to provide delta time to update, but it's up to you to maintain it globally somewhere else and in the format you prefer (e.g. Duration, Float or whatever else you need for your game).

[Quillraven]

I have tested it now in some of my projects and tbh I couldn't see a big difference memory/cpu wise. I guess this is due to JVM optimizations when it comes to short living objects (or I am not that good enough reading and understanding Intellij's profiler output 😁).

However, what I totally hated is all the conversions when working with LibGDX. LibGDX uses floats internally for many "per frame" methods and since Fleks would use a Duration you always have to convert back and forth which is really not nice.

Since I (and I know a few others) work with LibGDX and Fleks, I don't like the current approach.

As @metaphore mentioned, deltaTime is not always necessary in systems and that's why Fleks doesn't pass it to the update/tick methods of a system. When you need it, you can call a deltaTime getter which depending on the interval of the system returns the fixed timestep or the real delta time of the world (iirc). So I'd go more towards that direction that somehow the type of deltaTime gets configurable when creating the world. That way LibGDX users can stick to floats and other users can use whatever they want.

[ygdrasil-io]

Values are supposed to be 'inline'. I don't know how because, when I decompile, this is marked as duration, but there must be some optimization to treat it as the hold primitive instead of a class somehow.

Regarding code style, I understand. Durations are more the idiomatic way in some modern pure Kotlin frameworks, but they may not fit other frameworks way.

Perhaps we could consider another approach by removing the delta time management to an abstraction that we could inject or not into the system. This way, end users could see the pattern and choose to use it or not. This way we make the base framework lighter and more tweakable for people that need it. What do you think?

[Quillraven]

Yes, exactly. Maybe we can replace the float parameter of the world.update call with a reified type (I don't think so??) or, as you suggested, make it a separate object or var or something that gets set via world configuration.

This will be of course a breaking change but imo it is not a big deal if we manage to somehow make the current deltaTime getter in systems work.

My vision would be that e.g. I can set "Float" als deltaTime object in the world config and then just modifiy existing world.update calls with two separate calls

1. world.deltaTime = ...
2. world.update()

Not sure if a var, separate "Update handler service" or a world with a generic type for the delta time type is the best approach.

[ygdrasil-io]

What do you think of this version : #173 ?

[ygdrasil-io]

In the first pass, I duplicated the systems to create one that supports suspendable functions on update without adding coroutine libraries (except for testing). #172

This is the naive approach. With the library, we could use dispatchers and create complex system update orchestration, but that requires some design first. Give me some time to think about an implementation. I’m open to suggestions.

[Quillraven]

@RefuX don't forget about us 😉

[RefuX]

Sorry, back and catching up on stuff. Will have a look asap 👍

[RefuX]

Just a note that I started looking at the code today 👍

[RefuX]

I had a look at the code and ran it with my project. The catch is that in my project is adding/removing entities (and systems) off different coroutines, but I currently haven't had a need to suspend in a onTickEntity. I actually have times I will launch a coroutine in an onAddEntity.

I can see that having suspending functions for onTickEntity and onAddEntity and onRemoveEntity could be useful for me in the future, so I'm all for it 😎.

Code review wise, I think it's a very straight forward way of adding suspend onTickEntity, especially given Simon's desire to keep the core Fleks library very performant and small.

One note about the SuspendableSystemTest, call me old fashioned, but I would like to see SuspendableSystemTestIntervalSystemEachFrame and SuspendableSystemTestIntervalSystemFixed actually having a suspending function in the onTick function. A token delay(1.milliseconds), just so it's doing what it says on the tin.

Also IntelliJ is also quite insistent that override inline suspend fun is the wrong order and should be override suspend inline fun. 🤷‍♂️

If there is more interest from people in adding richer coroutine support, then maybe we can create a fleks-coroutines library. As @ygdrasil-io mentioned, we would create a more complex system leveraging the Kotlin coroutine libraries. So that way fleks-core could keeps in simplicity.

[Quillraven]

Thank you for having a look into this! Can you add your feedback to the open PR to continue the discussion there?

Once it is in a final state I think I will follow your idea for now and create a separate coroutine branch that follows the normal GitHub actions process and releases a ".CRT" version (name is not final).

With Fleks 3.0 there will be anyway bigger breaking changes and for me that is the point where I want to introduce coroutine support per default.