The dgVoodoo2 requirement was written as an MFD-mode problem. It is not. The
limitation is per SECONDARY DISPLAY, not per feature, so it applies to every mode
that lights up a second monitor -- including cameraship mode, which uses two
displays and no MFDs at all.
Console mode is the only configuration that does not need dgVoodoo2, because it is
single-display.
This matches the code: IsMultimonitorAvaliable() returns false for
_ECTCL_CameraShip, so cameraship falls through to IsSecondaryMonitorAvaliable()
and the single-secondary mr_device path -- which is still a second exclusive
IDirectDraw7, and therefore still refused by modern Windows for exactly the same
reason as the MFD panels.
Release notes updated in all three places it appears -- section heading and opening,
the known-issues entry, and upgrade checklist step 4 -- so an owner running
cameraship pods cannot read the requirement as "only applies to MFD setups" and
skip it. CLAUDE.md STEP 10 and repo memory corrected likewise, since both stated
the narrower "-tmfds 1/3/4" scope.
Both release-notes formats regenerated; still plain ASCII with CRLF.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Two wording corrections from the project owner, plus repair of three characters
left mangled by the earlier CP949 encoding problem.
1. dgVoodoo2 known-issue entry. "This is a Windows limitation, not a bug we can
fix" overstated it -- it reads as permanent. Replaced with a statement of what
dgVoodoo2 actually does (works around a limitation on exclusive full-screen use
of multiple displays on platforms after Windows XP) and that a future release
may address it. The borderless-windowed design assessed in CLAUDE.md STEP 10 is
exactly such a route, so leaving the door open is the accurate framing.
2. -tbaud. The notes implied any rate in the 9600-921600 range simply works. The
software will set any of them, but the achievable rate is bounded by hardware at
both ends: the serial UART in the pod PC and the RIO or replica RIO board. Added
that, with the symptoms of an unsupported rate (garbled input, dropped buttons,
no response) and the advice to step down. Without it an owner could conclude a
high rate is broken in the game when it is the UART or board refusing it.
Also repaired three leftovers from the CP949 encoding issue: two em dashes at ends
of lines that the earlier pass missed because it only matched dashes surrounded by
spaces, and the warning glyph on the MySQL export note, which had become a literal
"??" and is now a WARNING: label. It renders as a styled warning callout in the
HTML alongside the XP one, so both hazards look like hazards.
Both formats regenerated and verified: 0 non-ASCII bytes, 0 remaining artefacts,
2 warning and 5 note callouts in the HTML.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Deployed game tree copied back from the Windows build machine, containing the
compiled 5.1.0b_RC1 binaries and every asset the deploy produces. 846 files:
21 added, 825 modified.
Freshly built binaries: MW4.exe, Launcher.exe, autoconfig.exe, ctcls.dll,
MissionLang.dll, ScriptStrings.dll, Language.dll and the rest of the runtime DLL
set, carrying everything merged this cycle -- the 16-pilots-plus-cameraship launch
fix, the MFD mode 4 split-display support and its stutter fix, -tmon, -tcoop, -fps,
-tbaud, the Load File console lobby feature, configurable Rookie Mission, and the
English Language.dll build.
New in the deployment:
- set-appcompat.bat / set-appcompat.ps1 -- the one-click AppCompat shim installer,
now shipped by deploy-mw4.ps1 so any copy of an install can repair its own
registration (the layer is keyed on the exe's full path).
- libmysql.dll -- required by mw4print 2.0's MySQL export, late-bound at runtime.
- Four hsh art files restored from 5.0.7D: MFD/assassin2.bmp, Mechs/battlemaster
iic.bmp, Mechs/behemoth ii.bmp, Mechs/mad cat mkii.bmp.
- banner.txt, dbstruct.txt -- mw4print banner text and the exported DB structure
reference.
dgVoodoo2 is included as MW4/dgvoodoo2_files/ -- deliberately in a subfolder and
NOT alongside the executable. Nothing loads from there, so the files are available
for a pod owner to install on Windows 10/11 without being active by default. This
keeps XP pods safe: they use native DirectDraw, and having dgVoodoo2 loose in the
game folder would break them. Do not move these files up a level in the repo.
Runtime leftovers from testing on the build machine are included as well
(DDrawCompat logs, DebugLog.txt, mw4-help.txt, two screenshots), consistent with
this repo's stated purpose as a full disaster-recovery mirror in which nothing is
excluded on purpose.
All binaries and art are stored via Git LFS per .gitattributes; verified that
MW4.exe, libmysql.dll, the dgVoodoo2 DLLs and the screenshots staged as LFS
pointers rather than raw blobs.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Two corrections from the project owner.
1. dgVoodoo2 must NEVER be added to the repo or the deploy script.
The pod fleet is mixed. XP pods use native DirectDraw and need nothing extra --
installing dgVoodoo2 on them BREAKS them. Only Windows 10/11 pods need it, and
only for the MFD modes. It is therefore an installed-per-machine, OS-dependent
prerequisite that the pod owner sets up, not a build artifact.
This reverses the recommendation added in the previous commit, which suggested
versioning the working dgVoodoo.conf and having deploy-mw4.ps1 place it. That
advice was wrong: it would have pushed a Win10-only dependency onto every XP
machine. dgVoodoo.conf and dgVoodooCpl.exe were removed in 0ceba9c7 deliberately
and must stay out.
- CLAUDE.md STEP 10: the "TODO: commit it" note is replaced with the reasoning,
flagged so nobody re-adds the files later thinking it was an oversight.
- CLAUDE.md Next steps: that TODO is removed. The borderless-windowed item now
notes it is the only route that removes the dgVoodoo2 prerequisite WITHOUT
breaking the XP pods, since it needs no external DLL on either OS.
- Release notes gain an explicit warning callout: dgVoodoo2 is not part of the
build and must not be installed on XP pods, with the advice to configure it per
machine rather than inside the game folder that gets copied around. Without this
an owner with a mixed fleet could reasonably have copied a working Win10 install
onto an XP pod and broken it.
2. Version numbering is intentional, not a mismatch.
V5.1.0b<n> denotes beta build n; these are handed out as release candidates for
testing. The "b" is dropped and it becomes 5.1.0 when the release is final. So the
console string V5.1.0b1 alongside a release named V5.1.0b_RC1 is expected, and the
earlier suggestion to reconcile them is withdrawn.
Both release-notes formats regenerated; the XP warning renders as a warning
callout in the HTML. Both remain plain ASCII with CRLF.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Release notes covering the 58 commits since dbcf4052 (-tbaud), written for pod
owners rather than developers: what changed, what the defaults are if they touch
nothing, and how to switch on anything new.
Two formats. The HTML is generated from the markdown so the two cannot drift, and
carries the same inline styling as BTFrstrm/autoconfig-file-spec.html -- no external
files, opens in any browser, prints cleanly. Both are plain ASCII with CRLF so they
open correctly in Notepad on a pod.
Structure leads with the two things that will otherwise generate support traffic:
running set-appcompat.bat after install (the AppCompat layer is keyed on the install
path, and its absence produces the misleading "Another application is preventing use
of full screen mode"), and the dgVoodoo2 scaling mode, which fails silently when set
wrong. Every command line switch is listed with an explicit "if you leave it off"
column.
Facts checked against the source while writing, and corrected:
- [RookieMission] key names. The first draft documented RookieMission=, RookieGameType=
and so on -- the internal variable names. The game actually reads MissionName,
GameType, TimeLimit, Visibility, Weather, TimeOfDay, Radar, HeatOn, FriendlyFire,
SplashDamage, UnlimitedAmmo, WeaponJam, AdvanceMode, ArmorMode. Anyone following the
draft would have edited options.ini and seen no effect with nothing to explain why.
The section now carries the full annotated block verbatim from options.ini, and all
14 documented keys are machine-verified against MW4Shell.cpp.
- [automaticmode] needs TWO keys, not one. automaticmode=1 shows the Load File button;
automaticfile=<path> tells it what to load. Without the second, CTCL_LoadAutoFile
returns immediately -- the button appears and silently does nothing. Both are now
documented in a table, with the path rules (bare filename resolves next to MW4.exe,
or give a full path).
- dgVoodoo2 is required on Windows 10/11 for EVERY MFD mode, including the original
spanned display (-tmfds 1 and 3), not only the new split mode (-tmfds 4). The first
draft implied it was specific to the new feature, which would have led owners running
the span to skip it.
- The mw4print MySQL export is flagged as included but not yet tested against a live
server. Everything else in the notes is confirmed working by the project owner.
libmysql.dll ships in the deployment (Gameleap/mw4, kept by the deploy's root *.dll
rule and not on the skip list), so there is nothing for owners to download.
Also repaired 23 em dashes that had been written as literal '?' characters, including
in headings -- a side effect of the workspace saving new files as CP949, which cannot
represent them. Both files are now pure ASCII.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
First real run of -fps (222 seconds, 4-monitor bench, in-mission) showed a
rock-solid 60.0 fps average but a worst frame of ~24ms in 82% of seconds, with a
median of 24.4ms and a minimum of 23.2ms. That regularity was the tell: 60Hz vsync
intervals are 16.7 / 33.3 / 50.0 ms, so 24ms is not a multiple of anything and had
no business recurring once per second with that consistency.
Cause: the logger was measuring itself. The per-second line was written straight to
the file with WriteFile on the render thread, and the frame duration is recorded
BEFORE the line is emitted -- so the write's cost landed in the *next* frame's
measurement, which belongs to the next second's bucket. Result: exactly one
inflated frame per second, indefinitely. Holding the handle open (as the first
version did) was not enough; a single WriteFile is still several milliseconds when
something like antivirus is in the path.
Three fixes:
1. Buffered output. Lines accumulate in a 128 KB static buffer (~2000 rows, about
33 minutes at one row per second) and are flushed only when the buffer fills or
at exit via atexit(). A normal measurement session now performs no file writes
at all while running. Trade-off, deliberately accepted: a hard crash loses the
un-flushed tail. gos-displays.txt remains the crash-survivable log; gos-fps.txt
is a measurement instrument and must not perturb what it measures.
2. Meaningful percentiles. A "1% low" over 60 samples per second computes
nFrames/100 = 0, which was clamped to 1 -- so the column was literally
1000/worst_frame, i.e. the worst-frame column restated in different units.
Verified against the log: worst 24.1ms -> 41.5 fps, exactly the "1% low" printed.
Per-second is now a 5% low (worst 3 of 60), which is a number that actually
differs from the worst frame. True whole-session 1% and 0.1% lows are computed
at exit from a 0.5ms-bucket frame time histogram (2000 buckets, 0-1000ms) and
printed in a new session summary along with total frames, elapsed time, average,
and total hitches. The histogram gives exact-enough percentiles over an entire
session without retaining every frame time.
3. Carry-over. A single frame longer than one second (a level load: the log shows
4338ms and 4799ms frames) left the accumulator above the 1000ms threshold, so
the next few frames each emitted their own bogus one-frame row -- visible in the
log as rows reporting "1 frame, 1339 fps". The excess is now discarded.
Also adds #include <stdlib.h> to WinMain.cpp for atexit(); it was not reachable
through pch.hpp. GOS_FpsAtExit is declared __cdecl: GameOS builds with /Gz, which
makes __stdcall the default calling convention, but atexit() takes a __cdecl
callback -- without it VC6 rejects the call with C2664.
What the run did establish, and still stands: 60 frames per second sustained for
~150 seconds with no rhythmic multi-hitch pattern, so the mode 4 split-MFD stutter
fix (0a657b59) is holding. Genuine dropped frames (>40ms) occurred in 18% of
seconds, including clusters of 80-90ms; those are real and unaffected by this fix.
Re-measure after this change to see the true baseline.
CLAUDE.md STEP 10 updated: the previous claim that holding the handle open kept the
logger from perturbing the measurement was wrong, and is replaced with what was
actually observed.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Four-monitor MFD bring-up on the new bench (MR_new: AMD FirePro W4100, 4 outputs,
Win10). Adds permanent display diagnostics, a Release-capable frame pacing logger,
a self-locating AppCompat shim installer, and settles -- empirically -- whether
dgVoodoo2 can be dropped for the multi-monitor MFD modes. It cannot.
WHY THIS WAS HARD
-----------------
CHSH_Device::InitFirst/InitSecond discarded EVERY HRESULT (SetCooperativeLevel,
SetDisplayMode, CreateSurface, GetAttachedSurface, QueryInterface, CreateDevice)
and returned true unconditionally. A panel that failed to open produced no error,
no crash and no log entry -- the monitor just stayed on the desktop. SPEW is
compiled out of shipping builds, so none of it was visible. Restoring that
visibility is what unblocked everything else.
DIAGNOSTICS ADDED (keep these)
------------------------------
* VideoCard.cpp -- LogDisplayDevices() writes gos-displays.txt next to the exe:
NumDevices/NumHWDevices/NumMonitors, every DirectDraw device with its
hw_rasterization flag, the role assignment (FullScreenDevice / g_nNonDualHead /
g_nDualHead / g_nDualHead2 / g_nMFD1 / g_nMFD2), per-slot -tmon APPLIED/REJECTED
(previously silent), and whether mode 4's "BOTH mfd1 and mfd2" requirement is met.
* render.cpp -- HSH_LogInit()/HSH_CheckHR()/HSH_HRName() log every DirectDraw call
in the panel init path with its HRESULT decoded by name (27 DDERR_* codes, all
verified present and collision-free against build-env/dx7asdk/include/ddraw.h).
Each line is opened/appended/closed individually so the log survives a crash.
* WinMain.cpp -- GOS_LogFrameRate() writes gos-fps.txt: per second, frame count,
average fps, 1% low (mean of the worst 1% of frames), worst frame in ms, and a
count of frames exceeding 2x average ("hitches"). Average fps alone cannot
distinguish 60fps from 60fps-with-a-dropped-frame-every-second; the 1% low can.
The engine's own FrameRate readout is #ifdef LAB_ONLY (MWMission.cpp) so it only
exists in MW4pro.exe; this works in Release, which is what runs on the pods.
NEW SWITCHES (both documented in -help)
---------------------------------------
* -fps Enable the frame pacing report. Off by default: the gate is the first
statement in GOS_LogFrameRate, so an unflagged run does no arithmetic
and does not even create the file. The file handle is held open for the
process lifetime -- opening/closing it every second would put a syscall
of unpredictable latency on the render thread, i.e. the measurement tool
perturbing what it measures.
* -tcoop <0-5> Selects the SetCooperativeLevel form used by the radar/MFD panels.
0 = legacy (unchanged shipped behaviour, remains the default).
Exists so every candidate fix could be compared on real hardware without
a rebuild between attempts.
CRASH-SAFETY FIX
----------------
hsh_initialized was set unconditionally after panel init, so a failed panel left
null surfaces and a null IDirect3DDevice7 behind and the per-frame path called
straight through them. Now:
- all four InitSecond overrides (CMR/CRadar/CMFD/CMFDRight) bail on base failure,
- CMFD_Device::InitFirst reports its real result instead of always returning true,
- hsh_initialized is only set when the panels genuinely came up.
A display failure now leaves the game running without MFDs instead of bombing to
desktop. Crash signature for the record: `call [ecx+0x44]` with ECX=0 is
IDirectDrawSurface7::GetDC on a never-created surface (vtable offset confirmed
against the DX7 header), reported as "Attempt to read from address 0x00000044".
APPCOMPAT SHIM INSTALLER (new)
------------------------------
build-env/set-appcompat.ps1 + set-appcompat.bat. Self-locating via $PSScriptRoot:
applies DWM8And16BitMitigation to the MW4 executables sitting next to it, wherever
that install lives. HKCU always, HKLM too when elevated (the HKLM value format
differs -- it carries a leading "$" marker -- so the two must not be interchanged).
Verifies by reading back; detects the HIGHDPIAWARE-only entry that SUPPRESSES the
automatic shim; supports -Remove and -WhatIfOnly. deploy-mw4.ps1 now ships both
files into every deployment.
This matters because the layer is keyed on the executable's FULL PATH -- any copy
of an install to another folder or machine silently loses it, and the resulting
error is actively misleading (see below).
WHAT WE LEARNED
---------------
* The AppCompat shim SYNTHESISES 16-bit display modes. Proved directly: the crash
dump shows "16 bit modes :" EMPTY without it and fully populated with it. MW4
renders at bitdepth=16 and modern GPUs expose no 16-bit modes at all.
* Without the shim, GameOS reports "Another application is preventing use of full
screen mode" (GOS_DXRASTERIZER_NOFULLSCREEN, DXRasterizer.cpp ~1125). That is a
catch-all fired after every SetDisplayMode attempt fails -- it even scans for
NetMeeting -- and it sends you looking for a conflicting program that does not
exist. The real cause is the missing shim.
* Exclusive fullscreen DOES work on Win10 with the system ddraw.dll and dgVoodoo2
physically removed, once the shim is applied to that exe path.
* Windowed mode works natively with no shim at all: the windowed path sets
Environment.bitDepth = DesktopBpp (32), so there is no mode switch. Verified for
the console/shell; a full mission windowed is still untested.
* Native DirectDraw enumerates all four W4100 outputs, so dgVoodoo2 was never
needed for device enumeration.
* The engine is 4:3 ONLY. ImageHlp.cpp ~464 asserts the complete supported set:
640x480, 512x384, 800x600, 960x720, 1024x768, 1280x1024 (5:4), 1600x1200. No
16:9 mode and no aspect correction anywhere in the codebase. On a 16:9 monitor
the scaler must adapt: plain stretch distorts geometry, keep-aspect pillarboxes.
* -2dt is not a recognised switch anywhere in the codebase, despite appearing in
production ctcl.ini launch lines. Completely inert.
* NumHWDevices (5) can exceed NumDevices (4): it counts D3D device-enumeration
callbacks, and an adapter exposing both a HAL and a T&L HAL yields two. Benign.
WHAT WE TRIED AND WHY IT FAILED
-------------------------------
The panel cooperative-level call was genuinely wrong -- a latent 2002 bug. Every
panel asked to be BOTH the process focus window AND its own device window, on the
one shared hWindow, after the main device had already taken exclusive mode on it.
The main device (DXRasterizer.cpp ~1027) already uses the correct two-call idiom
(SETFOCUSWINDOW alone, then EXCLUSIVE|FULLSCREEN) -- tagged //sanghoon, the same
author. The panels never were.
Results on real hardware, no dgVoodoo2, shim applied, -tmfds 4:
-tcoop 0 SETFOCUSWINDOW|CREATEDEVICEWINDOW|ALLOWREBOOT|EXCLUSIVE|FULLSCREEN
-> DDERR_EXCLUSIVEMODEALREADYSET
-tcoop 1 CREATEDEVICEWINDOW|EXCLUSIVE|FULLSCREEN (no focus claim)
-> DDERR_INVALIDPARAMS (CREATEDEVICEWINDOW needs a focus window)
-tcoop 2 SETFOCUSWINDOW, then CREATEDEVICEWINDOW|EXCLUSIVE|FULLSCREEN
-> DDERR_INVALIDPARAMS
-tcoop 3 SETFOCUSWINDOW, then EXCLUSIVE|FULLSCREEN
-> first panel collides, but that collision STEALS exclusive mode from
the main display, after which panels 2 and 3 fully initialise (the
radar reached CreateDevice(HAL) = DD_OK -- a secondary panel running
entirely on native DirectDraw). Side effect: the desktop was left at
1920x1080 16bpp. Not viable.
-tcoop 4 EXCLUSIVE|FULLSCREEN only -> EXCLUSIVEMODEALREADYSET, all panels
-tcoop 5 ALLOWREBOOT|EXCLUSIVE|FULLSCREEN -> EXCLUSIVEMODEALREADYSET, all panels
CONCLUSION: on modern Windows only ONE DirectDraw object per process may hold
exclusive fullscreen. The main display takes it; every secondary panel is refused.
XP allowed multiple. dgVoodoo2 allows it because it is a full reimplementation of
ddraw and is not bound by that rule -- it is not papering over a bug we can fix.
=> dgVoodoo2 CANNOT be removed for -tmfds 1/3/4 by correcting these flags. The
default stays -tcoop 0. The switch is retained because it is how this was settled
and it will re-settle it on different hardware.
The only native path is a borderless windowed panel design (DDSCL_NORMAL + clipper
per monitor, no exclusive mode anywhere). Assessment and staged plan are recorded
in CLAUDE.md STEP 10; not started.
WORKING 4-MONITOR CONFIG (with dgVoodoo2)
-----------------------------------------
dgVoodoo2 Scaling mode MUST be "Stretched, Keep Aspect Ratio". Plain "Stretched"
fails silently: main and radar go fullscreen black, both MFD monitors keep showing
the desktop, and every DirectDraw call still returns DD_OK -- the devices are alive
but dgVoodoo2 never drives those outputs. Diagnosed with a temporary per-panel
colour-flash test (since removed), which also established that device index maps
1:1 to physical monitor on this bench, so -tmon 1,2,3,4 equals auto-detection.
Confirmed working end to end: all three secondary panels present, full mission
played.
KNOWN GAP: the working dgVoodoo.conf is still not versioned in the repo (removed
in 0ceba9c7), so a fresh deploy will reproduce the silent MFD failure.
Behaviour with no new switches supplied is unchanged from the previous build
except on failure paths, which now degrade gracefully instead of crashing.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
options.ini had no documentation. This documents every section and key, compiled
by reading the actual read sites rather than by describing the shipped file, so
that settings which look active but are not are identified as such.
Covers [graphics options], [sound options], [special commands], [server],
[joystick], [Cameraship Params], [Battle Tech Misc], [RookieMission] and
[battle tech print], plus how the file is loaded, which parts the game writes
back, and the per-role options-game/cam/mr variants.
Notable findings, all verified against source:
- The entire [network options] section is DEAD. None of connectiontype,
connectionspeed, packetsize, defaultconnection, playericon or teamicon is read
by any code; the connection type actually used comes from the multiplayer
connection wizard. These are stock MW4 leftovers.
- Several [Battle Tech Misc] keys have names that do not describe what they do,
and the real meanings are now recorded: RuleBook sets g_nMechVariant, DawnWar
sets g_nMechLabOp, BiggieSizeIt sets g_nMechPodNum (the console lobby's larger
roster flag), and CanYouHearTheFootSteps sets g_nBlackMech.
- The shipped options.ini misspells two keys. It contains secmissionreplay and
secmissionreport, but the code reads SecsMissionReplay and SecsMissionReport.
The shipped values are therefore ignored and the compiled defaults apply.
- Three keys are read and then immediately overridden, so editing them does
nothing: videodriverindex (device forced to 0), huddamagemode and
hudtargetdamagemode (both forced false). Their GetEntry calls are commented out.
- [special commands] killgame is a self-clearing kill switch: if true at startup
the game rewrites it to false, saves options.ini and exits immediately.
- maxplayers/maxbots are serialised to clients as 5-bit fields, so 31 is the
maximum usable value; cross-referenced to RAISING-PLAYER-CAP.md.
Also records why a typo produces no diagnostic: GetEntry returns false and the
compiled default is kept silently. Page and key lookup were confirmed to be
case-insensitive (NotationFile::FindPage lowercases; Page::FindNote uses
_stricmp), so the capitalisation differences between the shipped file and the
code are harmless -- the misspellings above are not.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
MW4.exe accepts 76 command line switches. Only 27 of them appeared in the old
-help output, that output went to the debug log rather than to the user, and it
did not stop the game from launching afterwards -- so in practice the switches
were undocumented.
-help now writes a full, categorised reference to mw4-help.txt next to the
executable, opens it in Notepad, and returns from WinMain without starting the
game. If Notepad cannot be launched, a message box reports where the file was
written. The check runs immediately after the command line is lower-cased at the
top of WinMain, before any subsystem is initialised.
A file plus a viewer was chosen over a message box because MW4 is a GUI-subsystem
application with no console, and 76 switches with real descriptions do not fit
legibly in a dialog.
The reference documents every switch actually parsed, grouped as: display and
video, audio and plasma display, pod hardware and arcade (CTCL), zoom and field
of view, multiplayer and network, logging and diagnostics, development and test
builds, and other. Each entry records the accepted value range where the parser
enforces one -- for example -tbaud 9600-921600, -armorlevel 0-4, -tmfds 0-4,
-zmfovb 0.01-0.5, and the -zmtime special case where 0 means instant.
Two switches are listed under "recognised but inactive" so their behaviour is not
misrepresented: -join, whose consuming line is commented out, and -noabzug, which
is only parsed inside a disabled code path. The LAB-only switches are marked as
accepted and ignored in Release builds.
The old partial SPEWALWAYS list in GetGameOSEnvironment was removed so there is a
single maintained reference rather than two that can drift apart. A comment there
points at the new one.
Also adds an explicit #include <stdio.h>; this translation unit previously had no
direct stdio use and relied on transitive inclusion.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
The previous correction overstated the case by implying the code reading was
wrong outright. It was not. The engine really does place surplus 'Mechs on
already-occupied spawn points -- two 'Mechs dropped on the same spot -- exactly
as reading the code suggests.
The only wrong part was the predicted consequence. The original draft said those
players "silently fail to spawn". They do spawn; the collision system then pushes
the stacked 'Mechs apart within a second or two, costing some minor contact
damage, and play continues normally.
Reworded Layer 7 and the known-traps entry to separate the two claims: the
spawn-point reuse is real and code-predictable, the failure-to-spawn conclusion
was not.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
The original draft claimed that players beyond a map's available drop zones
"silently fail to spawn", and called per-map drop-zone authoring the true gating
task for raising the player cap. That was inferred from reading the code and is
wrong.
Corrected from real pod testing: when there are more 'Mechs than drop zones, the
surplus 'Mechs spawn on top of each other. They clip and collide briefly, take
some minor damage, then separate and play normally. It resolves itself within
seconds.
So a drop-zone shortfall is a quality-of-experience issue, not a functional
failure. It does not block raising the cap and should not gate the schedule.
Adding start points to busy maps is still worth doing eventually -- overlapping
spawns are untidy and hand out free chip damage -- but it can happen at any point
and never needs to be complete.
Updated accordingly: the TL;DR table, Layer 7, the implementation order (drop
zones moved from step 5 to last and marked optional), the verification checklist,
and the known-traps list.
The biggest remaining non-code task is now the lobby pod-grid and scoreboard
layout rework.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Captures the full audit of every player-count limit in the codebase, done while
tracking down the "16 pilots + 1 cameraship" launch failure. Research only --
nothing in it is implemented.
Key finding: the practical ceiling without a wire-format change is 31, not 32.
m_maxPlayers and m_maxBots are serialized as 5-bit fields in
NetMissionParameters, so 32 truncates to 0. This supersedes the "32" figure in
the existing CLAUDE.md plan sections.
Documents, with file references:
- what is NOT a limit (Adept::Maximum_Players is 255, connectionID is a BYTE,
DirectPlay imposes nothing, and there is no 32-bit player bitmask)
- the 5-bit serialization ceiling and what widening it would cost
- the compiled defaults in CTCL_DefaultHostSetup that actually gate connections
- the CTCL roster arrays, including that g_aPlayerInfos[20] has NO bounds check
in CTCL_AddPlayer and that ctcl.h is duplicated across ~6 directories
- MAX_LANCEMATES 16 for bots
- the lobby script constants and the pod-grid UI work
- scoreboard/radar/review layout work
- per-map drop zones, which is the real gating task and produces silent spawn
failures when short
- the O(n^2) replication cost, reframed as verify-don't-assume on modern hardware
Also records the failure signatures to expect, so a future attempt recognises
them quickly: silent launch hang from a count mismatch, silent non-spawn from
missing drop zones, and 5-bit truncation looking like "max players became zero".
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Display roles are auto-detected in FindVideoCards(): the main view takes the
first hardware-rasterizing device that is not a 1280x480-capable span, the radar
takes the next, and mode 4's two MFD panels take the two after that. That works
until DirectDraw enumerates the adapters in an unexpected order, at which point
the wrong content appears on the wrong monitor with no way to correct it.
Adds an override that keeps auto-detection as the default:
-tmon <main>,<radar>,<mfd1>,<mfd2>
Values are 1-based, so the normal case is "-tmon 1,2,3,4". A value of 0 leaves
that slot auto-detected, so "-tmon 2,1,0,0" swaps only main and radar. Separators
may be ',' '/' or ':'. mfd1/mfd2 are only meaningful with -tmfds 4. Omitting the
switch entirely preserves existing behaviour exactly.
Implementation:
- Parsed in MW4Application's WinMain alongside -tmfds. That runs before GameOS
calls FindVideoCards(), so the values are in place for device selection.
- Stored in g_naMonitorOverride[4] (VideoCard.cpp), extern'd in MW4Application.cpp.
- ApplyMonitorOverride() validates the index against NumDevices, so a stale -tmon
on a machine with fewer monitors falls back to auto-detection rather than
breaking startup.
- Ordering matters and is deliberate: main and radar are applied BEFORE the mode 4
MFD search so that search still skips whichever devices the operator picked;
mfd1/mfd2 are applied after it. Partial overrides therefore compose correctly.
Role map: main = Environment.FullScreenDevice, radar = g_nNonDualHead,
mfd1 = g_nMFD1, mfd2 = g_nMFD2. The mode 1 span (g_nDualHead) is intentionally
not overridable -- it is detected by 1280x480 mode support, which only the span
card advertises, so that detection is reliable.
Also adds a SPEW line logging the final role -> device map and device count.
Note this is only visible in Profile/LAB builds; SPEW compiles out in Release
(gos2X/Gos.h), so in Release the order is determined by observation.
Verified: compiles clean, console launches. Multi-monitor testing pending.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
-tmfds 4 splits the 1280x480 MFD span into two independent 640x480 monitors so
the span hardware is no longer required. It rendered correctly but stuttered
rhythmically and constantly, making the game unplayable. -tmfds 1 on the same
binary was flawless.
Root cause: a cross-DirectDraw-object texture read, twice every 7-frame cycle.
CHSH_Device::InitFirst with no pOtherHSHD peer creates its OWN IDirectDraw7 (via
wDirectDrawCreateEx on that monitor's device GUID) and InitSecond creates its OWN
primary flip chain and IDirect3DDevice7. CMFDRight_Device::InitFirst passes no
peer, so the right MFD is an entirely separate DirectDraw object.
EndChannel then did, for channels 3-4:
target->pD3DDevice->SetTexture(0, pDDSTarget);
where target->pD3DDevice belonged to the RIGHT device but pDDSTarget was the LEFT
device's render-target texture. The old code comment asserted "both devices are
on the same GPU so VRAM textures are mutually accessible" -- that premise is
wrong. In DirectDraw 7 a surface belongs to the IDirectDraw7 that created it, not
to the physical GPU, so it is not a valid texture on another object's D3D device.
The MFDs still displayed, which means the runtime was emulating the access with a
VRAM -> system-memory readback and re-upload of the 1024x512 16-bit render target.
That forces a full GPU pipeline stall, and it happened on channels 3 and 4 (that
is, sh_step 5 and 6) -- twice per 7-frame cycle, on the same GPU drawing the main
view. Hence a fixed-period hitch in the whole game, forever.
This also explains why the earlier stagger work (eaa5fd3, BeginSceneRight) did not
help: it only moved a Flip from sh_step 0 to 1, and the flips already used
DDFLIP_DONOTWAIT|DDFLIP_NOVSYNC and never blocked. The flips were never the
problem.
Fix: give the right device everything it draws with, and render channels 3-4
entirely on it.
- New HSH_CreateMFDTextures() builds the mech image atlas and the MFD sprite atlas
on a caller-supplied IDirectDraw7. Both devices now call it, so each owns a
complete independent texture set. CMFD_Device::InitSecond was refactored onto it.
- CMFDRight_Device gained its own pDDSMechTexture / pDDSDamageTexture /
pDDSTargetTexture plus a Release() override, and its InitSecond now sets up
tw/th and the material/render state exactly like the left device.
- New CMFD_Device::SwapRightState() exchanges this object's DATA members with the
right device's. BeginChannel swaps in when channel >= 3 in mode 4; EndChannel
swaps back. This routes all existing drawing to the correct monitor without
touching the ~233 mfd_device.* call sites in hudchat/huddamage/hudweapon/
GUIRadarManager. The vtable pointer is deliberately never swapped, so virtual
dispatch is unaffected; CHSHFont has no virtual functions so its array is
swapped bytewise to avoid ctor/dtor side effects on a temporary.
- EndChannel's composite is now a single path for all modes. Mode 4 composites
full 640 width at x=0 (each device is a standalone panel); modes 1-3 keep the
half-width (ch/3)*w packing into one backbuffer.
Side effects: startup builds the 65-bitmap mech atlas twice (once per device), and
VRAM use rises by a few MB. Modes 0-3 are behaviourally unchanged.
Known cosmetic leftover, deliberately not changed: huddamage.cpp lines ~1319 and
~1901 call LoadTargetTexture outside the channel-3 block, so those loads land on
the left device and go unused. The in-channel call at ~2209 runs every frame in
that branch and correctly populates the right device's copy, so behaviour is
correct -- it is just a redundant load on target change.
Requires rebuild: MW4.exe (GameOS changes recompile the engine library).
Verified: compiles clean, console launches. Two-monitor testing pending.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
A full 16-'Mech roster plus a cameraship silently refused to launch: the console
sat in nLaunchState 3 ("loading") forever with no crash and no error. 15 mechs +
camera worked, and 16 mechs with no camera worked.
Two independent bugs, both counting the cameraship against the 16 'Mech slots.
1. Session capacity (broke all-human rosters)
CTCL_DefaultHostSetup derived the camera reserve from
CTCL_GetTeslaCountAll() - CTCL_GetTeslaCount(). Those counters read the CTCL
tesla table, which is only populated when CTCL_IsConsoleOrCOOP() is true --
i.e. only on the console. But the machine that creates the network session is
the cameraship pod (CTCL_DoMission sets g_nServer = nCameraship, and that pod
runs CTCL_DoCreateGame -> CTCL_DefaultHostSetup(0) -> Mech4CreateGame ->
gos_CreateGame(..., Environment.NetworkMaxPlayers, ...)).
On that pod both counters return 0, so the reserve collapsed to +0 and the
session was created with dwMaxPlayers = 16. The 17th connection was refused,
CTCL_CheckServerReady never saw nCount == g_nTeslas + 1, and the launch hung.
Fixed by reserving with a constant, MW4_CAMERASHIP_RESERVE (4, matching
MAX_CAMERAS), which is valid on every machine regardless of the tesla table.
2. Bot admission (broke any roster containing bots)
MW4Shell::AddBot rejects when (player_count + bot_count) >= m_maxPlayers.
player_count is the DirectPlay player count, which includes the cameraship
connection, so with m_maxPlayers = 16 the last bot was silently refused.
g_nBOTs then never matched the connected lancemates and the same readiness
check spun forever.
Fixed by subtracting cameraship participants from player_count under CTCL,
via a new CTCL_CountCameraShipsInGame() helper (non-bot entries with
m_nMechIndex == 0). Cameraships hold a network slot but pilot no 'Mech, so
they must not consume a 'Mech slot.
Also applies the constant reserve in the PLAYER_LIMIT_PARAMETER path, guarded by
!CTCL_IsNone() so a standalone non-pod host keeps its exact configured limit.
This supersedes commit f76dc05f, which had the right formula but evaluated it on
the console rather than on the pod that actually creates the session.
Note for later: m_maxPlayers is serialized in only 5 bits (MWApplication.cpp),
so 31 is the hard ceiling for any future player-cap work. See
RAISING-PLAYER-CAP.md.
Requires rebuild: MW4.exe (Release + Profile). No script or resource changes.
Verified: compiles clean, console launches. Pod testing pending.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
- Stabilize Load File first-click behavior across mission/map/options/slots.
- Fix map sequencing by rebuilding game-type scenario list before mission lookup.
- Resolve mission-name miss to map index 0 fallback for selected game type.
- Fix decal handling: map INI decal IDs to dropdown indices, clamp invalid indices, display actual decal IDs in UI labels, and avoid redraw-time decal overwrite.
- Fix option apply timing and UI visibility issues, including Weapon Jam refresh.
- Add NoReturn support end-to-end: parse/store in MW4Shell auto globals, expose script variable, and apply to respawn/no-return mission params and UI checkbox.
- Update autoconfig spec to reflect actual parser/default/fallback behavior and add NoReturn examples.
'gui_objects have no parent' crash at line 907: initialize(this) cannot be
called from sender==@conlobby@ context (external mail). Fix:
1. Replace initialize(this)+mail(-9998,parent) in MAIL_LOAD_AUTO_MISSION
with mail(MAIL_LOAD_AUTO_MISSION_DONE=-8888, this) -- a self-mail.
2. Add MAIL_LOAD_AUTO_MISSION_DONE handler in sender==this block, which
safely calls initialize(this)+mail(-9998,parent) from the correct context.
Also repaired a corrupt duplicate MAIL_PREVIOUS_MISSION_PARAMS block
that was left orphaned by an earlier edit (the original body of
MAIL_LOAD_AUTO_MISSION had been inserted there when the handler was
moved from sender==this to sender==@conlobby@).
No rebuild required (script-only).
Handler was inside 'if (sender == this)' but MAIL_LOAD_AUTO_MISSION is sent
from ConLobby (sender != this), so it never fired. All game params (FriendlyFire,
SplashDamage, UnlimitedAmmo, WeaponJam, AdvanceMode, ArmorMode, etc.) were
silently ignored on every Load File click.
Fix: move the ~70-line handler to the 'if (sender == @conlobby@)' block,
alongside MAIL_SET_ROOKIE_MISSION and MAIL_PREVIOUS_MISSION — where all
ConLobby-originated mails are handled. No rebuild required (script only).
Issue 1 — double press to fix team/FFA display:
cur_team_val is updated by ConLobbyMission's -9998 signal which was async.
Fix: call SetNetworkMissionParamater(team_allowed, ...) directly in ConLobby
before the slot loop, then re-read cur_team_val via CTCL_GetTeamParams.
This is synchronous so the slot display is correct on the first click.
New file keys: TeamAllowed=0/1, TeamCount=2 (default 2 teams).
Issue 2 — Default button broken after Load File click:
CTCL_LoadAutoFile was overwriting g_nRookieGameType/g_szRookieMission etc.
so the Default button loaded the last auto-file params instead of defaults.
Fix: 14 new dedicated g_nAutoXxx/g_szAutoMission globals. CTCL_LoadAutoFile
populates ONLY these. Rookie Mission globals are never touched.
New MAIL_LOAD_AUTO_MISSION (-6666) sent to ConLobbyMission applies the Auto
globals (mirrors MAIL_SET_ROOKIE_MISSION_PARAMS but uses g_nAutoXxx).
ConLobby reads game type/mission from Auto globals directly into the
ConLobbyMission dropdowns (@ConLobbyMission@o_game_options[N].nselected).
Files changed:
MW4Shell.cpp: 16 new globals, StartUp/ShutDown registration, CTCL_LoadAutoFile
ConLobby.script: MAIL_LOAD_AUTO_MISSION define, updated handler
ConLobbyMission.script: MAIL_LOAD_AUTO_MISSION define + handler
autoconfig-file-spec.html: document TeamAllowed + TeamCount fields
Rebuild required: MW4.exe (Release + Profile).
1. Expose g_bAutomaticMode as gosScript variable so ConLobby can check
it at init time. o_load_file.state is set to 3 (disabled/hidden) if
automaticmode != 1 in options.ini. Button is fully visible and active
only when the feature is intentionally enabled.
Rebuild required: MW4.exe (Release + Profile).
2. Remove cur_team_val conditional for team/skin slot assignment.
Previously, only one of o_team[k] or o_skins[k] was set depending on
cur_team_val at click time, but MAIL_SET_ROOKIE_MISSION propagates the
new game type asynchronously -- cur_team_val would not reflect the
file's GameType until the next frame, requiring a second click.
Fix: always set both o_team[k] and o_skins[k] unconditionally. The
mission launch code uses whichever is relevant for the active mode;
the other is harmlessly ignored. No rebuild (script-only).
mech[j] in the flat sorted array hits variant entries (e.g. 'Assassin2 A'
sorts before 'AssassinII' alphabetically, pushing all subsequent chassis
indices off by 1 or more). The script's stock_array[] maps each chassis
index -> its actual position in the flat mech[] array, bypassing variant
entries.
Fix: mech[allowed_mechs[j]] -> mech[stock_array[allowed_mechs[j]]]
Only stock (chassis) names are supported in Mech= field. Operators can
adjust variants manually after Load File is clicked. No rebuild required
(script-only change).
Script calls callback(CTCL_GetAutoSlotInt, k, 0/1/2/3) where 0-3 are
integer literals. The script engine passes literals as (void*)N directly
(not as pointers), so INTPARM(1) = *((int*)data[1]) dereferences NULL
when field=0, producing the 'Attempt to read from NULL' STOP.
Fix: VALUEPARM(1) = (int)data[1] reads the value without dereferencing.
k (data[0]) remains INTPARM because it is a script variable (passed as
a pointer to the variable's storage, not a literal).
Also add exists(@ConLobbyMission@) guard before MAIL_SET_ROOKIE_MISSION
for defensive safety if the sub-script is not running.
Rebuild required: MW4.exe (Release + Profile).
options.ini [automaticmode] section:
automaticmode=1
automaticfile=c:\path\to\config.ini
Right-click was considered then dropped in favor of a dedicated button
at 467,510 (below Pick Cond., left of Reprint).
C++ (MW4Shell.cpp):
- SAutoFileSlot struct + g_aAutoSlots[16], g_bAutomaticMode, g_szAutomaticFile globals
- [automaticmode] ini read at StartUp
- CTCL_LoadAutoFile: checks file exists, reads [mission] page into existing
g_nRookieXxx globals + [slot0]..[slot15] pages into g_aAutoSlots[]; returns 1 if loaded
- CTCL_GetAutoSlotName(out_str, k): pilot name for slot k
- CTCL_GetAutoSlotMech(out_str, k): mech display name for slot k
- CTCL_GetAutoSlotInt(k, field): Type/Team/Skin/Decal for slot k (fields 0-3)
- Register/unregister all 4 callbacks in StartUp/ShutDown
Script (ConLobby.script):
- o_load_file button at 467, 510
- Handler: CTCL_LoadAutoFile -> if loaded, sends MAIL_SET_ROOKIE_MISSION to
ConLobbyMission (game options), clears all slots, then applies per-slot data
in a loop (pilot names, mech by display-name lookup in allowed_mechs[], team,
skin, decal). USE_ALLOWED_MECHS/non-ALLOWED_MECHS both handled via #if.
File not consumed (stays on disk); external app overwrites for next load.
Rebuild required: MW4.exe (Release + Profile).
MW4Shell.cpp:
- CTCL_DefaultHostSetup (non-coop): replaced hardcoded
Environment.NetworkMaxPlayers=16 with
params->m_maxPlayers + (CTCL_GetTeslaCountAll() - CTCL_GetTeslaCount())
so DirectPlay reserves one extra slot per installed cameraship.
CTCL_GetTeslaCountAll() - CTCL_GetTeslaCount() = camera-only seat count.
- SetNetworkMissionParamater / PLAYER_LIMIT_PARAMETER: applied the same
camera-slot formula when the host changes the player limit at runtime.
Also restored the gos_NetServerCommands(gos_Commend_UpdateMaxPlayers)
call (was accidentally dropped) and the missing break that caused
fall-through into JOIN_IN_PROGRESS_PARAMETER.
- COOP branch: no change (capped at 9+bots; camera seats not needed there).
ConLobby.script:
- Raised the launch-guard cap from nTempPlayerCount > 16 to > 17,
allowing the 17th connection (the cameraship) to not trigger the
'Too many player/bots' error.
Version bumped to V5.1.0b1 to align with the 5.1.0b-in-progress branch name and
the goal of producing a tested release candidate.
Incorporated manually-tested script changes from Buddy 'Highlight' Taylor of
MechCorps (MCHL), who expanded the default mech pool from Fab4 to Super6:
- ROOKIEMECH defines extended to 6 entries (added Archer ID=1, Warhammer ID=62)
- 16-slot default mech assignments updated to cycle through all 6 Super6 mechs
- Right-click mech randomizer expanded from random(0,3) to random(0,5) to
include Archer and Warhammer in the pool
Changelog entries for Cyd (06/24/26), MCHL (06/27/26), and RT (07/19/26)
added to the script header.
Co-authored-by: Claude Sonnet 4.6 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Syncs all source, content, toolchain, and assets needed to build and test the game on the Windows machine at /vwe/firestorm. Excludes generated build outputs (bin dirs, *.mw4, *.dep), .git/LFS, _UNUSED, and the MW4 deploy dir.
Co-authored-by: Claude Sonnet 4.6 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Update mech_loadouts.csv with derived playability, hardpoint, facing, and loadout annotations, and add mech_loadouts.md as the catch-up reference for future updates.
Co-authored-by: Claude Sonnet 4.6 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Battlemaster stock loadouts (Content\Mechs\Battlemaster\battlemaster.subsystems):
- Replace lone MediumPulseLaser with full IS stock: PPC (Special2, group 1),
6×ML (3 RT + 3 LT, group 1), 2×MG (LA, 200 rds, group 1), SRM6 (Special1,
15 rds, group 2).
Battlemaster Clan 2C (battlemaster2c.subsystems):
- Replace ClanMediumPulseLaser with: ER PPC (RA, group 1), 6×ER ML (3 RT + 3
LT, group 1), 2×Clan Gauss (LA, 16 rds each, group 1), Clan SSRM6 (Special1,
15 rds, group 2).
Behemoth / Behemoth2 (.subsystems):
- Move Gauss rifles from weapon group 3 → group 1 (3 occurrences each).
Resource builder (build-resources.ps1):
- Always run with -window (windowed + DDrawCompat). Fullscreen native DDraw
fails on VMs with the generic Microsoft display adapter.
- Remove dgVoodoo2 D3D interceptors (D3D8/D3D9/D3DImm.dll) from Gameleap\mw4:
they silently break the builder (process exits 0 without packing anything).
Script also defensively moves any such files aside via $dgvMoved block.
- Remove dgVoodoo.conf and dgVoodooCpl.exe (abandoned experiment, no longer used).
- Expected: 'Hardware Error: not compatible with MechWarrior 4' dialog at end
of build on VMs -- click OK, packages are built correctly regardless.
CLAUDE.md: updated with mfdsplit branch notes covering all 2026-07-18 work.
Co-authored-by: Claude Sonnet 4.6 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
ConLobbyMission.script:
- Expand MP time-limit dropdown from 9 to 18 entries (1-15, 20, 25, 30 min)
with max_displayed=10 so the list scrolls cleanly.
- Fix bare else-if syntax (missing braces) that caused null-reference crash
on console lobby load when this was merged from main.
- Fix i==5 vs i==6 max_displayed assignment for time vs radar dropdowns.
build-resources.ps1:
- DDrawCompat's ddraw.dll is fatal to MW4pro.exe in FULLSCREEN but works
in WINDOWED mode. Don't move it aside; instead run the builder with
-window when ddraw.dll is present. This fixes builds on VMs with generic
display adapters (no hardware DirectDraw) and avoids the EnterWindowMode
CreateSurface crash on Win10/11 without a functioning DWM shim.
- Also temporarily set options.ini bitdepth=32 when running without any
ddraw interceptor (bare-metal fallback), restored in finally block.
- Remove stale comment about ddraw being fatal; update interceptor detection
to correctly identify DDrawCompat vs dgVoodoo2 via dgVoodoo.conf presence.
Co-authored-by: Claude Sonnet 4.6 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
