Windows support, live settings, edge scrolling and GUI scaling

AGENTS.md

@@ -0,0 +1,85 @@
+# Project context for future sessions
+
+## Language
+
+Communicate with the user in German.
+Write and maintain all project documentation in English.
+Use English for Git-related text, including commit messages, pull request titles,
+descriptions and review comments.
+
+## Project setup
+
+Always implement new requirements on the user's latest complete fork state,
+including all newer fork commits, local work and project documentation. Never
+start implementation work directly from `upstream` unless the user explicitly
+overrides this rule. Use `upstream` only to compare changes and to assemble a
+separate contribution branch after the fork implementation has been completed
+and reviewed.
+
+Before working on this project, read:
+
+1. [Windows environment and current status](docs/development/WINDOWS-DEV-SETUP.md).
+2. [Configure and build commands](docs/development/BUILDING.md).
+3. [Development documentation index](docs/development/README.md); follow the
+   workflow and task notes when relevant to the request.
+
+Windows development is organized on `feature/windows-support` in this fork.
+The related work is split into a local branch stack: `feature/windows-support`,
+`fix/dynamic-shadows`, `fix/settings-option-duplicates`, `feature/live-settings`,
+`feature/progressive-edge-scrolling`, `docs/improvement-roadmap`, then
+`feature/gui-scaling`. Continue each task from the latest complete fork state; see
+[live settings and verification](docs/development/LIVE-SETTINGS.md).
+Read the current setup in [the contribution workflow](docs/development/CONTRIBUTING-WORKFLOW.md)
+before Git operations: `origin` is the fork and `upstream` is the original project.
+Preserve the existing default branch; continue each task on its own work branch.
+The work branch includes local notes and is not the final upstream PR branch;
+assemble that separate contribution branch later using only the reviewed,
+reusable changes.
+Do not push without explicit user authorization.
+
+The Windows prerequisites are already installed in `C:\Users\mario\od-deps`;
+their sources, binaries and logs deliberately live outside the repository.
+The maintained instructions and scripts live in this repository under
+`docs/development/` and `scripts/win32/`.
+Do not rely on the old copies in `build/` or `od-deps/setup-scripts/`.
+
+At the verified state on 2026-09-05, dependency builds, game CMake configuration
+and both Windows x64 game builds (Release and Debug) succeeded.
+User startup attempts exposed a Windows resource-path bug; both binaries now
+include its correction. A subsequent Release run loaded the main-menu scene and
+shut down normally without the earlier loading errors; the user subsequently
+confirmed that the Release executable starts without errors.
+That confirmation predates enabling dynamic shadows: a later startup failure was
+traced to OGRE's internal shadow programs being registered only in Graphics.
+The resource template now also exposes Media/Main through OgreInternal while
+retaining Graphics access for shader includes; the headless OGRE resource test
+fails before and passes after this correction, and the user's 14:52 run reached
+the main menu with shadows enabled. That run later failed while entering
+TestLegacyNoScripts.level. Added exception logging captured the cause during the
+user's 15:05 reproduction: automatic additive illumination splitting removed
+DirtInstanced's fragment shader, which GL3Plus requires. RenderManager now uses
+integrated additive texture shadows to retain the custom shader passes. Release
+and Debug rebuilt successfully; the isolated OGRE pass test fails with splitting
+and passes without it. The user must still retest the map and shadow appearance
+with the rebuilt executable; check the latest evidence in the startup notes.
+Read [startup failures and verification](docs/development/WINDOWS-STARTUP-FIXES.md)
+before investigating further startup issues; broader gameplay tests and packaging
+remain unverified.
+The Release executable now has its runtime DLLs staged beside it for direct
+File Explorer startup; the configuration script maintains this through
+`scripts/win32/prepare-windows-runtime.ps1`. Python's standard library and OGRE
+media still use the external installation. Read BUILDING.md for the static
+verification results and the remaining Debug runtime/plugin limitations.
+Read the [Windows build fixes](docs/development/WINDOWS-BUILD-FIXES.md) for the four
+diagnosed failures and verification logs; the CEGUI source now includes a
+repository-managed compatibility patch applied by its installation script.
+Read the current status document and check the actual files before making claims.
+Do not reinstall dependencies or switch versions just because a new session starts.
+Use the repository's environment helper and configuration script; the scripts
+currently target Mario's Windows installation, with paths recorded in the docs.
+
+Keep changes within the user's request and preserve existing work.
+Do not read `.env` or other secret files.
+Manual game tests, QA and visual acceptance are performed by the user.
+When changing setup paths, versions, commands or verified build status, update the
+linked documentation in the same task so the next session has the current state.

CMakeLists.txt

@@ -514,6 +514,9 @@ ENDIF ()
 # Adds the Windows icon resource file when building on windows.
 IF (WIN32)
     SET(OD_SOURCEFILES ${OD_SOURCEFILES} ${CMAKE_SOURCE_DIR}/dist/icon.rc)
+    IF (MSVC)
+        SET(OD_SOURCEFILES ${OD_SOURCEFILES} ${CMAKE_SOURCE_DIR}/dist/opendungeons.manifest)
+    ENDIF ()
 ENDIF ()
 
 ##################################
@@ -569,7 +572,7 @@ if(WIN32 AND ${OGRE_FOUND})
 
     find_package(Boost REQUIRED COMPONENTS ${OD_BOOST_COMPONENTS})
     if(Boost_FOUND)
-        set(OD_BOOST_LIB_DIRS  ${Boost_INCLUDE_DIRS}/stage/lib)
+        set(OD_BOOST_LIB_DIRS  ${Boost_LIBRARY_DIRS})
         set(OD_BOOST_INCLUDE_DIRS ${Boost_INCLUDE_DIRS})
     endif()
 else()
@@ -661,6 +664,12 @@ target_link_libraries(
 
 target_link_libraries(opendungeons-plus pybind11::embed)
 
+if(MSVC AND PYTHON_DEBUG_LIBRARY AND NOT PYTHON_IS_DEBUG)
+    # Keep pybind11's headers consistent with the selected debug Python library.
+    # Python's Windows header defines Py_DEBUG without a value as well.
+    target_compile_definitions(${PROJECT_BINARY_NAME} PRIVATE "$<$<CONFIG:Debug>:Py_DEBUG=>")
+endif()
+
 # Set linker options in MSVC
 if(WIN32 AND MSVC)
     # We need to force output because of the boost lib used, defining two times the
@@ -962,4 +971,3 @@ elseif(WIN32)
     install(FILES ${EXT_LIBS}
             DESTINATION ${OD_BIN_PATH})
 endif()
-

README.md

@@ -40,6 +40,14 @@ You will find us on the following channels:
 
 ### Build instructions
 
+For this fork's local Windows setup, see the maintained
+[development environment](docs/development/WINDOWS-DEV-SETUP.md) and
+[configure/build commands](docs/development/BUILDING.md), including verified status.
+Diagnosed Windows compiler and linker failures are recorded in the
+[build fixes and validation notes](docs/development/WINDOWS-BUILD-FIXES.md).
+Direct Windows startup and its verification are covered in the
+[startup fixes](docs/development/WINDOWS-STARTUP-FIXES.md).
+
 If you retrieve the source code of OpenDungeonsPlus and want to have a go at
 building it yourself, have a look at platform-specific build instructions
 on our wiki: https://github.com/OpenDungeons/OpenDungeons/wiki/Compile

cmake/config/resources.cfg.in

@@ -12,6 +12,11 @@ FileSystem=models
 FileSystem=particles
 FileSystem=shaders
 
+# Internal shadow programs must also be visible to OGRE's global resource pool.
+# Keep Main in Graphics above for game shader includes with strict group lookup.
+[OgreInternal]
+FileSystem=@CMAKE_INSTALL_PREFIX@/share/OGRE/Media/RTShaderLib/../Main
+
 [GUI]
 FileSystem=gui
 FileSystem=gui/fonts

dist/icon.rc

@@ -1 +1,5 @@
 1 ICON "OD-Logo.ico"
+
+#ifdef __GNUC__
+1 24 "opendungeons.manifest"
+#endif

dist/opendungeons.manifest

@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
+  <application xmlns="urn:schemas-microsoft-com:asm.v3">
+    <windowsSettings>
+      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
+      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, PerMonitor</dpiAwareness>
+    </windowsSettings>
+  </application>
+</assembly>

docs/development/BUILDING.md

@@ -0,0 +1,208 @@
+# Configuring and compiling on Windows
+
+For the completed `feature/live-settings` work, see [LIVE-SETTINGS.md](LIVE-SETTINGS.md)
+for its build and runtime evidence. The baseline startup verification below
+predates those settings changes.
+
+As of September 5, 2026. The [prerequisites](WINDOWS-DEV-SETUP.md) are installed
+and CMake and the Windows x64 game builds in Release and Debug have
+completed successfully; the user's startup attempts exposed a resource-path error,
+which has been corrected and rebuilt; a subsequent run reached the main-menu scene
+and shut down normally, and the user confirmed that Release starts without errors.
+The four resolved build errors and their evidence are recorded in
+[WINDOWS-BUILD-FIXES.md](WINDOWS-BUILD-FIXES.md).
+The startup evidence and subsequent correction are recorded in
+[WINDOWS-STARTUP-FIXES.md](WINDOWS-STARTUP-FIXES.md).
+
+## 1. Prepare the PowerShell session
+
+In a new PowerShell console:
+
+```powershell
+Set-Location -LiteralPath 'C:\Users\mario\GitHub\OpenDungeonsPlus'
+. .\scripts\win32\Enter-OpenDungeonsPlus.ps1
+```
+
+The dot at the start loads the compiler and search paths into the same session;
+then configure and build in this console. CMake 3.31.8,
+Python 3.10.11 and the x64 compiler from Visual Studio 2022 Build Tools are expected.
+
+Some automated shells provide both `PATH` and `Path`. MSBuild then fails before
+starting `CL.exe` with `System.ArgumentException: An item with the same key has
+already been added`. Normalize the process environment before loading the helper:
+
+```powershell
+$taskCurrentPath = $env:Path
+[System.Environment]::SetEnvironmentVariable('PATH', $null, 'Process')
+[System.Environment]::SetEnvironmentVariable('Path', $taskCurrentPath, 'Process')
+Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
+. .\scripts\win32\Enter-OpenDungeonsPlus.ps1
+```
+
+This changes only the current build process. A normal PowerShell console with one
+path variable does not need this step.
+If needed, check without building:
+
+```powershell
+Get-Command cl.exe, cmake.exe, python.exe | Select-Object Name, Source
+cmake --version
+python --version
+```
+
+## 2. Configure CMake
+
+```powershell
+& .\scripts\win32\configure-windows-prereqs.ps1
+```
+
+The script also loads the environment helper itself and uses:
+
+- Source: project root, derived from the script path.
+- Build directory: `build\windows`.
+- Generator: `Visual Studio 17 2022`, architecture `x64`.
+- `OD_BUILD_TESTING=OFF` and `BUILD_TESTING=OFF`.
+- Installation target: `build\windows\install`.
+- Python under `C:\Users\mario\AppData\Local\Programs\Python\Python310`:
+  `python.exe`, `include`, `libs\python310.lib`, `libs\python310_d.lib`.
+
+The configuration log is replaced on every invocation:
+`C:\Users\mario\od-deps\logs\opendungeons-configure.log`.
+On errors, the script prints the last lines and aborts.
+Reconfigure after changes to CMake files or source lists;
+for ordinary changes to existing C++ files, use the existing build.
+
+## 3. Build the game
+
+Release from the same prepared console:
+
+```powershell
+cmake --build .\build\windows --config Release --parallel 4
+if ($LASTEXITCODE -ne 0) { throw 'Release game build failed' }
+& .\scripts\win32\prepare-windows-runtime.ps1
+```
+
+After changing a class layout in a header, or after an interrupted rebuild, create
+the next test executable with a clean build so that no object file can retain the
+previous layout:
+
+```powershell
+cmake --build .\build\windows --config Release --target opendungeons-plus --clean-first --parallel 4
+if ($LASTEXITCODE -ne 0) { throw 'Clean Release game build failed' }
+& .\scripts\win32\prepare-windows-runtime.ps1
+```
+
+Keep the game and its error dialogs closed while preparing the runtime. CMake
+can regenerate `resources.cfg` during a build and restore paths that do not exist
+in this local Windows installation. Run runtime preparation after the successful
+Release build, including a clean build, before handing the executable to the user.
+The September 5 GUI-scaling startup failure from this omitted step is recorded in
+[startup fixes](WINDOWS-STARTUP-FIXES.md#resource-path-regression-after-the-gui-scaling-clean-build).
+
+For Debug instead:
+
+```powershell
+cmake --build .\build\windows --config Debug --parallel 4
+if ($LASTEXITCODE -ne 0) { throw 'Debug game build failed' }
+```
+
+The successfully generated output files are
+`build\windows\opendungeons-plus.exe` and `build\windows\opendungeons-plus_d.exe`,
+directly in the build directory. Both files were checked for their AMD64 PE signature and
+the corresponding Python DLL without starting the game.
+The build output appears in the console; if an error occurs, record the first specific
+compiler/linker message and the configuration used.
+The logged successful verification runs for this setup are located
+under `build\windows\game-Release-pass3.log` and `game-Debug-pass3.log`.
+
+## 4. Direct Release startup and manual verification
+
+For the current local setup, double-click
+`C:\Users\mario\GitHub\OpenDungeonsPlus\build\windows\opendungeons-plus.exe`
+in File Explorer; no PowerShell session is needed to test the Release build.
+Keep the executable in that directory with its DLLs, configuration and resource links.
+The files have been prepared and checked, and the executable includes the fix for
+absolute Windows resource paths. The 14:07 startup logs confirm main-menu scene
+loading and normal shutdown without the earlier loading errors; the user then
+confirmed an error-free direct startup on September 5, 2026.
+That confirmation predates the dynamic-shadow startup failure. The resource
+template now also registers OGRE's `Media/Main` in `OgreInternal`, while retaining
+its `Graphics` entry for game shader includes; the user's subsequent run reached
+the main menu with shadows enabled, as recorded in
+[startup fixes](WINDOWS-STARTUP-FIXES.md).
+The corrected configuration has been generated beside the executable and passed
+the isolated OGRE resource test; no C++ rebuild is needed for this template change.
+The user's later Legacy test-map reproduction identified a fragment shader removed
+by OGRE's automatic illumination splitting. RenderManager now selects integrated
+additive texture shadows, preserving the existing custom shader passes. Release
+and Debug rebuilt successfully; the isolated OGRE pass test reproduces the missing
+fragment programs with splitting and retains the original pass without it.
+The Release executable is ready for the user to retest the same map with shadows
+enabled; gameplay and shadow appearance have not yet been verified after this fix.
+Build logs: `game-Release-integrated-shadows.log` and
+`game-Debug-integrated-shadows.log` under `build/windows`.
+
+The configuration script now calls
+[prepare-windows-runtime.ps1](../../scripts/win32/prepare-windows-runtime.ps1).
+It copies 20 installed Release library/plugin DLLs and the two Python runtime DLLs
+next to the executable, and replaces the generated Unix-style OGRE media paths
+with the existing Windows installation's `Media/RTShaderLib`,
+`Media/RTShaderLib/GLSL` and `Media/Main` directories.
+The missing HLSL, HLSL_Cg and materials subdirectories are not registered.
+The other game resource entries and their existing junctions are preserved.
+
+The generated `python310._pth` points to the existing Python installation, its
+`Lib` and `DLLs` directories and the executable directory, with `import site` enabled;
+Python documents this application-local module path mechanism in
+[Finding modules on Windows](https://docs.python.org/3.10/using/windows.html#finding-modules).
+This is a local development setup: OGRE media and the Python standard library
+still reside outside the repository, and the installed Visual C++ runtime is used.
+It is not a standalone distribution package.
+
+If dependencies change or CMake regenerates the resource configuration outside
+the configuration script, refresh the prepared files with:
+
+```powershell
+powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\win32\prepare-windows-runtime.ps1
+```
+
+The execution-policy option applies only to that process; it does not change the
+system's policy. The setup has already been performed for the current Release executable.
+
+As of September 5, 2026, static checks covered the executable and 22 DLLs,
+all four configured OGRE plugins and all 14 resource directories, with no missing
+DLL dependencies or incorrect CPU architectures; evidence is stored in
+`build\windows\runtime-validation.json`. These checks do not start the game.
+
+Debug still requires the prepared development environment; its direct-start
+runtime files have not been staged. An optional console startup from the loaded
+environment is:
+
+```powershell
+Push-Location -LiteralPath .\build\windows
+try {
+    & .\opendungeons-plus_d.exe
+} finally {
+    Pop-Location
+}
+```
+
+The Debug startup command has not been verified in practice; its generated
+`plugins_d.cfg` still names the Release variants of Codec_STBI and RenderSystem_GL3Plus,
+so Debug plugin selection needs correction before its startup can be considered ready.
+If a startup error occurs, record the actual message for diagnosis.
+The user performs manual game tests and visual acceptance.
+
+## Logs and resuming work
+
+- Current installation and verification status: [WINDOWS-DEV-SETUP.md](WINDOWS-DEV-SETUP.md).
+- Library logs: `C:\Users\mario\od-deps\logs\<name>-configure.log`,
+  `<name>-Release.log`, `<name>-Debug.log`; Boost uses
+  `boost-bootstrap.log` and `boost-build.log`.
+- Rebuild dependencies only when actually needed, following
+  [WINDOWS-PREREQUISITES.md](WINDOWS-PREREQUISITES.md).
+
+`build` is excluded from Git and contains generated files;
+`build\windows` also contains directory junctions to project resources.
+Take these junctions into account when cleaning up and do not delete source directories through them.
+After a new result, add the date, configuration used, error or success
+and remaining checks to the Windows status document.