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>
Root cause of the broken MFD2 display: CMFD_Device::BeginScene() cleared
the right device back buffer at old sh_step==0, but with the stagger the
right device flip also fired in that same frame (new sh_step==1 = old
sh_step==0 after increment). The flip presented a just-cleared buffer
with only the grid, no channel data.
Fix: split BeginScene for mode 4 - left device (step 0) vs right device
(step 1). Add BeginSceneRight() called from WinMain at old sh_step==1.
The right device flip at new sh_step==1 (= old sh_step==0) now shows
channels 3-4 rendered at steps 5-6 of the previous cycle - correct.
Cycle for mode 4 with stagger:
old sh_step 0: radar+left BeginScene, no flip
new sh_step 1: flip right MFD (shows prev cycle channels 3-4)
old sh_step 1: right BeginScene (clear+grid)
old sh_step 2-4: channels 0-2 -> left device
old sh_step 5-6: channels 3-4 -> right device
new sh_step 0: flip radar+left MFD (shows prev cycle channels 0-2)
Incremental Release + Profile builds (0 errors) picking up the
CRIOMAIN.CPP UpdateThrottle change; rel.bin\MW4.exe and MW4pro.exe
deployed to MW4\. Build logs in build-env\build_pr4_*.log.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
-tbaud <rate> (9600-921600) overrides the COM1 baud rate while keeping
old-RIO (type 0) protocol behavior unchanged; independent of -trio.
SetupComm buffers 2/2 -> 1024/1024 only when the override is active.
Rebuilt Release + Profile (0 errors), deployed rel.bin\MW4.exe to MW4\.
run-firestorm driver: game-start now takes optional extra args.
CLAUDE.md: branch notes incl. the CP949 comment-encoding hazard
(mw4 sources must be edited byte-safely).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
FS507D_20161015 release analysis wrap-up (drop itself is gitignored; art-review
folder kept local for review):
- Recovered the only assets our tree lacked: 13 hsh HUD/radar/mech bmps and the
two 5.07D lobby decals (decal_46/47.tga, extracted from release props.mw4 via
a ported gos_LZDecompress).
- ResourceImagePool.cpp: missing-texture placeholder is now LAB_ONLY (editor
keeps degraded mode); Release restores the original fatal STOP. Release +
Profile rebuilt, 0 errors.
Console script reconciled:
- ConLobby.script.new ("BattleTech Console V5.0.7Df", newest revision anywhere)
promoted to Content\ShellScripts\ConLobby.script; .new removed; stale loose
deploy copy removed. Verified in-game (console title shows V5.0.7Df).
- Corrected CLAUDE.md: the release never "renamed" the console to
ComputerPlayer.script -- the resource packer stores script contents under
alphabetically skewed entry names (runtime resolves the same pairing).
Packer quirks documented (stale entry carry-forward on incremental builds,
name/content skew in directory sweeps).
Mechlab bug fix (first FireStorm bug hunt):
- New-Mech dialog showed blank rows for Wolfhound/Zeus and crashed (KERNELBASE
read AV) when creating a Zeus. Root cause: newmech in chassis.script created
its Type droplist without setting $$m_listBoxSize$$, so capacity defaulted to
60 while 65 chassis were written in -- OOB script-array writes. Fixed by
sizing the list from $$m_chassisCount$$. Latent stock-MW4 bug armed when the
FireStorm roster passed 60 chassis. Verified: Zeus variant creates cleanly.
props.mw4 fully repacked (decals + promoted console + mechlab fix, junk
.new/.org entries gone); game deploy refreshed at MW4\. Gitignore: FS507D drop
and player-created MW4\Resource\Variants.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Complete disaster-recovery snapshot: engine/game source, game data assets,
VC6 toolchain + DX SDKs, build outputs, deployed game, and _UNUSED archive.
Large binaries in Git LFS; text preserved byte-for-byte (core.autocrlf=false,
no eol attributes). See RECOVERY.md for the one-clone rebuild procedure.
CydandClaude Fable 5