Suggestion: Switch to FetchContent for third-party dependencies

[MrOnlineCoder]

Most (if not all) dependencies for ElvenEngine are available as public repositories, and therefore, can be added to the project using FetchContent CMake module. This would allow:

• Get rid of submodules or including the source code for dependencies right away in the ElvenEngine repository
• Get rid of Windows-specific .bat script
• Allow to explicitly use a specific version of each dependency by specifying needed tag in the CMakeLists FetchContent command
• Automatically introduce cross-platform dependencies setup

This suggestion comes intially from my attempt to get ElvenEngine running on MacOS, and in that case, setting up dependencies and specifying their paths in CMake GUI was a bit of unneeded manual work.

Let me know if you have any objections about it.

P.S. - the only exception I guess would be GLAD, but it's pretty easy to include in project, as compared to other fully-featured libraries

[denyskryvytskyi]

Sounds interesting. I would integrate this type of dependency management. If you have time and desire to experiment I'll consider pull-request.

Anyway, thanks for your suggestion and time.

[MrOnlineCoder]

Thanks, I will try to experiment a bit of getting both Elven running on MacOS and building it with FetchContent, and will make a PR this or next week for that, if I succeed.

[MrOnlineCoder]

@denyskryvytskyi Hi again, I've succeeded to compile the engine itself with my changes to CMakeLists using FetchContent (which was a bit of a challenge btw :D ) but now I've encountered a tough problem: The irrKlang sound library officially provides binaries/libs only for x86/x64 platforms, which does not include arm64, which is the current mainstream platform for Apple-silicon based MacOS systems.

As I understand from forum replies, such support is not something they are going to add anytime soon: https://www.ambiera.com/forum.php?t=9751

Also because of it's licensing, irrKlang does not provide source code which I could potentially compile for desired architecture/platform.

Is there any workaround right now for this you can think about? Maybe using a toggle to disable sound system for now at all, or switching to another sound library? Not sure if things like SDL_mixer or similiar work without the main library (SDL) itself. Maybe fmod can be also an option, however they have a bit more advanced licensing conditions compared to irrklang.

[denyskryvytskyi]

@MrOnlineCoder Hi! I've submitted a quick workaround for this problem with the option to disable irrKlang usage. You can check it in the last commit 218a9b6. I'm considering integrating OpenAL in the future instead of irrKlang for all platforms, but the sounds module can be just disabled for now.

Thank you again for your effort to run it on MacOS :)

[MrOnlineCoder]

@denyskryvytskyi thanks for the hint, merged with your commit and the irrklang exclusion worked.

However now we encounter another MacOS-specific issue (👁️ Apple).

Their latest OpenGL implementation is stuck on OpenGL 4.1, while some of your OpenGL renderer implementation classes use features that were added only in later versions - like glCreateTextures, available only from 4.5

What do you think should be done about that?

I see few options right now:

1) Rollback to using OpenGL 4.1 functions only, rewriting unsupported functions to older ones (like glGenTextures). This may also require downgrading GLAD version to make sure newer functions won't be defined. We may also just create a new backend called OpenGLOld or something like that. 2) Use (1) but with a define/ifdef or some runtime check to use new implementation when supported on other systems 3) Write another renderer backend - Metal (🤮 ) or Vulkan (🤯 ) which should have better support on MacOS

[denyskryvytskyi]

@MrOnlineCoder well, this is a tough one.

• Vulkan/Metal support. This is an ideal option but is most complex at the same time. I want to implement the Vulkan backend at some point, but it's not planned for the near future. And it requires a massive work to do.
• Opengl version downgrading. This is completely not what I would like to see in the engine. The 4.5 version is optimized and tested for at least a reasonable time in the current Renderer implementation. It's not the best option cause Opengl is fully deprecated for Mac and dowgrading to deprecated API is overkill.
• 4.1 and 4.5 both support. This is the best option. I don't like to populate a lot of macro uses, especially ifdef that leads to unreadable code and a nightmare to support it. So, separate implementation for RHI is the best option for now I think.

Unfortunately, I don't have a Mac to test whatever. Are you sure that the OpenGL 4.1 version can be runnable on Apple-silicon? If yes, then we need to make the following work:

• make a separate folder for the new backend Platform -> OpenGL41
• add OpenGL41 RendererAPI type
• implement specific code for the next classes: Vertex/Index/ArrayBuffer, Texture, Framebuffer
• generate separate glad header here and include right one according to a platform
• check shaders and change versions
• check ImGui (I think should work without changes)
• test it

To sum up, It doesn't look too difficult to implement but needs time. I can make it all but not so quickly. Don't want to make promises or give particular dates. For now, I want to complete my current task in progress ( implement uniform buffer and cubemap). After that, I think I could experiment with this problem.

P.S. Thanks for your investigations! Feel free to experiment with OpenGL 4.1. and separate the backend if you have a desire. If you will start to do this, please let me know to avoid doing the same work.

[MrOnlineCoder]

@denyskryvytskyi thank you for the arguments, I also think an independent RHI just for OpenGL 4.1 would be fine and most optimal.

Are you sure that the OpenGL 4.1 version can be runnable on Apple-silicon?

Yes, aside from just info from here - I have personally created 3D applications with OpenGL on MacOS ARM-based system, and the used OpenGL version was exactly 4.1

If you will start to do this, please let me know to avoid doing the same work.

Yes, I would like to do that, although as you said, cannot give any guarantees on the time estimates, because I need to get familiar with Elven source code a bit more for implementing that.

I will make it as a part of my MacOS support PR.

[MrOnlineCoder]

@denyskryvytskyi I guess I will have to ping you for some organizational/setup questions, so here is the first one.

My guess is that you use Visual Studio for development, I am using VS Code + Clang on MacOS, and currently it cannot find defenitions for different core classes and functions like lia or logger.

None of the VertexArray or RenderTopology headers include them.

I guess this is related to precompiled headers usage (elpch.h), and I suppose Visual Studio is able to include it impiclity under the hood without writing the #include in the code itself.

Would it be fine if I manually #include the needed headers (like Core/Log or lia) where I need them? I currently cannot find an alternative solution in VSCode

[denyskryvytskyi]

@MrOnlineCoder Try to add "forcedInclude": ["${workspaceFolder}/Engine/src/elpch.h"] to the c_cpp_properties.json configurations part.

[denyskryvytskyi]

@MrOnlineCoder By the way, here is a great reference for the old/modern OpenGL comparison.

[MrOnlineCoder]

@denyskryvytskyi oh wow thanks, I was looking for a such compilation, that will help