Entt: Remove The Forge from the list of users
The Forge replaced EnTT with its own trivial map based ECS.
It seems that either they haven't read the FAQ or this wasn't enough anyway and they had problems on Windows in debug. I'd opt for the former, because the measures they reported are close (at the opposite) to what we experienced with the changes described in the FAQ.
That said, this brings under attention once more the fact that debug builds on Windows can be slower than expected when using the standard library, even when all the checks introduced by their implementation are disabled as described in the FAQ.
Probably it's worth replacing some data structures with something tailored for the purpose (at least on this platform).
The extension to allow custom pools should solve the problem to an extent because it permits to the user to do that on their own and therefore this feature gets higher priority over other features at the moment.
skypjack
All 6 comments
May be you should reconsider EA STL it's compile fast..., Suited for video games and efficient
Milerius
on 29 Jun 2019
Well, let's consider the facts.
The _issue_ is mainly with msvc because of the indecent amount of checks it has historically in debug. You can mitigate it by far (really, really by far) if you know your system (or if you read the FAQ). EnTT on its own allows to disable all the extra checks in debug too. We already discussed this more than once on gitter and the results were constantly reported at the time.
Also, not sure you followed the story but this was kind of expected and to be honest I've never understood why they accepted to use EnTT, because it was quite obvious they were looking for _something different_.
Thart said, EnTT started and is still an experimental project I use to learn the new features of the language and of the library. I don't want to set eastl as a dependency, nor to do something because a company that has never contacted me, will never pay for or will ever contribute to the project decided to use something that was already in use in some other parts of their library.
I think they made the right choice indeed, despite the poor performance of their handcrafted solution.
Note also that eastl is an old fashioned library with its own problems and I prefer to allow users to _decide_ what they want rather than forcing them with one or the other implementation, that is the whole point of making pools customizable. This way you can use the standard one and achieve good performance also in debug if you read the FAQ or you can roll your own pool that uses your custom vector if you want.
The only regret I have is that this is a missed opportunity for the open source community in general, but they are a company, an open source project doesn't make them necessarily open source friendly unfortunately.
There are a lot of companies that are using EnTT at the moment, some of them I cannot even mention because of a sign I put on a piece of paper. Let's see if the next one will decide to contribute and help us making EnTT greater. :wink:
Until then I'll continue to develop it in the free time so as to offer something new to those interested in the topic. :+1:
skypjack
on 29 Jun 2019
Then we should embed a eastl like lite library in EnTT but it's will take time to design and develop
Milerius
on 29 Jun 2019
I don't think so. Users can embed eastl by defining custom pools if needed or just rely on the standard library and read the doc from msvc to know how to disable extra checks on iterators on Windows and the doc from EnTT to know how to disable its extra checks during iterations.
Actually, custom pools are already possible to an extent if one is skilled enough to understand the code of this library (and this wasn't the case probably, who knows), so you can even provide your implementation if you want.
By the way, the ECS part is giving already and will give even more the flexibility you are asking for with the plus that I won't have to do foolish things like writing my own version of the standard library that has poor performance, less than half the features but many subtle bugs as many implementations you can find out there do.
Really, people shouldn't write about topics they have no experience with or have not the time/willingness to investigate into just because they came from the '90s with their old fashioned mantra _modern C++ is bad_ or _the standard library_ is bad, that is enough to justify everything most of the times.
I won't jump on the bandwagon of those that blame something because they are not willing to understand how a dev env works. I have many ideas on how to spend my time in a better way!
I don't really care of this internal war in the game industry and I prefer to keep away from it and stick with my goal, that is to invent something new from the point of view of the architecture and to experiment with the new features of the language while doing this. :wink:
skypjack
on 30 Jun 2019
Well considering it doesn't even have a build system, no make or cmake or anything of the sort to compile with, instead you have to install some weird GUI 1990's-looking IDE called CodeLight or so to compile it, it doesn't seem like dependency management would be terribly strong there either. :-/
_/me tried to experiment with it for a bit but that failed pretty hard just because of how extremely deficient the build system is..._
OvermindDL1
on 1 Jul 2019
@OvermindDL1 at least now they have been explicit on the reasons: https://github.com/ConfettiFX/The-Forge/blame/master/README.md#L105
This confirms my guess that it was the wrong choice from the beginning for them.
skypjack
on 13 Jul 2019
Related issues
markand
路
5Comments
skypjack
路
6Comments
bjadamson
路
4Comments
xoorath
路
3Comments
jaspercb
路
6Comments
Most helpful comment
Well, let's consider the facts.
The _issue_ is mainly with msvc because of the indecent amount of checks it has historically in debug. You can mitigate it by far (really, really by far) if you know your system (or if you read the FAQ). EnTT on its own allows to disable all the extra checks in debug too. We already discussed this more than once on gitter and the results were constantly reported at the time.
Also, not sure you followed the story but this was kind of expected and to be honest I've never understood why they accepted to use EnTT, because it was quite obvious they were looking for _something different_.
Thart said, EnTT started and is still an experimental project I use to learn the new features of the language and of the library. I don't want to set eastl as a dependency, nor to do something because a company that has never contacted me, will never pay for or will ever contribute to the project decided to use something that was already in use in some other parts of their library.
I think they made the right choice indeed, despite the poor performance of their handcrafted solution.
Note also that eastl is an old fashioned library with its own problems and I prefer to allow users to _decide_ what they want rather than forcing them with one or the other implementation, that is the whole point of making pools customizable. This way you can use the standard one and achieve good performance also in debug if you read the FAQ or you can roll your own pool that uses your custom vector if you want.
The only regret I have is that this is a missed opportunity for the open source community in general, but they are a company, an open source project doesn't make them necessarily open source friendly unfortunately.
There are a lot of companies that are using EnTT at the moment, some of them I cannot even mention because of a sign I put on a piece of paper. Let's see if the next one will decide to contribute and help us making EnTT greater. :wink:
Until then I'll continue to develop it in the free time so as to offer something new to those interested in the topic. :+1: