New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Externals: Use Common ASSERT for IM_ASSERT #10375
Conversation
Are you sure "imgui is only used by dolphinqt" is correct? The imgui-rendered OSD messages and so on show up on Android... Sounds reasonable other than that. |
Oops, that's wrong; there's also a dependency in VideoCommon: dolphin/Source/Core/VideoCommon/CMakeLists.txt Lines 134 to 142 in 7b8e846
Still, VideoCommon depends on common (through core) and fmt, so I don't think adding this dependency is a problem. There isn't an explicit dependency for android (but it looks like no android code directly references imgui, while some DolphinQt code and a lot of VideoCommon code does directly reference imgui). |
Yes, I agree. I was just confused by the PR description claiming that. |
9368895
to
89cba35
Compare
89cba35
to
3b8d112
Compare
You may want to leave a note somewhere visible that these changes need to be re-applied when updating imgui. |
Note that imgui itself documents the process: dolphin/Externals/imgui/imconfig.h Lines 1 to 13 in e58cf36
Since imgui doesn't include a |
Sure, but are you sure someone's gonna read that when they update? I'd just drop a |
This does introduce a dependency on common and on fmt from imgui, but gives a better experience.
I've added a README.txt for it. |
The first commit calls the
IMGUI_CHECKVERSION
macro, which is intended to prevent issues like the one I caused after #10188 where the wrong version of imgui was linked. The second commit is also future-proofing.The third commit switches to Common's
ASSERT
macro for theIM_ASSERT
macro. This does mean imgui now depends on both common and fmt, but since imgui is only used by dolphinqt (and the cmakelists file is added by dolphin in the first place), I don't think this is a problem. In my opinion, it's better to use the same assert window for everything, rather than have the default assert/retry/ignore one appear sometimes.Examples by removing the call to
ImGui::CreateContext()
inRenderer::InitializeImGui
:Before:
After:
I did attempt to avoid the direct dependency by declaring a global variable in
imconfig.h
to be modified, but that failed becauseimconfig.h
is included in multiple locations.Failed patch