Setting up Visual Studio to compile Ingnomia under Windows

Back in 2014, I really had fun with Gnomoria. I have 443.4 hours of playtime, and it made me sad when I found out that the original dev abandoned the project. That's when I learned of Ingnomia, an open source project to continue its legacy.

Now I also learned that Ingnomia's development seem to have stalled. So I decided to work on some improvements on my own, so maybe the community will get motivated yet again.

Gemini suggested that I tried to swap Noesis GUI, which is non-free, for Dear ImGui, which is open source. Setting up Ingnomia project for development is a pain due to Noesis requiring a trial key to work with it. And I naively thought that was the only issue with Noesis.

The first issue I ran into was setting up project dependencies. Qt requires you to sign up to download libraries, which is quite frustrating. I learned that you can download and compile them using vcpkg, so that's what I decided to do.

mkdir build

cd build 

cmake .. -A x64 -DCMAKE_TOOLCHAIN_FILE="D:/Documents/Projetos/vcpkg/scripts/buildsystems/vcpkg.cmake" 

However, getting the build to work wasn't as straightforward as just pointing to the toolchain. Since I usually code on Linux, wrestling with Windows build systems, proprietary SDK structures, and MSVC compiler quirks was a whole different beast. Here is a summary of the hurdles I had to overcome to get the project compiling:
1. The Missing SDKs (Steam and OpenAL)
The project relies on the official Steamworks SDK for features like achievements and cloud saves. Since these aren't managed by vcpkg, I had to download the SDK zip manually from Valve and explicitly map the inclusion and library paths in the CMake command. The same went for OpenAL (Open Audio Library), which handles the 3D positional audio. Fortunately, OpenAL-Soft was available via vcpkg, so a quick vcpkg install openal-soft:x64-windows did the trick.
2. The NoesisGUI Trap: Licensing and Version Incompatibility
This was the real "boss fight" of the day. Modern versions of Visual Studio (I am running VS 2025/2026 internally) immediately choked on the legacy source code.
First, the original developer placed a hard static_assert check inside the code to block the compilation if a proprietary NOESIS_LICENSE_KEY wasn't provided. I had to go into the header files and comment out that assertion to bypass the cloud-licensing roadblock for local development.
Second, the Noesis SDK structure has completely changed over the years. Headers like NsApp/DelegateCommand.h and rendering frameworks were buried deep inside recursive subdirectories that the old CMake configuration didn't know existed. I had to write a custom, recursive globbing script inside the root CMakeLists.txt to automatically scan and inject all Noesis headers and .lib import files into the compiler.
3. Fighting the Linker: Precompiled Headers and Missing Symbols
Even after getting all .cpp files to compile, the linker threw a fit with multiple unresolved external symbols. It turns out modern Noesis versions provide their App Framework as raw source code rather than pre-compiled .lib files.
While trying to fix this by creating a minimal Qt adapter (imgui_impl_qt), I bumped into MSVC's error C1010 regarding Precompiled Headers (PCH). Windows development enforces that every single source file must explicitly include the precompiled header at the very first line of code—a major workflow cultural shock coming from Linux!
Deciding to Cut the Dead Weight
At this stage, fighting a non-free, closed-source GUI framework just to keep legacy menus alive felt like swimming against the current. Since the goal is a complete migration to Dear ImGui, maintaining retrocompatibility with a changing proprietary SDK became a massive bottleneck.
So, I made a pragmatic engineering decision: tear NoesisGUI out completely.
I scrubbed its presence from the root CMakeLists.txt, decoupled it from the main execution threads, and silenced its legacy calls inside mainwindow.cpp.
Next step

Now we have to make the compiler generate a clean, unencumbered Ingnomia.exe binary. Code referencing the old proprietary UI framework must be erased, so we can have the OpenGL 4.3 rendering context active, with Dear ImGui successfully linked and running.

There is still a ton of dead, orphaned C++ interface code inside the directory tree that needs to be systematically deleted, but we'll need to revisit those sources to build our ImGui components anyway. Next time, I'll be focused on making it compile, and setting up the first rendering frames of our new open-source interface overlay.

Stay tuned for the revival!

 

Comentários