Setting up ecst - needed modules, compile issues

[BrodyHiggerson]

I thought this library looked really interesting, and was advertised as header-only, so I foolishly hoped to just drop it into my C++ Win64 VS2015 project without issue, but this has not been the case 😁

I've grabbed the vrm/core and vrm/pp code from Github and made sure it was included. Then, trying to compile the project:

1>l:_programming\projects\ecst-test\lib\vrm\pp\generated\output.hpp(782): fatal error C1112: compiler limit: '129' too many macro arguments, only '127' allowed

On this line of output.hpp in vrm/pp:

#define VRM_PP_IMPL_NSEQ( m1, m2, m3, m4, m5, m6, m7, m8, m9, m10, m11, m12, m13, m14, m15, m16, m17, m18, m19, m20, m21, m22, m23, m24, m25, m26, m27, m28, m29, m30, m31, m32, m33, m34, m35, m36, m37, m38, m39, m40, m41, m42, m43, m44, m45, m46, m47, m48, m49, m50, m51, m52, m53, m54, m55, m56, m57, m58, m59, m60, m61, m62, m63, m64, m65, m66, m67, m68, m69, m70, m71, m72, m73, m74, m75, m76, m77, m78, m79, m80, m81, m82, m83, m84, m85, m86, m87, m88, m89, m90, m91, m92, m93, m94, m95, m96, m97, m98, m99, m100, m101, m102, m103, m104, m105, m106, m107, m108, m109, m110, m111, m112, m113, m114, m115, m116, m117, m118, m119, m120, m121, m122, m123, m124, m125, m126, m127, mN, ...) mN

Any advice would be appreciated. Is this perhaps not a supported platform?

EDIT: Additionally, as a side question; the way you've written about the threading model has left this somewhat unclear, but can I totally take over with my own architecture, such as an IntelTBB or similar job system, and hand out the ECS update work to that or to other similar systems? An externally-controlled update on an ECS-system-by-system basis, for example.

[vittorioromeo]

Hello,

I only officially support clang++ and g++. I've built ecst successfully on Windows using nuwen MinGW.

I've grabbed the vrm/core and vrm/pp code from Github and made sure it was included. Then, trying to compile the project:

1>l:_programming\projects\ecst-test\lib\vrm\pp\generated\output.hpp(782): fatal error C1112: compiler limit: '129' too many macro arguments, only '127' allowed

Seems like MSVC has an hardcoded limit for macro parameters. I use a script to generate variadic macro boilerplate in vrm_pp.

Even by tweaking the script, I doubt that MSVC will be able to compile ecst as it's using bleeding edge C++14 features and idioms. Sorry for the incovenience! Check out MinGW if you can.

but can I totally take over with my own architecture, such as an IntelTBB or similar job system, and hand out the ECS update work to that or to other similar systems?

There currently is no way of plugging in a different thread pool/scheduler without modifying ecst's source code, but the library's design could allow the pool/scheduler to be a template parameter. Making this easier is something planned for the future.

An externally-controlled update on an ECS-system-by-system basis, for example.

Could you elaborate on this? I don't think ecst is capable/designed for this particular use case.

[BrodyHiggerson]

I only officially support clang++ and g++. I've built ecst successfully on Windows using nuwen MinGW.

Ahh, that's a shame. I figured due to MSVC's popularity in games, a gaming-focused architecture would be there, although I can see what you mean re. the bleeding-edge compared to some of the others! All good.

An externally-controlled update on an ECS-system-by-system basis, for example.

Could you elaborate on this? I don't think ecst is capable/designed for this particular use case.

I meant something like, updating a 'Movement' system, which just finds all 'Position' + 'Velocity' component combinations and changes the position's values by velocity, in a parallel_for loop or similar. You know, being able to split the work of updating individual systems out to multiple threads/jobs, rather than calling 'Update' on a central object and letting it do the work.

EDIT: Do you have any personal recommendations, given your familiarity with the topic, of other C++ ECS libraries that may operate in this way? Thanks!

[vittorioromeo]

I meant something like, updating a 'Movement' system, which just finds all 'Position' + 'Velocity' component combinations and changes the position's values by velocity, in a parallel_for loop or similar. You know, being able to split the work of updating individual systems out to multiple threads/jobs, rather than calling 'Update' on a central object and letting it do the work.

Assuming you mean: having a single Movement system which automatically splits its workload in multiple sub-tasks that can run in parallel... this is what ecst does.

From pres_code.cpp:

struct velocity
{
    template <typename TData>
    void process(ft dt, TData& data)
    {
        data.for_entities([&](auto eid)
            {
                auto& p = data.get(ct::position, eid)._v;
                const auto& v = data.get(ct::velocity, eid)._v;

                p += v * dt;
            });
    }
};

The above code can run in parallel on various "slices" of the subset of entities that have both "Position" + "Velocity". You can control this through system signatures:

constexpr auto ssig_velocity =
    ss::make(st::velocity)
        .parallelism(split_evenly_per_core)
        .dependencies(st::acceleration)
        .write(ct::position);
        .read(ct::velocity)