24 minutes ago, DiligentDev said:I tried to build it with MinGW and it does generate a lot of errors. I will see if I can fix them.
Oh? wow that would be really awesome. I have tried different mingw versions already (5.3.0,6.4.0, 8.1.0), but that does not seem to be the root cause.
@k3z4 The biggest problem turned out to be my Signal.h file that was conflicting with system signal.h. On case-sensitive Linux that worked fine because the files were different, but on Windows that made compiler go nuts because it was using my file instead of the system one. I fixed few other issues in Core module and it builds fine with MinGW now. Still working to fix the main repo.
45 minutes ago, DiligentDev said:@k3z4 The biggest problem turned out to be my Signal.h file that was conflicting with system signal.h. On case-sensitive Linux that worked fine because the files were different, but on Windows that made compiler go nuts because it was using my file instead of the system one. I fixed few other issues in Core module and it builds fine with MinGW now. Still working to fix the main repo.
That is very good news indeed. Looking forward to integrate Diligent Engine with my project. Thanx for your very(!) speedy response :-)
16 hours ago, DiligentDev said:I think you are not the first to ask about MinGW. Is there an advantage to it vs native windows build environment?
Yes. Compilations which are 10 times more long. Debugging sessions which are awfully slow, and which can have no backtrace. ?
mingw is (should be) the first target when porting a program from Linux to Windows. It is completely free, does not require Visual Studio, so does not require the VS runtime. And it allows couples of IDE to work with (as k3z4 mentioned). You can also do cross-compiling. Also, most Linux programs (and libraries) have their packages ported to mingw. And when they are not, this is generally not a big deal to compile them.
In my opinion GDB and DDD surpass MS, MinGW C++ compiler is compliant and has no MS proprietary behaviour.
---
How would I proceed the integration? I use GLFW for window creation, handle (mouse/keyboard) input and pass the native window handle to BGFX (nice, but shader mngt is big yuck!). I can see how my RenderManager will 'manage' the device and my RenderOperation will contain the Buffer related parts.
My engine is Entity based and follows Gaffer's ideas on distributed simulation, so I must have a lot of control on what happens when...:-)
18 minutes ago, Makusik Fedakusik said:
Your point being? I have played with BGFX for a few days and found it VERY cumbersome, especially its shaders. You cannot use any shader of the Interwebs for testing. You must extensively modify it, without any proper documentation at all. No geometry shaders. Uniforms are ALWAYS vec4. Need I go on?
Yes, I got it working, but am frantically removing it and hope to replace my rendering component with Diligent Engine/Core.
4 hours ago, k3z4 said:How would I proceed the integration?
Diligent itself does not define any platform-specific window abstraction. On any platform you use native window handle to initialize the engine (the swap chain). Below are examples for Windows and Linux:
P.S. Core module builds under MinGW, but it turned out shared libaries are not linked properly. Trying to understand how to properly use whole-archive business to make it work.
Ah, I figured that much. So I can maintain my input handling as it is and initialize Diligent with the native handle and proceed from there. I will certainly take a close look at the examples. Hopefully you solve the link issues. I had never hoped to get this kind of response soo quickly. Just awesome. Thanx ?
@k3z4 So MinGW build seems to be working now (do not forget to update the submodules).
To be honest, I should say (this was the first time I used MinGW) that I did not find anything that would compare positively against Visual Studio. Compile times are enormous. It seems like it's using only single core. I was not even able to wait until it builds the entire debug configuration: the linker was struggling with the first executable target for about 15 minutes (!) and produced ~500 MB executable (!??).
Release targets were all built successfully.
Couple things:
* Only Vulkan and OpenGL backends are built. D3D11/D3D12 backends depend on headers from windows SDK which are not found. Even d3d11.h is not found. I don't know how to fix this.
* I did not manage to make dynamic libraries to work. I build static library and then link static into shared one. On Linux, Android and Mac that works fine. MinGW produces empty dll (~47kb). When I use -whole-archive, it generated ~500 MB dll in debug build. So all targets are linked against static libraries (I don't really think this is a problem).
Other than that everything seems to be working fine, so all functionality is there.
