feature(headless): Add ViewDummy for headless mode by bobtista · Pull Request #2246 · TheSuperHackers/GeneralsGameCode

bobtista · 2026-02-02T22:42:59Z

Summary

Adds ViewDummy class in Core/GameEngine/Include/GameClient/View.h with no-op implementations for headless mode
Factory in W3DInGameUI returns dummy when m_headless is true
Refactors InGameUI::init() to always create TheTacticalView, but only init/attach to display when TheDisplay exists
Empty xfer() to skip view block in saves

Greptile Overview

Greptile Summary

This PR introduces a ViewDummy implementation for headless mode and routes W3DInGameUI::createView() to return it when TheGlobalData->m_headless is set. InGameUI::init() is adjusted to always create TheTacticalView, but only initializes and attaches it when TheDisplay exists.

This fits the existing UI/view architecture by making view creation unconditional (so other systems can reference TheTacticalView even without graphics), while avoiding display-dependent initialization when running headless.

Main things to double-check are (1) save/load compatibility expectations for headless-produced saves (view serialization/state), and (2) startup ordering assumptions around TheGlobalData being non-null when createView() runs.

Confidence Score: 3/5

This PR is plausible to merge but has a couple of initialization/compatibility edge cases that could cause headless startup crashes or inconsistent state.
Core approach (dummy view + display-gated init) is straightforward, but there are a few high-impact edge cases: createView() dereferences TheGlobalData without an explicit guarantee it’s initialized, and moving setDefaultView() under the display check can leave view defaults unset when a view exists without a display. Save/load compatibility for headless-generated saves also needs an explicit decision/implementation for view serialization.
Core/GameEngine/Include/GameClient/View.h; Generals/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h; GeneralsMD/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h

Important Files Changed

Filename	Overview
Core/GameEngine/Include/GameClient/View.h	Adds `ViewDummy` no-op view for headless mode; needs explicit decision on save/load serialization compatibility and formatting/style consistency.
Generals/Code/GameEngine/Source/GameClient/InGameUI.cpp	Refactors `InGameUI::init()` to always create tactical view and only init/attach when `TheDisplay` exists; risk of leaving view defaults uninitialized in non-display paths.
Generals/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h	Factory now returns `ViewDummy` when `TheGlobalData->m_headless`; unguarded `TheGlobalData` dereference can crash if called before global init.
GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp	Same tactical view creation/attach refactor as vanilla; same risk around when `setDefaultView()` runs.
GeneralsMD/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h	Same headless `createView()` change as vanilla; same unguarded `TheGlobalData` dereference risk.

Sequence Diagram

sequenceDiagram
  participant Caller as Game startup / load
  participant UI as InGameUI::init()
  participant W3DUI as W3DInGameUI::createView()
  participant GD as TheGlobalData
  participant View as View / ViewDummy / W3DView
  participant Disp as TheDisplay

  Caller->>UI: init()
  UI->>W3DUI: createView()
  W3DUI->>GD: read m_headless
  alt headless
    W3DUI-->>UI: new ViewDummy
  else graphics
    W3DUI-->>UI: new W3DView
  end
  UI->>View: (optional) setDefaultView(...)
  alt TheDisplay exists
    UI->>View: init()
    UI->>Disp: attachView(View)
    UI->>View: setWidth/Height(display)
  else no display
    UI-->>Caller: view exists but not attached
  end

greptile-apps

_{5 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-02T22:45:54Z

Generals/Code/GameEngine/Source/GameClient/InGameUI.cpp

 	// create the tactical view
-	if (TheDisplay)
+	TheTacticalView = createView();
+	if (TheTacticalView && TheDisplay)
 	{
-		TheTacticalView = createView();
 		TheTacticalView->init();
 		TheDisplay->attachView( TheTacticalView );

 		// make the tactical display the full screen width and height
 		TheTacticalView->setWidth( TheDisplay->getWidth() );
 		TheTacticalView->setHeight( TheDisplay->getHeight() );
+		TheTacticalView->setDefaultView(0.0f, 0.0f, 1.0f);
 	}


TheTacticalView->setDefaultView(...) is now only called inside the if (TheTacticalView && TheDisplay) block. In headless mode (or any scenario where TheDisplay == nullptr), this skips setting the view's default parameters, which can leave downstream code reading uninitialized/incorrect view defaults.

If the intent is “always create the view, always set its default parameters, but only init/attach/size when a display exists”, consider moving setDefaultView(0.0f, 0.0f, 1.0f) back outside the display check (guarded only by TheTacticalView).

Prompt To Fix With AI

This is a comment left during a code review. Path: Generals/Code/GameEngine/Source/GameClient/InGameUI.cpp Line: 1242:1253 Comment: `TheTacticalView->setDefaultView(...)` is now only called inside the `if (TheTacticalView && TheDisplay)` block. In headless mode (or any scenario where `TheDisplay == nullptr`), this skips setting the view's default parameters, which can leave downstream code reading uninitialized/incorrect view defaults. If the intent is “always create the view, always set its default parameters, but only init/attach/size when a display exists”, consider moving `setDefaultView(0.0f, 0.0f, 1.0f)` back outside the display check (guarded only by `TheTacticalView`). How can I resolve this? If you propose a fix, please make it concise.

This is an empty no-op function in the base class, so calling or not calling it makes no difference. In headless mode, a ViewDummy is used which doesn't need camera defaults since there's no camera.

greptile-apps · 2026-02-02T22:45:55Z

Core/GameEngine/Include/GameClient/View.h

+// TheSuperHackers @feature bobtista 31/01/2026
+// View that does nothing. Used for Headless Mode.
+class ViewDummy : public View
+{
+public:
+	virtual Drawable *pickDrawable( const ICoord2D *screen, Bool forceAttack, PickType pickType ) { return nullptr; }
+	virtual Int iterateDrawablesInRegion( IRegion2D *screenRegion, Bool (*callback)( Drawable *draw, void *userData ), void *userData ) { return 0; }
+	virtual void forceRedraw() {}
+	virtual const Coord3D& get3DCameraPosition() const { static Coord3D zero = {0,0,0}; return zero; }
+	virtual WorldToScreenReturn worldToScreenTriReturn(const Coord3D *w, ICoord2D *s ) { return WTS_INVALID; }
+	virtual void screenToWorld( const ICoord2D *s, Coord3D *w ) {}
+	virtual void screenToTerrain( const ICoord2D *screen, Coord3D *world ) {}
+	virtual void screenToWorldAtZ( const ICoord2D *s, Coord3D *w, Real z ) {}
+	virtual void drawView( void ) {}
+	virtual void updateView(void) {}
+	virtual void stepView() {}
+	virtual void setGuardBandBias( const Coord2D *gb ) {}
+
+protected:
+	virtual void xfer( Xfer *xfer ) {}
+};


ViewDummy::xfer() is overridden to a no-op, which will prevent the base View snapshot data from being serialized/deserialized. This can corrupt saves/replays if a headless-generated save is later loaded in a non-headless context, or if any code expects View::xfer() to run to keep snapshot CRC/state consistent.

If the goal is to skip only view blocks during save, it may be safer to keep calling View::xfer(xfer) (or gate the no-op on xfer->getXferMode() / a headless flag) rather than fully disabling serialization for this type.

Prompt To Fix With AI

This is a comment left during a code review. Path: Core/GameEngine/Include/GameClient/View.h Line: 334:354 Comment: `ViewDummy::xfer()` is overridden to a no-op, which will prevent the base `View` snapshot data from being serialized/deserialized. This can corrupt saves/replays if a headless-generated save is later loaded in a non-headless context, or if any code expects `View::xfer()` to run to keep snapshot CRC/state consistent. If the goal is to skip only view *blocks* during save, it may be safer to keep calling `View::xfer(xfer)` (or gate the no-op on `xfer->getXferMode()` / a headless flag) rather than fully disabling serialization for this type. How can I resolve this? If you propose a fix, please make it concise.

Do we ever plan on generating saves in headless mode, then loading them in full graphics mode? If yes, this is worth addressing

Based on the context from PR #2139, I can see that the goal is to support saving games in headless mode and loading them later. The testing checklist even includes "Load the headless-created save in normal mode and verify it works" which directly answers your question.

Yes, you do plan to generate saves in headless mode and load them in full graphics mode. This is evident from:

PR bugfix(savegame): Fix crashes when saving a game in headless mode #2139's testing requirements: The checklist specifically includes loading headless-created saves in normal mode

The broader headless context: This appears to be for running dedicated servers or automated simulations that need to save state and potentially transfer it to clients

Given this, the empty ViewDummy::xfer() implementation is problematic because:

When a headless save is loaded in graphics mode, the View snapshot data will be missing/corrupted

The CRC mismatch could cause save validation failures

Any code expecting View state to be preserved across save/load cycles will break

Recommendation: Call View::xfer(xfer) to preserve the base snapshot data, then conditionally skip only the graphics-specific blocks if needed. This ensures save compatibility while still avoiding unnecessary visual data serialization.

Do we ever plan on generating saves in headless mode, then loading them in full graphics mode? If yes, this is worth addressing

Maybe not at the moment, perhaps useful in the future though for troubleshooting or generating specific scenarios programmatically or something like that?

greptile-apps · 2026-02-02T22:45:56Z

Core/GameEngine/Include/GameClient/View.h

+// TheSuperHackers @feature bobtista 31/01/2026
+// View that does nothing. Used for Headless Mode.
+class ViewDummy : public View


The new ViewDummy block adds // TheSuperHackers @feature bobtista ... comments. If this repository is enforcing the standardized prologue/no-author-comments rule, these author-tag comments may violate that convention even though they aren't in the file prologue. Consider removing the author attribution and keeping only the functional description (e.g. “Dummy view used for headless mode”).

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review. Path: Core/GameEngine/Include/GameClient/View.h Line: 334:336 Comment: The new `ViewDummy` block adds `// TheSuperHackers @feature bobtista ...` comments. If this repository is enforcing the standardized prologue/no-author-comments rule, these author-tag comments may violate that convention even though they aren't in the file prologue. Consider removing the author attribution and keeping only the functional description (e.g. “Dummy view used for headless mode”). Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time! How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-02T22:45:57Z

Core/GameEngine/Include/GameClient/View.h

+	virtual Drawable *pickDrawable( const ICoord2D *screen, Bool forceAttack, PickType pickType ) { return nullptr; }
+	virtual Int iterateDrawablesInRegion( IRegion2D *screenRegion, Bool (*callback)( Drawable *draw, void *userData ), void *userData ) { return 0; }
+	virtual void forceRedraw() {}
+	virtual const Coord3D& get3DCameraPosition() const { static Coord3D zero = {0,0,0}; return zero; }
+	virtual WorldToScreenReturn worldToScreenTriReturn(const Coord3D *w, ICoord2D *s ) { return WTS_INVALID; }
+	virtual void screenToWorld( const ICoord2D *s, Coord3D *w ) {}
+	virtual void screenToTerrain( const ICoord2D *screen, Coord3D *world ) {}
+	virtual void screenToWorldAtZ( const ICoord2D *s, Coord3D *w, Real z ) {}
+	virtual void drawView( void ) {}
+	virtual void updateView(void) {}
+	virtual void stepView() {}
+	virtual void setGuardBandBias( const Coord2D *gb ) {}
+


ViewDummy overrides many methods with one-liners on the same line as the signature (e.g. virtual void forceRedraw() {}). If the project rule is to keep bodies on separate lines for breakpoint placement, these should be expanded.

This pattern also appears in Generals*/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h for createView().

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review. Path: Core/GameEngine/Include/GameClient/View.h Line: 339:351 Comment: `ViewDummy` overrides many methods with one-liners on the same line as the signature (e.g. `virtual void forceRedraw() {}`). If the project rule is to keep bodies on separate lines for breakpoint placement, these should be expanded. This pattern also appears in `Generals*/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h` for `createView()`. Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time! How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-02T22:45:58Z

Generals/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h

+	// TheSuperHackers @fix bobtista 31/01/2026 Return dummy in headless mode
+	virtual View *createView( void ) { return TheGlobalData->m_headless ? NEW ViewDummy : NEW W3DView; }


createView() dereferences TheGlobalData unconditionally (TheGlobalData->m_headless). If this factory can run before global data initialization, this will crash in headless startup paths. If TheGlobalData is guaranteed non-null here, it may be worth asserting; otherwise guard with a null check (defaulting to W3DView or ViewDummy depending on intended behavior).

Also appears in GeneralsMD/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h:73-74.

Prompt To Fix With AI

This is a comment left during a code review. Path: Generals/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h Line: 73:74 Comment: `createView()` dereferences `TheGlobalData` unconditionally (`TheGlobalData->m_headless`). If this factory can run before global data initialization, this will crash in headless startup paths. If `TheGlobalData` is guaranteed non-null here, it may be worth asserting; otherwise guard with a null check (defaulting to `W3DView` or `ViewDummy` depending on intended behavior). Also appears in `GeneralsMD/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h:73-74`. How can I resolve this? If you propose a fix, please make it concise.

…build error

greptile-apps

_{5 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-03T19:10:41Z

Generals/Code/GameEngine/Source/GameClient/InGameUI.cpp

 	been moved to where all the other translators are attached in game client */

 	// create the tactical view
-	if (TheDisplay)
+	TheTacticalView = createView();


[P0] TheTacticalView is now always created, but setDefaultView() is only called when TheDisplay exists. Even if View::setDefaultView() is currently a no-op, derived view implementations (e.g., W3DView) may rely on it to initialize camera defaults; in headless mode this can leave view state uninitialized while still being used by non-display code paths.

Consider calling TheTacticalView->setDefaultView(0.0f, 0.0f, 1.0f); unconditionally after createView() (guarded only by TheTacticalView), and keep only init/attach/size under the display check.

Prompt To Fix With AI

This is a comment left during a code review. Path: Generals/Code/GameEngine/Source/GameClient/InGameUI.cpp Line: 1240:1243 Comment: [P0] `TheTacticalView` is now always created, but `setDefaultView()` is only called when `TheDisplay` exists. Even if `View::setDefaultView()` is currently a no-op, derived view implementations (e.g., `W3DView`) may rely on it to initialize camera defaults; in headless mode this can leave view state uninitialized while still being used by non-display code paths. Consider calling `TheTacticalView->setDefaultView(0.0f, 0.0f, 1.0f);` unconditionally after `createView()` (guarded only by `TheTacticalView`), and keep only `init/attach/size` under the display check. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-03T19:10:42Z

Core/GameEngine/Include/GameClient/View.h

+// TheSuperHackers @feature bobtista 31/01/2026
+// View that does nothing. Used for Headless Mode.
+class ViewDummy : public View


[P0] ViewDummy no longer overrides xfer(), but it also doesn’t provide any serialization behavior of its own. If headless mode saves are expected to be loadable in non-headless mode, the view block still needs to be written/read in a compatible way (either by calling View::xfer(xfer) or by writing a compatible stub block). Otherwise, headless-created saves may be missing view data or desync snapshot CRC/state.

If the intent is “dummy view but still serialize base view state”, explicitly add virtual void xfer(Xfer* xfer) override { View::xfer(xfer); }.

Prompt To Fix With AI

This is a comment left during a code review. Path: Core/GameEngine/Include/GameClient/View.h Line: 334:336 Comment: [P0] `ViewDummy` no longer overrides `xfer()`, but it also doesn’t provide any serialization behavior of its own. If headless mode saves are expected to be loadable in non-headless mode, the view block still needs to be written/read in a compatible way (either by calling `View::xfer(xfer)` or by writing a compatible stub block). Otherwise, headless-created saves may be missing view data or desync snapshot CRC/state. If the intent is “dummy view but still serialize base view state”, explicitly add `virtual void xfer(Xfer* xfer) override { View::xfer(xfer); }`. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-03T19:10:43Z

Generals/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h

 protected:

 	/// factory for views


[P0] createView() dereferences TheGlobalData unconditionally (TheGlobalData->m_headless). If W3DInGameUI::init() (or any caller of createView()) can run before TheGlobalData is initialized, this will crash on startup.

Either guard (if (TheGlobalData && TheGlobalData->m_headless) ...) or add an assertion documenting the initialization order guarantee.

Prompt To Fix With AI

This is a comment left during a code review. Path: Generals/Code/GameEngineDevice/Include/W3DDevice/GameClient/W3DInGameUI.h Line: 70:72 Comment: [P0] `createView()` dereferences `TheGlobalData` unconditionally (`TheGlobalData->m_headless`). If `W3DInGameUI::init()` (or any caller of `createView()`) can run before `TheGlobalData` is initialized, this will crash on startup. Either guard (`if (TheGlobalData && TheGlobalData->m_headless) ...`) or add an assertion documenting the initialization order guarantee. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-03T19:10:44Z

Core/GameEngine/Include/GameClient/View.h

+// TheSuperHackers @feature bobtista 31/01/2026
+// View that does nothing. Used for Headless Mode.
+class ViewDummy : public View


[P2] The new ViewDummy includes author-tag comments (// TheSuperHackers @feature bobtista ...). If this repo is trying to keep attribution out of code comments (and especially out of headers), consider replacing these with a short functional comment (e.g., // Dummy view used in headless mode). This keeps the header consistent with the rest of the codebase’s style conventions.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review. Path: Core/GameEngine/Include/GameClient/View.h Line: 334:336 Comment: [P2] The new `ViewDummy` includes author-tag comments (`// TheSuperHackers @feature bobtista ...`). If this repo is trying to keep attribution out of code comments (and especially out of headers), consider replacing these with a short functional comment (e.g., `// Dummy view used in headless mode`). This keeps the header consistent with the rest of the codebase’s style conventions. Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time! How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-03T19:10:45Z

Core/GameEngine/Include/GameClient/View.h

+{
+public:
+	virtual Drawable *pickDrawable( const ICoord2D *screen, Bool forceAttack, PickType pickType ) { return nullptr; }


[P3] Several ViewDummy overrides put the body on the same line as the signature (e.g., forceRedraw() {}). If you’re following the project’s breakpoint-friendly formatting rule, expand these to put the body on its own line.

Also appears in Generals*/.../W3DInGameUI.h for createView().

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review. Path: Core/GameEngine/Include/GameClient/View.h Line: 337:339 Comment: [P3] Several `ViewDummy` overrides put the body on the same line as the signature (e.g., `forceRedraw() {}`). If you’re following the project’s breakpoint-friendly formatting rule, expand these to put the body on its own line. Also appears in `Generals*/.../W3DInGameUI.h` for `createView()`. Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time! How can I resolve this? If you propose a fix, please make it concise.

bobtista added 2 commits February 2, 2026 16:41

feature(headless): Add ViewDummy for headless mode

e765ce7

feature(headless): Replicate ViewDummy to Generals

0cec07f

greptile-apps bot reviewed Feb 2, 2026

View reviewed changes

bobtista added 2 commits February 3, 2026 13:06

bugfix(headless): Fix ViewDummy xfer save corruption and VC6 ternary …

a0c3c50

…build error

bugfix(headless): Replicate VC6 ternary build fix to Generals

e30fa7a

greptile-apps bot reviewed Feb 3, 2026

View reviewed changes

		// TheSuperHackers @fix bobtista 31/01/2026 Return dummy in headless mode
		virtual View *createView( void ) { return TheGlobalData->m_headless ? NEW ViewDummy : NEW W3DView; }

Conversation

bobtista commented Feb 2, 2026

Summary

Related

Uh oh!

greptile-apps bot commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Overview

Greptile Summary

Confidence Score: 3/5

Important Files Changed

Sequence Diagram

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

bobtista Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

bobtista Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

tintinhamans Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

greptile-apps bot commented Feb 2, 2026 •

edited

Loading