Can't compile

[mctb32]

I was trying to check out the project, but I can’t get it to build. Are there any special configuration steps or requirements that are not mentioned in the usage section of the readme? I generated a vs2022 solution using cmake with x64 target and all options on default. Out of the 23 projects, 5 fail, most notably equilibrium, editor and sandbox. In the equilibrium project I’m getting 780 compiler errors, most of them, if not all, are on invalid calls to flecs and bgfx according to error log. Meanwhile, all bgfx projects and flecs build fine... Do you have any idea what I might be doing wrong?

[clibequilibrium]

Hello @mctb32 ,

Thank you for submitting the ticket. As I can probably guess you are compiling with MSVC & not clang. Also I am not using IDE but VS Code to build my applications.

However I will take a look at what I can do to support pure MSVC on Windows. I can see there is an issue with macros unrolling.

EDIT:

in the meantime could you please tell me if that works for you?

[mctb32]

Sorry, for some reason I got the impression that msvc was supported. I saw LLVM in the readme, but I assumed it would be used for some scripting features, code formatting or shader cross-compilation magic… Anyway, thanks for updating the readme to making it even more clear.

Thanks for the link, I’ll try it out and see if that’s easy to set up, or I will just try VSCode/Clang.

[mctb32]

Just FYI @clibequilibrium, I managed to build the engine using visual studio and the built in cmake/clang support. It worked almost out of the box - the only thing I had to do was to change the selected toolset from msvc to clang, as msvc was selected when I opened the cmake project.

With clang, all of the projects built in about 10 seconds on my machine. I was surprised, because earlier when I was trying to build using a vs solution with msvc it took almost 17 seconds even without linking the failed projects. I don’t have any experience with clang – is it usually that faster in comparison to msvc, or is this only with C code as opposed to C++?

[clibequilibrium]

Hello @mctb32 ,

Thank you for getting back to it and I am glad you were able to compile the project. I have updated README and also added Sponza model that will be copied to the final build destination upon CMake configuration , so once you build you can launch the Launcher and see Sponza.

With clang, all of the projects built in about 10 seconds on my machine. I was surprised, because earlier when I was trying to build using a vs solution with msvc it took almost 17 seconds even without linking the failed projects

Yes indeed. The full engine recompilation (equilibrium, editor, launcher) targets should not take more than 10 seconds. Every incremental compilation happens in about 1-2 seconds. In the past I had an entt C++ branch for the Engine and I used GCC back then. Static linking to CXX libraries would take the longest time and total of ~30 seconds .

I decided to enforce Clang due to the good support of C standard as oppose to MSVC that doesn't have official C99 support. Also supporting multiple compilers just for the sake of supporting them seems unnecessary to me. Currently the biggest time consuming compiling targets are just the dependencies that you will build once.

In any case do not hesitate to open a new issue if some problems arise. I am very happy to see somebody actually trying the engine !

I saw LLVM in the readme, but I assumed it would be used for some scripting features, code formatting or shader cross-compilation magic…

To clarify on shader cross-compilation I use bgfx's shaderc LLVM tools used: clang-format, clangd. Luckily VS Code has all the needed extensions for Clang development on Windows.

Here are the extensions I use in VS Code for the development. I disabled C/C++ extension Intellisense in favor of clangd one.

[mctb32]

Thanks for the additional details. And for including the sponza model - I added it myself at first but it failed to load as only dds textures are supported.

Unfortunately, I know the pains of long compile times to well. Our inhouse engine uses static linking for all of the components and with our current games full builds can take up to 10 minutes. I was looking into flecs when I saw your post about you open sourcing your engine so I decided to take a look to see how one might use flecs in the context of an actual engine. So big thanks for making it public!

One more question – when you decided to use bgfx for the gfx api layer, did you take other options into consideration? I’m specifically thinking about DiligentGraphics, which seems to have a very similar feature set but in contrast to bgfx it uses modern abstractions better suitable to dx12/vulkan/metal. It’s written in C++ but I believe it exposes a pure C API as well.

[clibequilibrium]

Thanks for the additional details. And for including the sponza model - I added it myself at first but it failed to load as only dds textures are supported.

Unfortunately, I know the pains of long compile times to well. Our inhouse engine uses static linking for all of the components and with our current games full builds can take up to 10 minutes. I was looking into flecs when I saw your post about you open sourcing your engine so I decided to take a look to see how one might use flecs in the context of an actual engine. So big thanks for making it public!

One more question – when you decided to use bgfx for the gfx api layer, did you take other options into consideration? I’m specifically thinking about DiligentGraphics, which seems to have a very similar feature set but in contrast to bgfx it uses modern abstractions better suitable to dx12/vulkan/metal. It’s written in C++ but I believe it exposes a pure C API as well.

Yes, at first I was looking at sokol and also was comparing DiligentGraphics. The 1st thing that turn me off is Metal not being easily available on Diligent. Sokol not having compute shaders also contributed to my decision.

I was guided by this article.

But since Equilibrium Engine is modular, everyone is welcome to create their own flecs modules for graphics and use them. Same goes for windowing, if somebody doesn't like SDL , feel free to use GLFW! I picked bgfx for its rich platform and rendering backend support that comes out of the box with no hassle. The API is also very nice.

I added it myself at first but it failed to load as only dds textures are supported.

Yes, it's a must unfortunately. To compile textures you can either use cmake macro compile_texture or checkout this python converter

[mctb32]

I remember reading the article you mentioned about a year ago and it was already outdated back then. For example, one of the frameworks it mentions, bs:framework, was abandoned a few years back. AFAIK Diligent supports Metal, but it’s a separate commercial license, and it also supports Vulkan on Apple systems via MoltenVK. I was in touch with the author of Dilligent back in 2018 when the project was just starting and from what I remember one of the reasons he created the library was to solve the problems he had with bgfx performance using modern gfx API’s. But I’m sure BGFX has also evolved over the years and solved some of the problems.

But since Equilibrium Engine is modular, everyone is welcome to create their own flecs modules for graphics and use them. Same goes for windowing, if somebody doesn't like SDL , feel free to use GLFW! I picked bgfx for its rich platform and rendering backend support that comes out of the box with no hassle. The API is also very nice.

How are you going to achieve this kind of modularity? Is the engine defining a common set of components the various backends and the client should use? For example, is the client app using a generic mesh component or is it forced to select a component provided by a certain backend system? I know ECS systems are modular by nature, but the problem seems to be in designing abstractions.

[clibequilibrium]

How are you going to achieve this kind of modularity? Is the engine defining a common set of components the various backends and the client should use? For example, is the client app using a generic mesh component or is it forced to select a component provided by a certain backend system? I know ECS systems are modular by nature, but the problem seems to be in designing abstractions.

The chances of the team wanting changing implementations on the fly are very rare. Usually teams come up with a decision on what to use. Example: PhysX or Havok for physics, imgui or Nuklear for ui tooling etc. Currently the modularity comes with the freedom creating your own modules , set of components and defining your own flow of a given frame. Also hot reloading of both shaders & scripts allows you to dynamically prototype your Engine GUI or in game systems . Currently Equilibrium Engine is pretty much barebone but can give a good start for many people.

By default the engine comes with some generic components (windowing, input, ui context), but some rendering specific ones like bgfx scene components. ROI of Designing abstractions with ECS are low in my humble opinion and I usually stick to a more straight forward approach on how I design my ECS applications.

EDIT: thanks for updating information on Diligent!

[clibequilibrium]

@mctb32 I was also planning to make a small diagram explaining how is the Engine structured. Which libraries are hot reloadable at all times and which ones are the ones that should not be reloaded. Also currently equilibrium.dll is not hot reloadable as it's the core library that is responsible for windowing and gfx, while editor.dll and sandbox.dll are. What can be done is splitting equilibrium into equilibrium_reloadable.dll, where sky, camera & some rendering systems can be placed to be hot reloaded as well.

[mctb32]

Thanks, I have very little experience with ECS so this is very interesting. A diagram of the engine architecture would be very nice, especially if the focus is on modularity and clean separations.