pr0g / sdl-bgfx-imgui-starter

A starter project for graphics applications using SDL, bgfx and Dear ImGui
MIT License
312 stars 33 forks source link

Help with compilation #19

Closed cmorales828 closed 11 months ago

cmorales828 commented 11 months ago

Good day, I stumbled across this as one of the possible examples of the "bgfx" library usage in their documentation. I'm unsure if this is still supported, but I tried it nevertheless. I attempted to use the CMake GUI, as well as following the instructions as closely as I could, but I am a total newbie when it comes to C++ and libraries, and I'm not sure where to start learning, so I've just been messing around with projects.

I've attempted to get the project up and running, but have hit a couple of walls. The root CMake script seems to have an issue with finding SDL2 even when pre-compiling the third party binaries. Since I am using VS Code, I have my launch.json mapped to the root "CMakeLists.txt," which does not run or inherit any subdirectories to my knowledge. Wasn't really sure where to ask, but I have tried to follow all instructions for compiling or trying to get the starter program to run, and even when I just click on the executable file it opens and closes immediately. Again, I am a total beginner, so I completely understand if some of this is either hazy or if I messed up on my end. Thank you!

pr0g commented 11 months ago

Hey @cmorales828!

No worries at all! This stuff is always tricky to get up and running with, you have so start somewhere and I hope I can help!

I would start by just focussing on getting things building and running from the command line, and then setting things up to work with VS Code. Just to check can you let me know what platform you're on as that can sometimes be a factor making things more or less complicated.

I would delete all temp build folders (in the root and third-party folder) and then just run:

./configure-ninja.sh
cmake --build build/debug-ninja
./build/debug-ninja/sdl-bgfx-imgui-starter

This will get things working (you can run cmake --build build/release-ninja to build the release builf type as well if you want).

Can you give that a try (if you're on Windows you will likely need to run this from the Visual Studio Command Prompt to make sure Ninja and the MSVC compiler are found). and let me know how you get on. I can share how to hook-up VS Code after that.

Cheers!

cmorales828 commented 11 months ago

Good afternoon, I have attempted to build the project once more but I don't have ninja and don't really know how to set it up so I just used the visual studio 2022 compiler since I am on windows. This is the error I am receiving, even though SDL2 is installed, but the configuration for it isn't found (I have looked for it).
image Should I install ninja? I was a bit confused on how to, all tutorials I've seen tell me to set up an environment variable but not how to actually set it up (like what name to use so that it's registered or viewed by my IDE?)

Many thanks for the response nonetheless :)

cmorales828 commented 11 months ago

Seems I've figured it out! image Either way, thank you very much! :)

pr0g commented 11 months ago

Glad you got it working!

One alternative solution where you don't need to modify the CMakeLists.txt file is to use -DCMAKE_PREFIX_PATH=third-party/build from the command line when you configure (this is needed if you're not using a superbuild, superbuild is currently the default in the configure shell scripts I have).

Side note: You might also need to use %cd%/third-party/build when running the command as I think CMake used to need an absolute path for that command, later versions might be okay.

Also if you're on Windows, if you open the Visual Studio command prompt then Ninja will be automatically added to your path (Environment Variables).

If you want to learn more about CMake and how this project is set up, I'd definitely recommend taking a look at another repo of mine called CMake Examples which attempts to explain a lot of this stuff, as it can be quite confusing 🙈

I'll try and post some other example commands later today that could be helpful.

cmorales828 commented 11 months ago

I got it working for a bit, but trying to run the project made it close immediately. That wasn't a major concern for me, as I was going to rename the project as well, but that required recompilation of the build folder to ensure that all file paths were set properly. On attempting to compile the project using a different root folder name that "sdl-bgfx-imgui-starter," I received an error:

mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0 doesn't match value '2' in main.obj

I'm not sure if this error was just invisible beforehand (I can still go into the folder and run the executable but it causes the same thing to happen, it opens for a second and then closes.) or something entirely new.

When compiling, I did use superbuild initially, but the way the launch.json works for my project (to my understanding) means it runs the CMakeLists.txt directly from the root folder and attempts to compile the project.

Aside from this, I appreciate you providing examples, as it's very hard to come across valuable resources that aren't incredibly verbose and indigestible, and I did also check out the Awesome CMake repo. I'm not home right now so I can't use many of these resources but I can still surf through them and see if I'm able to get anything of value.

cmorales828 commented 11 months ago

Figured it out, I wasn't compiling to release. As for the crashes, the base SDL window process works just fine, not sure about anything else.

pr0g commented 11 months ago

Sorry I did start replying yesterday but it was more complicated to explain than I anticipated 😅 I will share a quick update later today 👍

pr0g commented 11 months ago

Sorry I still haven't been able to 100% test this (I wound up running into issues locally as I'm using Parallels on macOS to use Windows and I have an M1 chip so things get a bit more complicated with arm64 and x64 architectures...)

Anyway this should work, I'm 99% sure 😅

The error you were seeing before (iterator mismatch) was probably because the third party dependencies were built in the Release configuration and the sample app was built in Debug (or vice versa, could be either way IIRC, this is just a problem that can happen with the MSVC compiler and standard library implementation I believe). To ensure this doesn't happen, make sure you build both Debug and Release for the third-party dependencies. Then if you build Debug or Release the correct libraries will be used.

If you ignore all the configure scripts and want to do everything yourself, I'd recommend the following...

  1. Open a terminal (I can highly recommend cmder on Windows, cmd.exe is fine too) and then run "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\VsDevCmd.bat" -arch=<your arch> (this will add all the right environment variables you need for development). \<your arch> is also most likely x64, it could also possibly be arm64, but that's less likely.
  2. Do a git clone of the repo (if you haven't already), and then cd to the third-party folder.
  3. Run cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug (this generates the Debug build files).
  4. Then run cmake --build build (this builds the debug configuration)
  5. Run cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release (this generates the Release build files).
  6. Then run cmake --build build again (this builds the release configuration) i. By doing this it will build both Debug and Release versions of all the third-party libraries. We're using Ninja because it is waaaay faster than using Visual Studio/MSBuild.
  7. cd back to the root folder and run cmake -B build -G "Visual Studio 17 2022" -DCMAKE_PREFIX_PATH=%cd%/third-party/build
  8. You can then run cmake --build build, or open the Visual Studio .sln file (sdl-bgfx-imgui-starter.sln) and build from Visual Studio.
  9. Remember to also build the shader files (compile-shaders-win.bat). Do this after building the third-party dependencies.
  10. When running from Visual Studio, the working directory is set to be the source directory (so the shader files can be found). An alternative I haven't done, but likely should do, is to copy the shader folder to the same folder as where the app .exe is. I'd try this manually if you want to run from that folder. There's a way to do this with CMake using add_custom_command which I'll look into updating at some point. We actually do this already for the Emsripten build.

I think that's everything, again the configure scripts are intended to simplify things but this is essentially all the commands going on behind the scenes. The reason it is a bit more complicated is because of all the different platforms/OSes/architectures/CMake generators... I wish it was simpler too but this is the world we live in 😅 I hope that's helped a bit more and it's a bit clearer what's happening behind the scenes.

pr0g commented 11 months ago

Also just pushed a commit that should simplify running the app in future (see 8cff6aef7d14a16b820254f646e2f22535925d8d)