Cameraship Map/Armor diagnostics: -tmr ladder, draw counter, CTCL type log

Investigating a field report that the cameraship secondary armor/score/map
screen showed its background BMP but no overlay graphics "on certain video
cards". The video card was a red herring: the machine was launched with
-ctcltype 2 (game pod) instead of 3 (cameraship), and the overlay block in
hudchat.cpp is gated on CTCL_GetType()==_ECTCL_CameraShip, so it never ran.

This is hard to spot because the two gates are independent. HSH_EnterFullScreen2
and CMR_Device open the screen and paint its background based purely on whether
a spare secondary monitor exists, and never consult the CTCL role. A wrong
-ctcltype therefore yields a screen that lights up, shows the correct artwork
and renders nothing, which is visually identical to a DirectDraw failure. The
same background-only screen also appears on a game pod when an MFD mode finds no
dual-head span and falls through to the single-secondary mr_device path.

Diagnostics added:

- render.cpp: log the CTCL type in gos-displays.txt from HSH_EnterFullScreen2,
  via the existing g_pfnCTCL_GetType hook so GameOS gains no game-code
  dependency. Always logged, and states in words whether overlays will be drawn.
- render.cpp/.hpp: CHSH_Device::m_nDrawCalls, incremented in DrawQuad,
  DrawThickFrame and DrawTexture, reset in CMR_Device::BeginScene and reported
  for the first 5 frames from CMR_Device::EndScene when -tmr is active. Zero
  draws proves the overlay code never ran; non-zero with a blank screen would
  mean it ran and drew invisibly. This distinction is what settled the case.
- render.cpp: log CMR_Device surface creation plus the overlay texture's
  dimensions, depth and channel masks.
- New -tmr <0-3> switch (MW4Application.cpp, documented in -help): 0 normal,
  1 background blit with DDBLTFAST_WAIT|DDBLTFAST_NOCOLORKEY, 2 Clear instead of
  the background blit, 3 as 2 plus alpha blending off and an untextured magenta
  DrawQuad.

Mode 3 drew magenta and mode 2 was pure black, which cleared the 3D device, the
flip and the background blit in two runs; the draw counter then reported 0 and
pointed straight at the gate. Documented as STEP 11 in CLAUDE.md, including the
field triage rule: read "CTCL type =" in gos-displays.txt before suspecting
drivers.

Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>

CLAUDE.md

@@ -1039,7 +1039,13 @@ rebuild between attempts. Results (no dgVoodoo2, shim applied, `-tmfds 4`):
 **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, not bound by that rule.**
-=> **dgVoodoo2 cannot be removed for `-tmfds 1/3/4` by fixing flags.** Default stays `-tcoop 0`.
+=> **dgVoodoo2 cannot be removed by fixing flags.** The limitation is per *secondary display*,
+not per feature, so it applies to **every mode that opens a second monitor** — all MFD modes
+(`-tmfds 1/3/4`) **and cameraship mode**, which drives two displays with no MFDs at all via the
+single-secondary `mr_device` path (`IsMultimonitorAvaliable()` returns false for
+`_ECTCL_CameraShip`, so it falls to `IsSecondaryMonitorAvaliable()` — still a second exclusive
+IDirectDraw7). **Console mode is the only configuration that needs no dgVoodoo2**, because it is
+single-display. Default stays `-tcoop 0`.
 (`-tcoop` is retained: it is how this was settled and will re-settle it on different hardware.)
 
 ### ✅ Working 4-monitor config (WITH dgVoodoo2)
@@ -1106,6 +1112,61 @@ Smaller than it sounds because the mechanisms already exist:
 - New switches are documented in `-help` (`-fps` under LOGGING AND DIAGNOSTICS, `-tcoop` under
   DISPLAY AND VIDEO).
 
+## STEP 11: Cameraship Map/Armor screen shows background but no overlays — SOLVED
+## (2026-07-26): it is the CTCL role, NOT the video card
+
+Reported as *"the secondary armor/score/map screen in cameraship mode shows the background BMP
+fine but none of the overlay graphics, with certain video cards but not others"*. **The video
+card is a red herring. The machine was not being told it was a cameraship.**
+
+### Root cause
+`-ctcltype <n>` maps **straight** to the role enum — no remapping
+(`MW4Application.cpp:~1534`, `g_nCTCL = token[0]-'0'`; `ctcl_params.h`):
+`1 = console`, **`2 = game pod`**, **`3 = cameraship`**, `4 = none`.
+The failing launch line used `-ctcltype 2` (game pod). The overlay drawing in
+`mw4\Code\MW4\hudchat.cpp:~596` is gated on
+`bool draw_mr = CTCL_GetType()==_ECTCL_CameraShip;` (`#ifdef _DEBUG` -> unconditional `true`),
+so with role 2 the overlay block simply never executes. Fixed by launching `-ctcltype 3`
+(user-confirmed working).
+
+### ⚠️ Why this is so hard to spot — the two gates are INDEPENDENT
+**The Map/Armor screen opens and paints its background regardless of the CTCL role.**
+`HSH_EnterFullScreen2` / `CMR_Device` decide purely on *"is a spare secondary monitor
+available?"* and never consult `CTCL_GetType()`; only `hudchat.cpp` checks the role. So a wrong
+`-ctcltype` produces a screen that lights up, shows the correct artwork, survives mode changes
+and renders nothing — **visually identical to a graphics-card/DirectDraw fault**, which is
+exactly why it got mis-attributed to specific GPUs. Diagnose it from `gos-displays.txt`
+(`CTCL type = ...`), never by eye.
+- Corollary: `mr_device` also opens in **non-cameraship** configs. Observed here with
+  `-tmfds 1` when `g_nDualHead = -1` (no spanned pair found): MFD mode 1 fell through to the
+  single-secondary `mr_device` path on a *game pod*, giving the same background-only screen.
+- **Field triage:** on a failing machine read that pod's `ctcl.ini` launch line and its
+  `gos-displays.txt`. `CTCL type = 2` means it is misconfigured, not broken.
+
+### Diagnostics added (kept)
+- **`CTCL type = <n>` line in `gos-displays.txt`** (`render.cpp` `HSH_EnterFullScreen2`, via the
+  already-present `g_pfnCTCL_GetType` hook — no game-code dependency). Always logged, states in
+  words whether overlays will be drawn. One look settles the question.
+- **`-tmr <0-3>`** Map/Armor diagnostic ladder (`g_nMRDiag`, `CMR_Device::BeginScene`):
+  0 = normal, 1 = background blit with `DDBLTFAST_WAIT|DDBLTFAST_NOCOLORKEY`,
+  2 = `Clear` instead of the background blit, 3 = additionally alpha-blend off + untextured
+  magenta `DrawQuad`. Results that cracked this: **3 drew magenta** (device/3D/flip all fine),
+  **2 was pure black** (the background blit was never erasing the overlays), 1 unchanged.
+- **Draw-call counter** — `CHSH_Device::m_nDrawCalls`, bumped in `DrawQuad` / `DrawThickFrame` /
+  `DrawTexture`, reset in `CMR_Device::BeginScene`, reported for the first 5 frames from
+  `CMR_Device::EndScene` when `g_nMRDiag` is set. **This was the decisive instrument:**
+  `0 draw call(s)` proves the overlay code never ran (a gating problem), whereas non-zero with a
+  blank screen would mean it ran and drew invisibly (texture/alpha). Keep it — it separates
+  "not running" from "not visible" in one run.
+- Also logged: `CMR_Device` surface creation (`pDDSBackground`/`pDDSTexture`/`pDDSMapTexture`)
+  plus the overlay texture's size/bpp and channel masks. Healthy reference reading on the W4100:
+  `256x256 16bpp a=0000F000 r=00000F00 g=000000F0 b=0000000F` (normal 4-bit alpha, not zero).
+
+### Method note
+Every hypothesis reasoned forward from the code was wrong again (blit erasing overlays; alpha
+channel; per-GPU rendering). The `-tmr` ladder plus the draw-call counter settled it in two runs.
+Consistent with the rest of STEP 10: **instrument, don't infer.**
+
 ## Next steps (proposed)
 - [ ] (Decision pending) Borderless-windowed migration — see the staged assessment in STEP 10.
   Step 2 (one panel) is the cheap, decisive experiment. Note this is the only route that would

Gameleap/code/CoreTech/Libraries/GameOS/render.cpp

@@ -486,6 +486,7 @@ CHSH_Device::CHSH_Device()
 	pDDSTarget=0;
 	pDDSTexture=0;
 	pD3DDevice=0;
+	m_nDrawCalls=0;	// [mrdiag]
 	tw=512;
 	th=512;
 }
@@ -527,6 +528,14 @@ const DWORD dwFlags = DDSCL_SETFOCUSWINDOW | DDSCL_CREATEDEVICEWINDOW |
 // Selected with -tcoop <0-3>.  See CHSH_Device::InitFirst for what each one does.
 int g_nHshCoopMode = 0;
 
+// [mrdiag] Cameraship secondary-screen (Map/Armor) diagnostic mode, -tmr <0-3>.
+//   0 = unchanged
+//   1 = wait for the background blit to finish before starting the 3D scene
+//   2 = skip the background blit entirely (Clear instead)
+//   3 = as 2, plus draw a solid magenta quad to prove whether ANY 3D output lands
+// See CMR_Device::BeginScene.
+int g_nMRDiag = 0;
+
 extern HRESULT wDirectDrawCreateEx( GUID* lpGUID, void** lplpDD, REFIID iid, IUnknown* pUnkOuter );
 
 //
@@ -932,6 +941,7 @@ bool CHSH_Device::Release()
 
 void CHSH_Device::DrawQuad(int x1,int y1,int x2,int y2,DWORD dwColor)
 {
+	m_nDrawCalls++;	// [mrdiag]
 	D3DTLVERTEX Vertices[4]; // Vertices for the cube
 
 	Vertices[0] = D3DTLVERTEX(D3DVECTOR(  (float)x1-0.5f, (float)y2-0.5f,0.9f),1.0f,dwColor,0, 0.0f, 1.0f );
@@ -1041,6 +1051,7 @@ void CHSH_Device::DrawFrameList(int framecount,RECT * prc,DWORD dwColor)
 
 void CHSH_Device::DrawThickFrame(int x1,int y1,int x2,int y2,int t,DWORD dwColor)
 {
+	m_nDrawCalls++;	// [mrdiag]
 	if(t>1){
 		RECT rc[4]={
 			{x1  ,y1  ,x2  ,y1+t},
@@ -1149,6 +1160,7 @@ void CHSH_Device::DrawTexture2(float x,float y,float w,float h,DWORD dwColor, fl
 //Not scaled....
 void CHSH_Device::DrawTexture(float x,float y,DWORD dwColor, float u1,float v1,float u2,float v2)
 {
+	m_nDrawCalls++;	// [mrdiag]
 	D3DTLVERTEX v[4];
 	float w=u2-u1;
 	float h=v2-v1;
@@ -1233,6 +1245,26 @@ bool CMR_Device::InitSecond()
 	//3. Texture for map..
 	pDDSMapTexture=CreatePixelFormatTexture(pDD,256,256,&DDPF_R5G6B5);
 
+	// [mrdiag] Report what actually got created.  A missing surface here produces a
+	// screen that shows some things and not others, which is very hard to interpret
+	// from the outside - the original code only beeped when the background failed.
+	HSH_LogInit( "     CMR_Device surfaces:\r\n" );
+	HSH_LogInit( "       pDDSBackground  = %s\r\n", pDDSBackground ? "ok" : "*** NULL ***" );
+	HSH_LogInit( "       pDDSTexture     = %s\r\n", pDDSTexture    ? "ok" : "*** NULL ***" );
+	HSH_LogInit( "       pDDSMapTexture  = %s\r\n", pDDSMapTexture ? "ok" : "*** NULL ***" );
+	if( pDDSTexture ) {
+		DDSURFACEDESC2 dsd; ZeroMemory(&dsd,sizeof(dsd)); dsd.dwSize=sizeof(dsd);
+		if( SUCCEEDED(pDDSTexture->GetSurfaceDesc(&dsd)) )
+			HSH_LogInit( "       overlay texture : %lux%lu %lubpp  a=%08lX r=%08lX g=%08lX b=%08lX\r\n",
+				(unsigned long)dsd.dwWidth, (unsigned long)dsd.dwHeight,
+				(unsigned long)dsd.ddpfPixelFormat.dwRGBBitCount,
+				(unsigned long)dsd.ddpfPixelFormat.dwRGBAlphaBitMask,
+				(unsigned long)dsd.ddpfPixelFormat.dwRBitMask,
+				(unsigned long)dsd.ddpfPixelFormat.dwGBitMask,
+				(unsigned long)dsd.ddpfPixelFormat.dwBBitMask );
+	}
+	HSH_LogInit( "       -tmr diagnostic mode = %d\r\n", g_nMRDiag );
+
 	tw=256;
 	th=256;
 
@@ -1247,11 +1279,32 @@ bool CMR_Device::BeginScene()
 	//SetRenderTargetTexture();
 
 
-	//Draw background image to Texture. Used as a substitute for Clear..
+	// [mrdiag] The cameraship secondary screen is the ONLY panel with no offscreen
+	// render target (InitSecond(0,0)), so it blits its background straight onto the
+	// back buffer and then renders 3D into that same surface.  The blit below is
+	// issued with flags 0 - no DDBLTFAST_WAIT - and nothing ever checks GetBltStatus,
+	// while every other blit in the engine uses DDBLT_WAIT.  If a driver does not
+	// serialise its 2D blit engine against the 3D pipeline, that blit can land after
+	// the frame's 3D draws and erase them, leaving only the background.
+	//
+	// -tmr selects between the possibilities so they can be told apart on real hardware.
 	if(sh_game_started){
 		//Draw background only when game has started.
 		RECT rc={0,0,640,480};
-		pDDSBack->BltFast(0,0,pDDSBackground,&rc,0);
+
+		switch( g_nMRDiag )
+		{
+		case 1:		// wait for the blit to complete before any 3D is issued
+			pDDSBack->BltFast(0,0,pDDSBackground,&rc,DDBLTFAST_WAIT|DDBLTFAST_NOCOLORKEY);
+			break;
+		case 2:		// no background at all - if the overlays appear, the blit was erasing them
+		case 3:
+			pD3DDevice->Clear(0,NULL,D3DCLEAR_TARGET,0,1.0f,0);
+			break;
+		default:	// 0 = original behaviour
+			pDDSBack->BltFast(0,0,pDDSBackground,&rc,0);
+			break;
+		}
 	}else{
 		//If game has not started.. show blank.
 		pD3DDevice->Clear(0,NULL,D3DCLEAR_TARGET ,0,1.0f,0);
@@ -1259,12 +1312,33 @@ bool CMR_Device::BeginScene()
 
 	pD3DDevice->BeginScene();
 
+	// [mrdiag] mode 3: a solid untextured quad. If even this does not appear, nothing
+	// this device draws in 3D is reaching the screen, and the background blit is
+	// innocent - the fault is in the 3D pass itself.
+	if( g_nMRDiag==3 ) {
+		pD3DDevice->SetRenderState( D3DRENDERSTATE_ALPHABLENDENABLE, FALSE );
+		pD3DDevice->SetTexture(0,0);
+		DrawQuad( 64, 64, 576, 416, 0xFFFF00FF );	// magenta
+	}
+
 	pD3DDevice->SetTexture(0,pDDSTexture);
+	m_nDrawCalls=0;		// [mrdiag] count what the game draws between here and EndScene
 	return true;
 }
 
 bool CMR_Device::EndScene()
 {
+	// [mrdiag] Report how many draws the game actually issued on this device. Zero means
+	// the overlay code never ran (a gating problem, not a rendering one); a non-zero count
+	// with a blank screen means it ran and drew nothing visible.
+	{
+		static int s_nFrames=0;
+		if( g_nMRDiag && s_nFrames<5 ) {
+			s_nFrames++;
+			HSH_LogInit( "   [mrdiag] frame %d: game issued %d draw call(s) on the Map/Armor screen\r\n",
+						 s_nFrames, m_nDrawCalls );
+		}
+	}
 	pD3DDevice->EndScene();
 	if( gCaptureScreen && (gCaptureDevice == 2))
 	{
@@ -2931,6 +3005,19 @@ void HSH_EnterFullScreen2()
 	HSH_LogInit( "\r\nHSH_EnterFullScreen2\r\n" );
 	HSH_LogInit( "--------------------\r\n" );
 
+	// [mrdiag] The cameraship Map/Armor overlays are drawn by hudchat.cpp only when
+	// CTCL_GetType() reports _ECTCL_CameraShip (3). If it reports anything else the
+	// screen still opens and still shows its background, but nothing is ever drawn on
+	// it - which looks identical to a rendering fault.
+	if( g_pfnCTCL_GetType ) {
+		int nType=(*g_pfnCTCL_GetType)();
+		HSH_LogInit( "  CTCL type = %d%s\r\n", nType,
+					 (nType==_ECTCL_CameraShip) ? "  (cameraship - overlays WILL be drawn)"
+											   : "  (NOT cameraship - Map/Armor overlays will NOT be drawn)" );
+	} else {
+		HSH_LogInit( "  CTCL type = unavailable (g_pfnCTCL_GetType is NULL)\r\n" );
+	}
+
 	if(IsMultimonitorAvaliable()){
 		HSH_LogInit( "  path: multi-monitor (MFD + radar)\r\n" );
 
@@ -2970,9 +3057,19 @@ void HSH_EnterFullScreen2()
 		}
 	}else if(IsSecondaryMonitorAvaliable()){
 		HSH_LogInit( "  path: single secondary monitor (mr_device)\r\n" );
-		mr_device.InitFirst();
-		mr_device.InitSecond();
-		hsh_mrdev_initialized=true;
+		bool bMR = mr_device.InitFirst();
+		if( bMR )
+			bMR = mr_device.InitSecond();
+		// [panelcoop] same reasoning as the MFD path above: do not claim the device is
+		// live if it never came up, or the per-frame code runs on null surfaces.
+		if( bMR ) {
+			hsh_mrdev_initialized=true;
+			HSH_LogInit( "  result: cameraship secondary screen initialised OK\r\n" );
+		} else {
+			HSH_LogInit( "  result: *** cameraship secondary screen FAILED - continuing without it ***\r\n" );
+			mr_device.Release();
+			hsh_mrdev_initialized=false;
+		}
 	}else{
 		HSH_LogInit( "  path: none - no secondary displays opened\r\n" );
 	}

Gameleap/code/CoreTech/Libraries/GameOS/render.hpp

@@ -89,6 +89,7 @@ public:
 	SIZE size_back;
 	SIZE size_target;
 	float tw,th;//texture width,height
+	int m_nDrawCalls;	// [mrdiag] draws issued since the last BeginScene
 	CHSH_Device();
 
 	bool InitFirst(int devicenum,DWORD resx,DWORD resy, CHSH_Device* pOtherHSHD = NULL);

Gameleap/code/mw4/Code/MW4Application/MW4Application.cpp

@@ -98,6 +98,9 @@ extern int g_nFpsLog;
 // [panelcoop] SetCooperativeLevel form used by the radar/MFD panels; 0 = legacy.
 // Defined in CoreTech GameOS render.cpp.
 extern int g_nHshCoopMode;
+// [mrdiag] Cameraship secondary-screen (Map/Armor) diagnostic mode; 0 = normal.
+// Defined in CoreTech GameOS render.cpp.
+extern int g_nMRDiag;
 extern LONG g_ThrottleDir;
 extern bool g_bCanSuicideAllways;
 extern bool g_f3dtarget;
@@ -881,6 +884,14 @@ static const char* const g_apszCommandLineHelp[] =
 "                                 panels never contend for it.",
 "                             5 = as 4, plus ALLOWREBOOT.",
 "                             Results are reported in gos-displays.txt.",
+"  -tmr <0-3>                 Cameraship Map/Armor screen diagnostics.",
+"                             0 = normal.",
+"                             1 = wait for the background blit to finish before",
+"                                 drawing the overlays.",
+"                             2 = skip the background image entirely.",
+"                             3 = as 2, plus a solid magenta test rectangle.",
+"                             Use when that screen shows its background but no",
+"                             overlay graphics or text.",
 "  -mechview <1|2>            Show the rotating mech view. 1 = on the radar",
 "  -mv <1|2>                  screen, 2 = on the main screen. Default: off.",
 "  -3dt                       Draw the MFD target as a live 3D model instead of",
@@ -1709,6 +1720,14 @@ int WINAPI WinMain( HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpCmdLine, int n
 		if ((0 <= n) && (n <= 5))
 			g_nHshCoopMode = n;
 	}
+	// [mrdiag] Cameraship Map/Armor screen diagnostics. 0 = normal behaviour.
+	token = strstr(all_lower, "-tmr ");
+	if (token && token[5])
+	{
+		int n = atoi(&token[5]);
+		if ((0 <= n) && (n <= 3))
+			g_nMRDiag = n;
+	}
 	// [fpslog] Enable the per-second frame pacing report written to gos-fps.txt.
 	g_nFpsLog = (strstr(all_lower, "-fps") != NULL) ? 1 : 0;
     g_bCanSuicideAllways = (strstr(all_lower, "-suicide") != NULL);

RELEASE-NOTES-5.1.0b_RC1.html

@@ -56,7 +56,7 @@ If you see it, run <code>set-appcompat.bat</code> and restart the game.</p>
 <hr>
 <h2>2. Multiplayer</h2>
 <h3>16 pilots plus a cameraship now launch correctly</h3>
-<p>Previously, a full 16-pilot game with a cameraship connected would silently fail to launch ?
+<p>Previously, a full 16-pilot game with a cameraship connected would silently fail to launch --
 you pressed launch and nothing happened, with no error. Fixed. A cameraship no longer consumes
 one of the 16 pilot slots.</p>
 <p><strong>No configuration needed.</strong> This applies automatically.</p>
@@ -117,10 +117,14 @@ the zero point could be skipped.</p>
 speed without changing anything else about how the board talks to the game:</p>
 <pre><code>MW4.exe -tbaud 115200
 </code></pre>
-<p>Accepts 9600 to 921600. <strong>Leave it off</strong> and the game uses the original speed, exactly as before ?
+<p>Accepts 9600 to 921600. <strong>Leave it off</strong> and the game uses the original speed, exactly as before --
 existing original RIO boards need no change and should not use this switch.</p>
-<p>This is only the speed. The wire protocol is untouched. (The separate <code>-trio 1</code> switch changes
-the whole protocol and is <em>not</em> what you want for a replica board.)</p>
+<p><strong>Whether a particular rate actually works is a hardware question, not a software one.</strong> The
+game will happily set any rate in that range, but both ends have to support it: the serial
+UART in the pod PC, and the RIO or replica RIO board itself. If a rate misbehaves -- garbled
+input, dropped buttons, no response -- step down to a lower one.</p>
+<p>This switch only changes the speed. The wire protocol is untouched. (The separate <code>-trio 1</code>
+switch changes the whole protocol and is <em>not</em> what you want for a replica board.)</p>
 <hr>
 <h2>4. Displays and MFDs</h2>
 <h3>Split MFD mode -- two separate 640x480 MFD monitors</h3>
@@ -133,12 +137,15 @@ and <code>3</code>) are unchanged and remain the default for existing pods.</p>
 <h3>Split MFD stutter -- fixed</h3>
 <p>Early split-MFD builds had a constant rhythmic stutter across the whole game. Fixed. The two MFD
 panels no longer force the graphics card to stall every frame cycle.</p>
-<h3>Required dgVoodoo2 setting for ALL MFD modes on Windows 10/11</h3>
-<p><strong>On Windows 10 and 11, dgVoodoo2 is required for every MFD mode -- including the original
-spanned display (<code>-tmfds 1</code> and <code>-tmfds 3</code>), not only the new split mode (<code>-tmfds 4</code>).</strong></p>
-<p>If your pod drives any MFD or radar panel at all, this applies to you. It is not specific to
-the new split-MFD feature: the underlying Windows limitation affects every mode that lights up
-a second display. On Windows XP none of this was needed.</p>
+<h3>Required dgVoodoo2 setting for any multi-display mode on Windows 10/11</h3>
+<p><strong>On Windows 10 and 11, dgVoodoo2 is required for every mode that uses more than one display.</strong>
+That means all of the MFD modes -- the original spanned display (<code>-tmfds 1</code> and <code>-tmfds 3</code>) as
+well as the new split mode (<code>-tmfds 4</code>) -- <strong>and cameraship mode</strong>, which drives two monitors
+without using MFDs at all.</p>
+<p><strong>Console mode is the only configuration that does not need it</strong>, because it uses a single display.</p>
+<p>The deciding factor is the number of displays, not which feature you are using: anything that
+lights up a second monitor runs into the same Windows limitation. On Windows XP none of this
+was needed.</p>
 <div class="warn"><p><strong>dgVoodoo2 is not part of the build, and must NOT be installed on Windows XP pods.</strong>
 XP uses the graphics support built into Windows and needs nothing extra -- adding dgVoodoo2
 there will break it. It is a per-machine prerequisite that you install yourself, on
@@ -169,6 +176,53 @@ order <strong>main, radar, MFD 1, MFD 2</strong>:</p>
 <p>Use <code>0</code> in any position to leave that one on automatic -- <code>-tmon 2,1,0,0</code> swaps only main and radar.
 <strong>Leave the switch off entirely and everything is detected automatically</strong>, which is correct on
 most pods.</p>
+<p><strong>Which positions apply depends on the MFD mode:</strong></p>
+<table>
+<thead>
+<tr>
+<th>Position</th>
+<th>Display</th>
+<th><code>-tmfds 4</code> (split)</th>
+<th><code>-tmfds 1</code> / <code>-tmfds 3</code> (spanned)</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>1st</td>
+<td>Main</td>
+<td>applies</td>
+<td>applies</td>
+</tr>
+<tr>
+<td>2nd</td>
+<td>Radar</td>
+<td>applies</td>
+<td>applies</td>
+</tr>
+<tr>
+<td>3rd</td>
+<td>MFD 1</td>
+<td>applies</td>
+<td>ignored</td>
+</tr>
+<tr>
+<td>4th</td>
+<td>MFD 2</td>
+<td>applies</td>
+<td>ignored</td>
+</tr>
+</tbody>
+</table>
+<p>In the spanned modes the first two positions work normally, so you can still correct main and
+radar. The 3rd and 4th positions are accepted but have no effect, because the spanned modes
+drive both MFDs from a single wide display rather than two separate ones.</p>
+<p><strong>The spanned MFD display itself cannot be assigned with <code>-tmon</code>.</strong> It is picked automatically
+as the first display that reports a 1280x480 mode -- a distinctive signature that a spanned
+MFD pair produces and ordinary monitors do not, so it normally lands on the right one. If you
+ever need to force it, ask and it can be added.</p>
+<p>If a display comes up in the wrong place, check <code>gos-displays.txt</code> next to the game (see
+section 8). It lists every display found, which role each was given, and whether each <code>-tmon</code>
+position was accepted or ignored.</p>
 <hr>
 <h2>5. 'Mechs and content</h2>
 <h3>Six rookie 'Mechs instead of four</h3>
@@ -255,7 +309,7 @@ so you can also edit it directly.</p>
 external <strong>MySQL</strong> database after each print job, for league tables or long-term stats.</p>
 <p>Configure via <strong>File -&gt; Database Settings (Ctrl+D)</strong>, or the <code>[MySQLExport]</code> section of
 <code>mw4print.ini</code>. The table layout is documented in <code>db_schema.sql</code>.</p>
-<div class="note"><p>?? <strong>This feature has not yet been tested against a live database server.</strong> It is off unless you
+<div class="warn"><p><strong>WARNING: this feature has not yet been tested against a live database server.</strong> It is off unless you
 configure it, and printing works normally without it. If you try it, please report back.</p></div>
 <hr>
 <h2>8. Quality of life</h2>
@@ -294,7 +348,7 @@ start. Previously such failures were completely silent. Include this file with a
 </tr>
 <tr>
 <td><code>-tmon a,b,c,d</code></td>
-<td>Force monitor order: main, radar, MFD1, MFD2</td>
+<td>Force monitor order: main, radar, MFD1, MFD2. Positions 3 and 4 apply only to <code>-tmfds 4</code></td>
 <td>Automatic detection</td>
 </tr>
 <tr>
@@ -322,9 +376,11 @@ start. Previously such failures were completely silent. Include this file with a
 <hr>
 <h2>10. Known issues and limitations</h2>
 <ul>
-<li><strong>Every MFD mode requires dgVoodoo2 on Windows 10/11</strong> -- the spanned modes (<code>-tmfds 1</code>
-  and <code>-tmfds 3</code>) just as much as the split mode (<code>-tmfds 4</code>) -- with scaling set to
-  <code>Stretched, Keep Aspect Ratio</code>. This is a Windows limitation, not a bug we can fix.</li>
+<li><strong>Any multi-display mode requires dgVoodoo2 on Windows 10/11</strong> -- every MFD mode (spanned
+  <code>-tmfds 1</code> / <code>-tmfds 3</code> and split <code>-tmfds 4</code>) and cameraship mode. Console mode, using a
+  single display, is the only exception. Scaling must be set to <code>Stretched, Keep Aspect Ratio</code>.
+  dgVoodoo2 works around a limitation on exclusive full-screen use of multiple displays on
+  platforms after Windows XP. It may be possible to fix this in a future release.</li>
 <li><strong>The MySQL export in mw4print has not been tested against a live server.</strong></li>
 <li><strong>The game renders in 4:3 only.</strong> There is no widescreen mode. On 16:9 monitors, use
   keep-aspect scaling for correct geometry with black bars at the sides.</li>
@@ -338,8 +394,10 @@ start. Previously such failures were completely silent. Include this file with a
 <li>Copy in the new build.</li>
 <li><strong>Double-click <code>set-appcompat.bat</code></strong> (as administrator if the pod has multiple accounts).</li>
 <li><strong>On Windows 10/11, confirm dgVoodoo2 is installed and its scaling mode is
-   <code>Stretched, Keep Aspect Ratio</code>.</strong> This is required for <strong>every</strong> MFD mode -- spanned
-   (<code>-tmfds 1</code> / <code>-tmfds 3</code>) as well as split (<code>-tmfds 4</code>). Windows XP pods do not need it.</li>
+   <code>Stretched, Keep Aspect Ratio</code>.</strong> Required for <strong>any</strong> mode that uses more than one
+   display: all MFD modes (spanned <code>-tmfds 1</code> / <code>-tmfds 3</code>, split <code>-tmfds 4</code>) and cameraship
+   mode. Only console mode, on a single display, does without it. Windows XP pods never
+   need it.</li>
 <li>Launch and confirm the console lobby reads the new version.</li>
 <li>Play one mission end to end before putting the pod back into service.</li>
 <li>Optional: add <code>[automaticmode]</code> and <code>[RookieMission]</code> to <code>options.ini</code> if you want the new

RELEASE-NOTES-5.1.0b_RC1.md

@@ -41,7 +41,7 @@ If you see it, run `set-appcompat.bat` and restart the game.
 
 ### 16 pilots plus a cameraship now launch correctly
 
-Previously, a full 16-pilot game with a cameraship connected would silently fail to launch ?
+Previously, a full 16-pilot game with a cameraship connected would silently fail to launch --
 you pressed launch and nothing happened, with no error. Fixed. A cameraship no longer consumes
 one of the 16 pilot slots.
 
@@ -110,11 +110,16 @@ speed without changing anything else about how the board talks to the game:
 MW4.exe -tbaud 115200
 ```
 
-Accepts 9600 to 921600. **Leave it off** and the game uses the original speed, exactly as before ?
+Accepts 9600 to 921600. **Leave it off** and the game uses the original speed, exactly as before --
 existing original RIO boards need no change and should not use this switch.
 
-This is only the speed. The wire protocol is untouched. (The separate `-trio 1` switch changes
-the whole protocol and is *not* what you want for a replica board.)
+**Whether a particular rate actually works is a hardware question, not a software one.** The
+game will happily set any rate in that range, but both ends have to support it: the serial
+UART in the pod PC, and the RIO or replica RIO board itself. If a rate misbehaves -- garbled
+input, dropped buttons, no response -- step down to a lower one.
+
+This switch only changes the speed. The wire protocol is untouched. (The separate `-trio 1`
+switch changes the whole protocol and is *not* what you want for a replica board.)
 
 ---
 
@@ -137,14 +142,18 @@ and `3`) are unchanged and remain the default for existing pods.
 Early split-MFD builds had a constant rhythmic stutter across the whole game. Fixed. The two MFD
 panels no longer force the graphics card to stall every frame cycle.
 
-### Required dgVoodoo2 setting for ALL MFD modes on Windows 10/11
+### Required dgVoodoo2 setting for any multi-display mode on Windows 10/11
 
-**On Windows 10 and 11, dgVoodoo2 is required for every MFD mode -- including the original
-spanned display (`-tmfds 1` and `-tmfds 3`), not only the new split mode (`-tmfds 4`).**
+**On Windows 10 and 11, dgVoodoo2 is required for every mode that uses more than one display.**
+That means all of the MFD modes -- the original spanned display (`-tmfds 1` and `-tmfds 3`) as
+well as the new split mode (`-tmfds 4`) -- **and cameraship mode**, which drives two monitors
+without using MFDs at all.
 
-If your pod drives any MFD or radar panel at all, this applies to you. It is not specific to
-the new split-MFD feature: the underlying Windows limitation affects every mode that lights up
-a second display. On Windows XP none of this was needed.
+**Console mode is the only configuration that does not need it**, because it uses a single display.
+
+The deciding factor is the number of displays, not which feature you are using: anything that
+lights up a second monitor runs into the same Windows limitation. On Windows XP none of this
+was needed.
 
 > **dgVoodoo2 is not part of the build, and must NOT be installed on Windows XP pods.**
 > XP uses the graphics support built into Windows and needs nothing extra -- adding dgVoodoo2
@@ -186,6 +195,28 @@ Use `0` in any position to leave that one on automatic -- `-tmon 2,1,0,0` swaps
 **Leave the switch off entirely and everything is detected automatically**, which is correct on
 most pods.
 
+**Which positions apply depends on the MFD mode:**
+
+| Position | Display | `-tmfds 4` (split) | `-tmfds 1` / `-tmfds 3` (spanned) |
+|---|---|---|---|
+| 1st | Main | applies | applies |
+| 2nd | Radar | applies | applies |
+| 3rd | MFD 1 | applies | ignored |
+| 4th | MFD 2 | applies | ignored |
+
+In the spanned modes the first two positions work normally, so you can still correct main and
+radar. The 3rd and 4th positions are accepted but have no effect, because the spanned modes
+drive both MFDs from a single wide display rather than two separate ones.
+
+**The spanned MFD display itself cannot be assigned with `-tmon`.** It is picked automatically
+as the first display that reports a 1280x480 mode -- a distinctive signature that a spanned
+MFD pair produces and ordinary monitors do not, so it normally lands on the right one. If you
+ever need to force it, ask and it can be added.
+
+If a display comes up in the wrong place, check `gos-displays.txt` next to the game (see
+section 8). It lists every display found, which role each was given, and whether each `-tmon`
+position was accepted or ignored.
+
 ---
 
 ## 5. 'Mechs and content
@@ -295,7 +326,7 @@ external **MySQL** database after each print job, for league tables or long-term
 Configure via **File -> Database Settings (Ctrl+D)**, or the `[MySQLExport]` section of
 `mw4print.ini`. The table layout is documented in `db_schema.sql`.
 
-> ?? **This feature has not yet been tested against a live database server.** It is off unless you
+> **WARNING: this feature has not yet been tested against a live database server.** It is off unless you
 > configure it, and printing works normally without it. If you try it, please report back.
 
 ---
@@ -337,7 +368,7 @@ start. Previously such failures were completely silent. Include this file with a
 | Switch | Purpose | If you leave it off |
 |---|---|---|
 | `-tmfds 4` | Two separate 640x480 MFD monitors | Existing MFD mode unchanged |
-| `-tmon a,b,c,d` | Force monitor order: main, radar, MFD1, MFD2 | Automatic detection |
+| `-tmon a,b,c,d` | Force monitor order: main, radar, MFD1, MFD2. Positions 3 and 4 apply only to `-tmfds 4` | Automatic detection |
 | `-tbaud <rate>` | COM1 speed for replica RIO boards | Original board speed |
 | `-fps` | Write a performance log | No log, no overhead |
 | `-help` | Show the full switch reference and exit | Game starts normally |
@@ -347,9 +378,11 @@ start. Previously such failures were completely silent. Include this file with a
 
 ## 10. Known issues and limitations
 
-- **Every MFD mode requires dgVoodoo2 on Windows 10/11** -- the spanned modes (`-tmfds 1`
-  and `-tmfds 3`) just as much as the split mode (`-tmfds 4`) -- with scaling set to
-  `Stretched, Keep Aspect Ratio`. This is a Windows limitation, not a bug we can fix.
+- **Any multi-display mode requires dgVoodoo2 on Windows 10/11** -- every MFD mode (spanned
+  `-tmfds 1` / `-tmfds 3` and split `-tmfds 4`) and cameraship mode. Console mode, using a
+  single display, is the only exception. Scaling must be set to `Stretched, Keep Aspect Ratio`.
+  dgVoodoo2 works around a limitation on exclusive full-screen use of multiple displays on
+  platforms after Windows XP. It may be possible to fix this in a future release.
 - **The MySQL export in mw4print has not been tested against a live server.**
 - **The game renders in 4:3 only.** There is no widescreen mode. On 16:9 monitors, use
   keep-aspect scaling for correct geometry with black bars at the sides.
@@ -364,8 +397,10 @@ start. Previously such failures were completely silent. Include this file with a
 2. Copy in the new build.
 3. **Double-click `set-appcompat.bat`** (as administrator if the pod has multiple accounts).
 4. **On Windows 10/11, confirm dgVoodoo2 is installed and its scaling mode is
-   `Stretched, Keep Aspect Ratio`.** This is required for **every** MFD mode -- spanned
-   (`-tmfds 1` / `-tmfds 3`) as well as split (`-tmfds 4`). Windows XP pods do not need it.
+   `Stretched, Keep Aspect Ratio`.** Required for **any** mode that uses more than one
+   display: all MFD modes (spanned `-tmfds 1` / `-tmfds 3`, split `-tmfds 4`) and cameraship
+   mode. Only console mode, on a single display, does without it. Windows XP pods never
+   need it.
 5. Launch and confirm the console lobby reads the new version.
 6. Play one mission end to end before putting the pod back into service.
 7. Optional: add `[automaticmode]` and `[RookieMission]` to `options.ini` if you want the new