Skip to content

Windows sdl#7

Closed
fbraz3 wants to merge 59 commits intomainfrom
windows-sdl
Closed

Windows sdl#7
fbraz3 wants to merge 59 commits intomainfrom
windows-sdl

Conversation

@fbraz3
Copy link
Owner

@fbraz3 fbraz3 commented Mar 4, 2026

  • Copilot revision
  • Manual builds - all OS
  • Manual run tests - all OS
    • MacOS
    • Linux
    • Windows

GeneralsX Developer added 29 commits February 26, 2026 23:32
… Complete

Complete setup for win64-modern preset enabling cross-platform backend stack on Windows.

Changes:
- CMakePresets.json: Added win64-modern and win64-modern-debug presets
- cmake/openal.cmake: NEW - FetchContent kcat/openal-soft 1.24.2 with WASAPI backend
- cmake/dx8.cmake: Triple-path architecture (DX8 native / DXVK headers / DXVK native)
- cmake/sdl3.cmake: Platform guards for Wayland/X11 (Linux) and DirectX/WASAPI (Windows)
- cmake/config-build.cmake: Updated SDL3/OpenAL descriptions (cross-platform)
- windows_compat.h: Pre-guards for DXVK headers (both Linux and Windows+DXVK)
- SDL3GameEngine.cpp/h: Converted #ifndef _WIN32 to #ifdef SAGE_USE_SDL3
- OpenALAudioManager.cpp: Converted #ifndef _WIN32 to #ifdef SAGE_USE_OPENAL
- SDL3Mouse.h/SDL3Keyboard.h: Converted platform guards to semantic feature flags
- GeneralsMD/Code/Main/CMakeLists.txt: Updated source selection for SDL3Main.cpp on Windows
- SDL3Main.cpp: Guarded POSIX setenv() for Windows, removed top-level platform guard
- scripts/deploy_zh_modern.ps1: NEW - Deploy script for runtime DLLs (DXVK/SDL3/OpenAL/FFmpeg)
- .vscode/tasks.json: 10 new tasks for win64-modern workflow (configure/build/deploy/run)
- CMakeLists.txt: Added include for cmake/openal.cmake
- docs/DEV_BLOG/2026-02-DIARY.md: Session 55 entry - comprehensive Phase 6 completion

Infrastructure is complete and ready for first build/test cycle on Windows.

Acceptance Criteria: All 12 implementation steps completed successfully.
Next: Build and test on Windows with Vulkan SDK installed.
…ation

Scripts (Phase 6 Windows Modern Stack):
- configure_cmake_modern.ps1 - Configure CMake with win64-modern preset (DXVK+SDL3+OpenAL)
- build_zh_modern.ps1 - Build GeneralsXZH with optimal parallelization
- run_zh_modern.ps1 - Launch game with DLL verification and diagnostic logging
- pipeline_win64_modern.ps1 - Complete workflow (Configure → Build → Deploy → Run)
- README_WIN64_MODERN.md - Comprehensive guide for all win64-modern scripts

Documentation:
- docs/ETC/WINDOWS_BUILD_INSTRUCTIONS.md - Complete Windows build guide (matches Linux/macOS pattern)
  * Prerequisites (MSVC 2022, Vulkan SDK, CMake, Ninja)
  * Quick Start section with win64-modern recommended
  * Technology Stack comparison (Modern vs Legacy)
  * Build Configuration with step-by-step commands
  * Runtime Deployment guide
  * Running the game
  * Troubleshooting section
  * Developer mode and performance optimization

All scripts follow the established pattern from old-main-sdl2 branch with:
- Colored console output for better UX
- Comprehensive error handling and validation
- Logging to logs/ directory
- Next-step hints for workflow continuity
- MSVC environment setup integration
- DLL verification before launch

Inspiration: old-main-sdl2 branch scripts, adapted for win64-modern preset
REMOVED:
- All 15 legacy VC6 and win32 build tasks
- Old inline cmake calls for configuration/build

REPLACED WITH:
- Configure (Windows win64-modern DXVK+SDL3+OpenAL) → configure_cmake_modern.ps1
- Build GeneralsXZH (win64-modern) → build_zh_modern.ps1
- Build GeneralsX (win64-modern) → build_zh_modern.ps1 -Generals
- Deploy GeneralsXZH (win64-modern) → deploy_zh_modern.ps1 -Preset win64-modern
- Deploy GeneralsX (win64-modern) → deploy_zh_modern.ps1 -Preset win64-modern -Generals
- Run GeneralsXZH (win64-modern windowed) → run_zh_modern.ps1
- Run GeneralsX (win64-modern windowed) → run_zh_modern.ps1 -Generals
- Pipeline: Configure→Build→Deploy→Run (win64-modern ZH) → pipeline_win64_modern.ps1
- Pipeline: Configure→Build→Deploy→Run (win64-modern Generals) → pipeline_win64_modern.ps1 -Generals

Benefits:
- Cleaner, more declarative task definitions
- Direct integration with new build scripts
- Consistent colored output and logging
- All error handling in scripts, not in tasks
- Easier to maintain and update

All tasks now use shell type for simplicity and PowerShell execution
Fixed path resolution issues in:
- configure_cmake_modern.ps1
- build_zh_modern.ps1
- pipeline_win64_modern.ps1

Changed from relative paths (.\scripts\script.ps1) to \\script.ps1
This ensures scripts can be called from any working directory and properly
locate other PowerShell scripts in the same scripts/ folder.

\ is a PowerShell automatic variable containing the directory
of the currently executing script file.
This script sets up MSVC BuildTools environment variables for the current
PowerShell session, making cl.exe, rc.exe, and mt.exe available on PATH.

Sourced from origin/old-main-sdl2 branch as it's essential for the modern
build scripts to function correctly.

Usage:
  .\scripts\setup_msvc_buildtools_env.ps1
  .\scripts\setup_msvc_buildtools_env.ps1 -Arch x64 -HostArch x64
Windows DXVK version bumped to 2.7.1 with verified SHA256 hash:
- Previous: v2.6 with mismatched hash
- Updated: v2.7.1 (d85ce7c79f57ecd765aaa1b9e7007cb875e6fde9f6d331df799bce73d513ce87)

Source: https://github.com/doitsujin/dxvk/releases/download/v2.7.1/dxvk-2.7.1.tar.gz

Note: Linux native DXVK remains at 2.6-steamrt-sniper for now.
Will be updated separately if newer version is available.
Fixed CMake error: Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR)

Changes:
1. vcpkg.json: Added libpng as dependency (for Windows SDL3_image support)
2. cmake/sdl3.cmake: Updated PNG discovery logic
   - Linux: Use system libpng-dev via MODULE mode (explicit paths)
   - Windows: Use vcpkg's libpng via CONFIG mode with MODULE fallback

The issue was that SDL3_image requires libpng at build time. On Linux we have
system packages, but on Windows we need to declare it via vcpkg.

This matches the pattern used for other platform-specific dependencies in vcpkg.json
…tion

- GLM is header-only and should not be compiled by vcpkg
- Add CMAKE_MAKE_PROGRAM=ninja.exe to win64-modern presets to fix Ninja detection
- This resolves vcpkg GLM build failure and CMake configuration errors
- GLM is required by d3dx8_compat.cpp and CompatLib CMakeLists.txt
- Removed CMAKE_MAKE_PROGRAM to let vcpkg/CMake handle Ninja discovery normally
- This should resolve GLM build configuration errors
- Remove complex generator expressions from CMAKE_MSVC_RUNTIME_LIBRARY
- Use simple values: MultiThreadedDLL (release) and MultiThreadedDebugDLL (debug)
- Define CMAKE_TOOLCHAIN_FILE and CMAKE_MSVC_DEBUG_INFORMATION_FORMAT explicitly
- Fixes LNK1104 linker errors (MSVCRTD.lib, LIBCMT.lib not found)
- vcpkg now properly configures CRT linkage without conflicts
- Updates GLM and all dependencies to latest vcpkg registry versions
- New baseline includes fixes for header-only package handling
- Should resolve GLM compilation issues with MSVC toolchain
- GLM is header-only and doesn't need compilation
- vcpkg was trying to build GLM which failed with MSVC linker errors
- New cmake/glm.cmake fetches GLM 1.0.3 from GitHub as INTERFACE library
- Removed GLM from vcpkg.json to eliminate dependency conflicts
- CompatLib now includes glm.cmake and falls back gracefully
- GLI is header-only and was failing to build in vcpkg
- Both GLM and GLI now use FetchContent from GitHub
- New cmake/gli.cmake provides GLI as INTERFACE library
- Removed both GLM and GLI from vcpkg.json
- Now vcpkg only handles zlib and libpng (actual binary dependencies)
- Ninja single-config fails with vcpkg + VS BuildTools 2024 MSVC runtime linking
- Ninja Multi-Config handles multi-config builds better with MSVC toolchain
- This is what fighter19 uses successfully on Linux/macOS
- Now CMake will properly manage debug/release configurations
- Ninja/Ninja Multi-Config fail with VS BuildTools 2024 and stdlib linking
- Visual Studio generator handles MSVC toolchain and library paths correctly
- Standard Windows + vcpkg approach that's proven to work
- BuildTools are bundled with VS 2022 and properly configure stdlib libraries
- Removed zlib and libpng from vcpkg.json (project already has FetchContent for these)
- Changed win64-modern/win64-modern-debug to use NMake Makefiles generator
  (native to VS BuildTools, no Ninja complexity)
- CMake falls back to cmake/zlib.cmake and cmake/libpng.cmake automatically
- GLM and GLI still use FetchContent directly
- This eliminates vcpkg build failures while using available BuildTools tools
…only libs)

- Switched back to Ninja Multi-Config (handles multi-config better than NMake)
- vcpkg no longer tries to compile zlib/libpng (using project FetchContent instead)
- vcpkg only manages minimal packages now (no compilation needed)
- GMa/GLI via FetchContent, everything else via project's existing cmake/
- This should work because Ninja gets proper MSVC environment from VsDevCmd.bat
- VS 16 2019 is the standard generator for VS BuildTools version 18 (2026)
- Generator creates .sln and .vcxproj files natively without Ninja issues
- CMake controls full build process, no subprocesses with environment issues
- BuildTools has full MSBuild support for VS 16 2019 projects
- cmake --help confirms VS 17 2022 is available
- Removed space before SAGE_USE_DX8
- BuildTools should work with standard VS 2022 generator
- Will generate .sln/.vcxproj for MSBuild
Root cause: MSVC 14.44 installed but missing MSVCRTD.lib (incomplete install)
- configure_cmake_modern.ps1 now sets VCToolsVersion=14.50.35717 before cmake
- MSVC 14.50 has complete CRT libs (msvcrtd.lib confirmed present)
- Reverted presets from Visual Studio 17 2022 back to Ninja generator
- Added CMAKE_BUILD_TYPE and CMAKE_MSVC_DEBUG_INFORMATION_FORMAT back
- External CMake 3.31 has bug with Ninja 1.12 (rules.ninja not generated in TryCompile)
- VS BuildTools CMake 4.1.1 is fully compatible with bundled Ninja 1.12.1
- Configure script now prepends VS cmake/ninja to PATH before running cmake
- All three fixes combined: MSVC 14.50, VS cmake 4.1.1, vcpkg packages clean
…windows_compat.h

- Remove duplicate #ifndef _WIN32 guard (line 163 never closed, causing C1004 EOF errors)
- Add _MSC_VER guard for __fastcall macro (prevent MSVC redefinition warnings)
- Guard Linux-only includes (pthread.h, unistd.h, sys/time.h) with #ifndef _WIN32
- Simplify windows_base.h include guard to Linux-only (clear platform separation)
- Improve SDL3 WASAPI WinRT header path detection in cmake/sdl3.cmake

Phase 1 Preprocessor Fixes:
- Resolved C1004 'unexpected EOF' errors by fixing preprocessor directive mismatch
- Eliminated band-aid workarounds (commented code) in favor of real platform guards
- Validated all #ifndef/#ifdef/#endif balance (30 opens, 34 closes analyzed)

Note: Build now hits type definition ordering issues (PUCHAR undefined in bcrypt.h)
- Requires further analysis of include order in next session
- Preprocessor structure now correct and clean
…ds GeneralsXZH.exe)

GeneralsX @feature BenderAI 02/03/2026 - Phase 6: win64-modern DXVK+SDL3+OpenAL
Windows x64 build stack fully functional. generalszh.exe links and deploys.

## Build System
- CMakePresets.json: Add win64-modern preset (MSVC x64, DXVK+SDL3+OpenAL)
- CMakeLists.txt: Integrate sccache, GLI/GLM FetchContent, vcpkg x64-windows
- cmake/sdl3.cmake, openal.cmake, gli.cmake, glm.cmake, sccache.cmake: Win support
- cmake/dx8.cmake: DXVK win64 headers + prebuilt DLL path
- GeneralsMD/Code/Main/CMakeLists.txt: Fix OUTPUT_NAME (was inverted; now GeneralsXZH on all platforms)
- Generals/Code/Main/CMakeLists.txt: Fix OUTPUT_NAME to GeneralsX on all platforms

## Platform Guards (windows_compat.h, etc.)
- GeneralsMD/Code/CompatLib/Include/windows_compat.h: Unconditional MEMORYSTATUS/IUnknown guards; pthread/unistd inside #ifndef _WIN32
- GeneralsMD/Code/CompatLib/Include/windows_wrapper.h: Guard pthread includes for Windows
- GeneralsMD/Code/CompatLib/Include/types_compat.h: Guard SIZE_T/ssize_t/#includes for Windows
- GeneralsMD/Code/CompatLib/Include/string_compat.h: strlcpy now provided by wwdownload_compat.h on Win
- GeneralsMD/Code/CompatLib/Include/file_compat.h: Guard POSIX file macros for Windows
- GeneralsMD/Code/CompatLib/Include/gdi_compat.h: Guard GDI stubs for Windows

## WWDownload MSVC Fixes
- Core/Libraries/Source/WWVegas/WWDownload/wwdownload_compat.h: NEW - strlcpy/strlcat/ARRAY_SIZE polyfills, ws2tcpip.h (socklen_t)
- Core/Libraries/Source/WWVegas/WWDownload/ftp.h: winsock.h -> winsock2.h
- Core/Libraries/Source/WWVegas/WWDownload/FTP.cpp: Add windows.h, time.h, sys/stat.h includes on Win
- Core/Libraries/Source/WWVegas/WWDownload/Download.cpp: Add windows.h, timeapi.h (for timeGetTime)
- GeneralsMD/Code/Libraries/Source/WWVegas/WWDownload/CMakeLists.txt: z_wwdownload as STATIC with absolute sources

## FramGrab / VFW
- Core/Libraries/Source/WWVegas/WW3D2/FramGrab.cpp: VFW code guarded with ENABLE_FRAME_GRABBER; stubs for non-VFW builds
- Core/Libraries/Source/WWVegas/WW3D2/CMakeLists.txt: FramGrab.cpp path uses absolute CMAKE_CURRENT_SOURCE_DIR

## SDL3 / OpenAL Device
- GeneralsMD/Code/GameEngineDevice/Source/SDL3Device/GameClient/SDL3Mouse.cpp: Remove unused frame_offset (C4189)
- GeneralsMD/Code/GameEngineDevice/Source/SDL3Device/GameClient/SDL3Keyboard.cpp: Remove outer #ifndef _WIN32 wrapper
- GeneralsMD/Code/Main/SDL3Main.cpp: Add #ifdef _WIN32 SDL_main.h (WinMain via SDL3.dll)
- Core/Libraries/Source/WWVegas/CMakeLists.txt: WWDownload unconditional (was UNIX-only)

## Deploy & Run Scripts
- scripts/deploy_zh_modern.ps1: Fix \ (build root _deps, not subdir); remove d3d12.dll (not in DXVK package)
- scripts/run_zh_modern.ps1: Use GeneralsXZH.exe
- scripts/build_zh_modern.ps1, configure_cmake_modern.ps1: Refined for MSVC BuildTools

## Debug / Profile (Windows guards)
- Core/Libraries/Source/debug/debug_debug.cpp/.h: Windows-compatible debug stack
- Core/Libraries/Source/debug/debug_except.cpp, debug_stack.cpp: Guard POSIX APIs
- Core/Libraries/Source/profile/profile.cpp: Guard Linux timing

## Docs
- docs/DEV_BLOG/2026-03-DIARY.md: Session 58-60 entries (Windows Phase 6 build success)
- docs/WORKDIR/lessons/2026-03-LESSONS.md: Lessons 5-12 from Windows SDL3 porting
- Core/Libraries/DX90SDK/Lib/x64/d3d8.lib: Add x64 lib for DXVK validation builds
@fbraz3 fbraz3 requested a review from Copilot March 4, 2026 04:17
GeneralsX Developer and others added 8 commits March 4, 2026 18:24
DWORD is not guaranteed to be defined when types_compat.h is included
directly (e.g. module_compat.cpp includes it before windows_compat.h).
stdint.h is already included above, so uint32_t is always available.

// GeneralsX @BugFix fbraz3 04/03/2026 COLORREF typedef: DWORD -> uint32_t
brew install glm installs GLM system-wide at /opt/homebrew/share/glm/,
which conflicts with the FetchContent-managed GLM in cmake/glm.cmake.
When vcpkg's cmake wrapper calls _find_package(glm), CMake finds the
Homebrew version (defines glm::glm) but not glm::glm-header-only,
causing:
  'Some (but not all) targets in this export set were already defined.
   Targets Defined: glm::glm; Targets not yet defined: glm::glm-header-only'

GLM must only come from FetchContent (tag 1.0.3) as configured in
cmake/glm.cmake. Also removed the now-misleading glmConfig.cmake check.

// GeneralsX @BugFix fbraz3 04/03/2026 Remove brew GLM to prevent FetchContent target conflict
…mpat.h for non-Windows

time_compat.h uses DWORD and BOOL but only includes types_compat.h directly,
without going through windows_compat.h/bittype.h which define these types.
On Linux/macOS, this caused compilation errors:
  'DWORD' does not name a type (time_compat.h:34, :37, :41)
  'BOOL' does not name a type (time_compat.h:56, :66)

Add all basic Win32 types (DWORD, WORD, BYTE, UINT, ULONG, BOOL, LPCSTR, USHORT)
to types_compat.h under #ifndef _WIN32 with #ifndef guards, matching the existing
COLORREF pattern. On Windows, bittype.h remains authoritative (no conflict).

// GeneralsX @BugFix fbraz3 04/03/2026 Add missing Win32 type defs to types_compat.h
…cal typedef redefinition

The previous fix used 'unsigned long' for ULONG, but on Linux/macOS x86_64
'unsigned long' is 64-bit while bittype.h uses 'uint32_t' (32-bit). C++11
allows identical typedef redefinition but not conflicting ones, causing:

  macOS: typedef redefinition with different types ('unsigned long' vs 'uint32_t')
  Linux: conflicting declaration 'typedef long unsigned int ULONG'

#ifndef guards do not prevent typedef conflicts (they only check macros).
The fix is to mirror bittype.h's exact types so that when both headers are
included in the same translation unit, the redefinitions are identical:
  DWORD/ULONG -> uint32_t  (not unsigned long, which is 64-bit on x86_64)
  WORD/USHORT -> unsigned short / uint16_t
  BYTE        -> unsigned char
  BOOL        -> int
  UINT        -> unsigned int
  LPCSTR      -> const char*

// GeneralsX @BugFix fbraz3 04/03/2026 Match bittype.h types exactly in types_compat.h
…file_compat

Three preventive fixes identified via static analysis:

1. gdi_compat.h: Add #include 'types_compat.h'
   HANDLE was used (HFONT, HDC, HBITMAP typedefs) with only <stdint.h> included.
   TUs including gdi_compat.h before windows_compat.h would fail with
   'HANDLE does not name a type'.

2. windows_compat.h: Remove static inline timeGetTime() duplicate
   windows_compat.h defined static inline timeGetTime() via gettimeofday, then
   included time_compat.h which declares extern timeGetTime(). Having both an
   extern declaration and a static inline definition in the same TU is a
   linkage conflict that Clang rejects. The authoritative implementation is in
   time_compat.cpp (CLOCK_BOOTTIME on Linux, mach_absolute_time on macOS).

3. file_compat.h: Guard INVALID_HANDLE_VALUE with #ifndef
   types_compat.h defines INVALID_HANDLE_VALUE as ((HANDLE)-1).
   file_compat.h redefined it as ((void*)-1) unconditionally. Already triggered
   a warning in Linux CI; -Werror would make this fatal.

// GeneralsX @BugFix fbraz3 04/03/2026 Prevent CompatLib header conflicts
Two root causes identified and fixed:

1. GLM target conflict (cmake configure error):
   - GeneralsMD/Code/CompatLib/CMakeLists.txt called find_package(glm/gli)
     after cmake/glm.cmake already created the targets via FetchContent.
   - vcpkg wrapper found system Homebrew GLM and tried to create glm::glm +
     glm::glm-header-only, but glm::glm already existed -> CMake error.
   - Fix: removed redundant find_package(glm/gli) calls; FetchContent targets
     are authoritative.

2. OpenAL architecture mismatch (arm64 linker error):
   - cmake/openal.cmake detected Homebrew openal-soft at /usr/local/opt which
     is Intel x86_64 Homebrew on Apple Silicon M-series Macs.
   - Linking arm64 binary against x86_64 libopenal.dylib produced:
     ld: symbol(s) not found for architecture arm64
   - Fix: migrated cmake/openal.cmake to use FetchContent for ALL platforms
     (Linux, macOS, Windows). FetchContent compiles openal-soft 1.24.2
     natively for the target architecture - always correct arm64 on Apple.
   - CI: removed brew install openal-soft (no longer needed).

Result: cmake --preset macos-vulkan + cmake --build both pass cleanly.
Binary confirmed: Mach-O 64-bit executable arm64 (14MB).
Replace legacy SuperHackers CI with GeneralsX-specific pipeline that:

1. Runs three parallel builds (no dependencies between jobs):
   - Linux (x86_64): linux64-deploy preset, ubuntu-latest
   - macOS (arm64): macos-vulkan preset, macos-latest
   - Windows (x64): win64-modern preset, windows-latest

2. Smart change detection via dorny/paths-filter@v3:
   - Detects changes in GeneralsMD, Core, cmake, CMakePresets.json
   - Skips build if only docs/comments/Generals changes (not priority yet)
   - Always runs on manual trigger (workflow_dispatch)

3. Unified pipeline for a single game (GeneralsMD/Zero Hour):
   - Focus on cross-platform correctness at CI level
   - Replay testing deferred until game is feature-complete
   - Smoke tests (headless gameplay) planned for future

4. Build status summary:
   - Generates GitHub step summary with platform status table
   - Fail-fast: any platform failure fails entire CI
   - Logs available as artifacts

This is a minimal, focused CI for the cross-platform port. Legacy
vc6/win32 presets (SuperHackers) are not tested in CI — that's for
the upstream baseline in .github/workflows/ci.yml.backup.

Future: integrate smoke tests, binary uploads, performance tracking.
Move all unused/legacy workflows to .github/workflows/old/:
  - build-historical.yml (legacy)
  - build-toolchain.yml (vc6/win32 presets, not in GeneralsX CI)
  - check-replays.yml (replay testing deferred)
  - validate-pull-request.yml (not used)
  - weekly-release.yml (not used)
  - ci.yml.backup (original SuperHackers CI for reference)
  - valid-tags.txt (legacy config)

Add README.md explaining the archived files and rationale.

Active workflows remain in root:
  - ci.yml (GeneralsX multi-platform CI)
  - build-linux.yml
  - build-macos.yml
  - build-windows.yml

This keeps the workflow directory clean and focused on current
GeneralsX cross-platform modernization efforts.
fbraz3 added 12 commits March 5, 2026 20:57
…sing gamespy

- Replace find -o *.dylib.so (no such files) with simple *.dylib search
- Use cp -L to dereference symlinks (libSDL3.dylib, libopenal.dylib etc.)
  so bundle always contains real files, not broken symlinks
- Make libgamespy.dylib copy fail-fast instead of silent warning
  (FetchContent builds it directly in binaryDir, not under _deps)

GeneralsX @BugFix felipebraz 05/03/2026 Fix macOS CI dylib bundling for symlinks and gamespy"
- Add find+copy for openal_soft-build/*.so* (libopenal.so missing from bundle)
- Add libopenal.so* to fail-fast validation on Linux
- Add libopenal.1.dylib to fail-fast validation on macOS (consistency)

GeneralsX @BugFix felipebraz 05/03/2026 Bundle OpenAL in Linux and validate across platforms
…3_image path

- Add diagnostic step listing all *.dll under build tree (replaces manual find)
- Copy gamespy.dll via Get-ChildItem -Recurse (same pattern as macOS/Linux)
- Replace hardcoded SDL3_image path with Get-ChildItem -Recurse (handles case)
- Add gamespy.dll to fail-fast validation

GeneralsX @BugFix felipebraz 05/03/2026 Bundle gamespy.dll and add DLL diagnostics on Windows
On macOS, files extracted from a downloaded archive receive the
com.apple.quarantine extended attribute, forcing Gatekeeper to
prompt approval for the binary AND each dylib individually.

Fix: on first launch run.sh removes quarantine recursively then
ad-hoc signs all dylibs + executable. No paid Developer ID needed.

GeneralsX @BugFix felipebraz 05/03/2026 Strip quarantine and ad-hoc sign macOS bundle on launch
GamespySDK CMakeLists sets BUILD_SHARED_LIBS=OFF by default.
On Windows the preset does not override this, so gamespy compiles
as a static .lib linked directly into the executable.

Remove gamespy.dll copy fail-fast; keep as optional/informational.
Update validation comment to document this platform difference.

GeneralsX @BugFix felipebraz 05/03/2026 Remove gamespy.dll from Windows bundle (statically linked)
…ploy scripts

- build-macos.yml: copy all dylibs directly to RUNTIME_DIR/ (no lib/ subdir),
  update MoltenVK ICD path, fix validation and ls output
- build-linux.yml: same flat layout, remove lib/ mkdir from all copy steps,
  fix validation globs
- run-bundled-game.sh: update DYLD_LIBRARY_PATH, LD_LIBRARY_PATH, VK_ICD_FILENAMES
  and codesign find path to use SCRIPT_DIR directly (no lib/ subdir)
- deploy-macos-zh.sh: replace fragile hardcoded DXVK/SDL3_image paths with
  find+cp-L over _deps/; fix dxvk.conf source path (was GeneralsMD/Run/dxvk.conf,
  correct path is project root dxvk.conf)
- deploy-linux-zh.sh: add OpenAL copy step (openal_soft-build) matching CI bundle

GeneralsX @BugFix BenderAI 06/03/2026 Flat layout: all runtime libs next to binary
…il_env.cpp

The str.replace() for adding getExePath()'s macOS branch was silently failing
because blank lines between } and void setThreadName have 2-space trailing
indentation ("  \n  \n") in the DXVK source, not bare newlines ("\n\n").

Switch to re.sub() with [ \t]* wildcard on blank lines so the replacement
matches regardless of trailing whitespace in future DXVK source updates.

Root cause of crash: dxvk::env::getExeName() -> getExePath() had no __APPLE__
branch, compiler inserted brk #1 (UB trap) at function entry on ARM64 macOS.
Binary images in crash report confirmed all dylibs loaded correctly (flat layout
works) but collapsed immediately into SIGTRAP inside DXVK initialization.

GeneralsX @BugFix BenderAI 05/03/2026 Fix DXVK getExePath macOS branch patch
// GeneralsX @BugFix fbraz3 11/07/2025 Add explicit idempotency guards to
// patches 1, 2, 5, and 9 in dxvk-macos-patches.py. Root cause: str.replace()
// and re.sub() would re-apply when 'old' is a substring of 'new', causing
// triple-application across consecutive CMake configure runs.
//
// Patch 1 (util_win32_compat.h): guard on '|| defined(__APPLE__)' presence
// Patch 2 (util_env.cpp): guard on 'pthread_setname_np(posixName.data());'
// Patch 5 (meson.build x5): guard on \"if platform != 'darwin'\" presence
// Patch 9 (dxvk_adapter.cpp): guard on 'VK_ENABLE_BETA_EXTENSIONS' presence
// GeneralsX @BugFix fbraz3 06/03/2026 Patch 6 (getExePath macOS branch) was
// inserting #elif defined(__APPLE__) AFTER the closing #endif of the original
// #if/_WIN32/#elif __linux__/#elif __FreeBSD__ chain, producing a dangling
// '#elif without #if' compile error (5 errors in util_env.cpp).
//
// Root cause: regex captured \1 = "#endif\n  }" and preserved it, then added
// #elif after — creating the orphaned #elif. Fix: consume the old #endif in
// the match and emit #elif...#endif at the correct position instead.
Resolved files:
- CMakePresets.json: Integrates macos-vulkan + win64-modern presets
- cmake/config-build.cmake: Cross-platform options
- cmake/dx8.cmake: Platform-specific backends (VC6/Windows Modern/macOS/Linux)
- cmake/openal.cmake: Cross-platform OpenAL (Homebrew on macOS, FetchContent on Linux/Windows)
- cmake/sdl3.cmake: Platform-specific libpng handling
- .vscode/tasks.json: Uses main version (better process tasks structure)
- GeneralsMD/Code/Main/SDL3Main.cpp: Integrate glob.h include for Vulkan ICD
- docs/DEV_BLOG/2026-02-DIARY.md: Keeps main version

Result: windows-sdl branch now has all features from main (Phase 6 Windows Modern Stack)
while retaining Phase 5 macOS support.
# Conflicts:
#	.github/workflows/build-windows.yml
#	.vscode/tasks.json
#	Core/GameEngineDevice/CMakeLists.txt
#	GeneralsMD/Code/GameEngineDevice/CMakeLists.txt
#	cmake/dx8.cmake
#	cmake/openal.cmake
#	docs/WORKDIR/lessons/2026-03-LESSONS.md
#	scripts/build/macos/deploy-macos-zh.sh
Copilot AI review requested due to automatic review settings March 11, 2026 03:47
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 41 out of 549 changed files in this pull request and generated 5 comments.


// Includes
#include "d3d10.h"
#include "d3dx10.h"
Copy link

Copilot AI Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same issue as D3DX11: this looks like a self-include of the umbrella header (d3dx10.h). It’s redundant under include guards and makes include graphs harder to reason about. Remove it and keep only the intended subordinate includes.

Suggested change
#include "d3dx10.h"

Copilot uses AI. Check for mistakes.
Copy link

Copilot AI Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Providing an empty token can cause dorny/paths-filter to lose access to PR file lists (rate limits / missing permissions) and behave inconsistently. Prefer omitting the input (so it defaults) or set it explicitly to ${{ github.token }}.

Suggested change
token: ${{ github.token }}

Copilot uses AI. Check for mistakes.
Comment on lines 98 to 100
Copy link

Copilot AI Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These summary expressions don’t treat the skipped job result as a skip, so if should-build is false the build jobs will be skipped and the summary will incorrectly show ❌ Failed. Update the condition to consider skipped (and/or cancelled) as a non-failure status in the table output.

Suggested change
echo "| Linux (x86_64) | ${{ needs.build-linux.result == 'success' && '✅ Success' || (needs.build-linux.result == 'cancelled' || needs.build-linux.result == 'skipped') && '⏭️ Skipped' || '❌ Failed' }} |" >> $GITHUB_STEP_SUMMARY
echo "| macOS (arm64) | ${{ needs.build-macos.result == 'success' && '✅ Success' || (needs.build-macos.result == 'cancelled' || needs.build-macos.result == 'skipped') && '⏭️ Skipped' || '❌ Failed' }} |" >> $GITHUB_STEP_SUMMARY
echo "| Windows (x64/modern) | ${{ needs.build-windows.result == 'success' && '✅ Success' || (needs.build-windows.result == 'cancelled' || needs.build-windows.result == 'skipped') && '⏭️ Skipped' || '❌ Failed' }} |" >> $GITHUB_STEP_SUMMARY

Copilot uses AI. Check for mistakes.
Comment on lines +60 to +67
if (-not (Test-Path "C:\vcpkg\vcpkg.exe")) {
Write-Host "Cloning vcpkg from GitHub..."
git clone https://github.com/microsoft/vcpkg.git C:\vcpkg
git -C C:\vcpkg checkout ffc071e0c08432c60c9b64f00334c0227667931b
Write-Host "Running vcpkg bootstrap..."
& C:\vcpkg\bootstrap-vcpkg.bat -disableMetrics
} else {
Write-Host "Using cached vcpkg"
Copy link

Copilot AI Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When vcpkg is restored from cache, the workflow skips the git checkout pin entirely, so the cached vcpkg revision can drift from the intended commit. Consider always validating/pinning the vcpkg commit (even when cached), e.g., fetch + checkout the desired SHA, to keep builds reproducible.

Suggested change
if (-not (Test-Path "C:\vcpkg\vcpkg.exe")) {
Write-Host "Cloning vcpkg from GitHub..."
git clone https://github.com/microsoft/vcpkg.git C:\vcpkg
git -C C:\vcpkg checkout ffc071e0c08432c60c9b64f00334c0227667931b
Write-Host "Running vcpkg bootstrap..."
& C:\vcpkg\bootstrap-vcpkg.bat -disableMetrics
} else {
Write-Host "Using cached vcpkg"
# Ensure vcpkg repository exists (clone if missing)
if (-not (Test-Path "C:\vcpkg\.git")) {
Write-Host "Cloning vcpkg from GitHub..."
git clone https://github.com/microsoft/vcpkg.git C:\vcpkg
} else {
Write-Host "Using existing vcpkg checkout (possibly from cache)"
}
# Ensure vcpkg is at the expected pinned commit for reproducible builds
Write-Host "Ensuring vcpkg is at the expected commit..."
git -C C:\vcpkg fetch origin --tags --prune
git -C C:\vcpkg checkout --force ffc071e0c08432c60c9b64f00334c0227667931b
# Bootstrap only if the vcpkg executable is not present
if (-not (Test-Path "C:\vcpkg\vcpkg.exe")) {
Write-Host "Running vcpkg bootstrap..."
& C:\vcpkg\bootstrap-vcpkg.bat -disableMetrics
} else {
Write-Host "vcpkg executable already present; skipping bootstrap"

Copilot uses AI. Check for mistakes.
Comment on lines 128 to 131
Copy link

Copilot AI Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same reproducibility issue as the Windows workflow: if /opt/vcpkg is reused from cache, the pinned checkout won’t be applied and the vcpkg revision may differ from the intended SHA. Apply the checkout (or at least verify HEAD) even when vcpkg already exists.

Copilot uses AI. Check for mistakes.
@fbraz3 fbraz3 closed this Mar 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants