feat(input): Implement SDL3 input and window management

[mirelle7]

SDL3 Input Backend
This PR updates the windowing and input pipeline to use SDL3 by default on modern toolchains (non-VC6 builds) to DirectInput and Win32 window creation. By utilizing SDL3, we bypass DirectInput emulation layers on modern systems, providing a lower-latency pipeline for Windows 11 and Wine/Linux users.

Input handling
Unified event manager that centralizes keyboard, mouse, and gamepad events into a thread-safe buffer

Gamepad Support (v0.1)
This is an initial baseline implementation focused on providing functional out-of-the-box playability. Feedback is encouraged regarding the ergonomics and logic of these default mappings.

Input	Action
Left Stick	Virtual mouse cursor
Right Stick	Camera pan (arrow keys)
LT (hold)	Currently unmapped
RT (hold)	Force Attack (LCTRL)
LB	Select All (Q)
RB	Queue Orders (LSHIFT)
A	Left click
AA	Guard mode
B	Right click
X	Attack Move (A)
Y	Stop (S)
D-Pad	Control groups 1–4
Start	Menu (ESC)
Back	Last radar event (SPACE)
L3	Next idle worker
R3	Snap to command center

Scope Note: This implementation provides a hardcoded default layout to establish core functionality. Advanced features, such as input remapping, radial menus, adjustable deadzones, are currently out of scope for this PR and may be addressed in future iterations.

This SDL3 input/windowing backend builds on prior work from the community:

• fbraz3
• Fighter19
• feliwir
• Bobby Battista
• Stephan Meesters

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The SDL3 backend reaches the runtime window and input paths for both games on modern builds.

Fix closing the minimized game and satisfy the required statement format before merging.

Findings

1.  Minimized game will not close ▶
2.  Statement bodies share breakpoint lines ▶

Summary

Adds SDL3 window creation and input for modern builds, while retaining the legacy backend as an option.

• Modern builds start the games through an SDL3 window.
• SDL3 input turns keyboard, mouse, and gamepad events into game actions.
• Controller movement changes how the camera scrolls.
• Builds can select SDL3 and bring in its required libraries.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[SDL events] --> B[SDL3InputManager]
    B --> C[Keyboard and mouse queues]
    C --> D[Game update]
    D --> E[Message handlers]
    B --> F[Quit message]
    F --> E
    G[Minimized loop] --> B
    B --> G
    E --> H[Quit game]

Loading

_{Reviews (39) · Last reviewed commit: "fix(sdl3): keep virtual double-click tim..." · Reviewed by Greptile}

[xezon]

This needs polishing. Not yet reviewed extensively until the obvious style issues are fixed.

[xezon]

Perhaps also check Fighter19's fork for SDL related implementations. As far as I am aware he has it all done.

[mirelle7]

I have looked at all existing forks and attributed where possible.

[bobtista]

How about changing display-mode? eg getDisplayModeCount() / getDisplayModeDescription() using SDL_GetFullscreenDisplayModes + desktop mode + resolution filtering. EDIT: Also account for mouse position which can sometimes not match clicks to cursor position.

[bobtista]

Is it better to use SDL3InputManager (+ SDL3CursorManager) or to split out SDL3Keyboard + SDL3Mouse that subclass the engine's existing Keyboard/Mouse base classes?

[xezon]

Will we have a SDL3Main or not?

[mirelle7]

I've started cleaning up the style and structural issues in the latest commits.

Regarding SDL3Main: The main benefit of the current approach is that we keep the game's native Win32 WinMain entry point and startup sequence intact.

To get rid of the #ifdef blocks in WinMain while minimizing duplication, I can move the window initialization out into SDL3Window.

Regarding splitting out subclasses: I don't think splitting the input handling into isolated SDL3Keyboard and SDL3Mouse subclasses is the right way. It runs contrary to how SDL3 tries to be a unified way; it relies on a single event pump where all keyboard, mouse, and gamepad signals flow together.

[xezon]

I don't think splitting the input handling into isolated SDL3Keyboard and SDL3Mouse subclasses is the right way.

But this is how you currently have set this up. What is the plan here?

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to GitHub limitations.

⚠️ Outside diff range comments (1)

🟡 Minor · 🎯 Functional Correctness · SDL3Input.cpp:948

Core/GameEngineDevice/Source/SDL3Device/GameClient/SDL3Input.cpp:948
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

The review comment is supported. virtualPulseMouse() keeps lastClickTime across all SDL3InputManager instances and does not reset it when virtual gamepad inputs are released. A reconnect or manager recreation within 350 ms can mark the first virtual mouse press as a double click. Move the timestamps into SDL3InputManager and reset them in releaseGamepadVirtualInputs().

---

ℹ️ Review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: db189db8-6cfb-452c-b2a2-49b47c374e0b

📥 Commits

Reviewing files that changed from the base of the PR and between 138be1c and f9e8aea.

📒 Files selected for processing: 2

• Core/GameEngineDevice/Include/SDL3Device/GameClient/SDL3Input.h
• Core/GameEngineDevice/Source/SDL3Device/GameClient/SDL3Input.cpp

🚧 Files skipped from review as they are similar to previous changes: 1

• Core/GameEngineDevice/Include/SDL3Device/GameClient/SDL3Input.h

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 2 remain after this review.

[macroscopeapp]

🟡 Medium GameClient/SDL3Cursor.cpp:74

initResources ignores loose cursor overrides in TheGlobalData->m_modDir, so directory mods display the base game's cursor or fail to load a cursor that exists only in the mod. It always passes the base Data/Cursors/... path to FileSystem::openFile, which does not prepend the mod directory; try the mod-prefixed path first, then fall back to the base path.

🤖 Copy this AI Prompt to have your agent fix this:

In file @Core/GameEngineDevice/Source/SDL3Device/GameClient/SDL3Cursor.cpp around line 74:

`initResources` ignores loose cursor overrides in `TheGlobalData->m_modDir`, so directory mods display the base game's cursor or fail to load a cursor that exists only in the mod. It always passes the base `Data/Cursors/...` path to `FileSystem::openFile`, which does not prepend the mod directory; try the mod-prefixed path first, then fall back to the base path.

[macroscopeapp]

🟡 Medium GameClient/SDL3Input.cpp:1058

Diagonal left-stick input produces cursor velocity above targetSpeed: after stickMagnitude is clamped to 1, (0.9, 0.9) is divided by 1, yielding a direction with length about 1.27. Preserve the original magnitude for direction normalization and clamp only the magnitude used for the response.

 	float stickMagnitude = sqrtf(lx * lx + ly * ly);
+	float directionMagnitude = stickMagnitude;
 	if (stickMagnitude > 1.0f)
 		stickMagnitude = 1.0f;
@@
-		float dirX = lx / stickMagnitude;
-		float dirY = ly / stickMagnitude;
+		float dirX = lx / directionMagnitude;
+		float dirY = ly / directionMagnitude;

🤖 Copy this AI Prompt to have your agent fix this:

In file @Core/GameEngineDevice/Source/SDL3Device/GameClient/SDL3Input.cpp around lines 1058-1066:

Diagonal left-stick input produces cursor velocity above `targetSpeed`: after `stickMagnitude` is clamped to 1, `(0.9, 0.9)` is divided by 1, yielding a direction with length about 1.27. Preserve the original magnitude for direction normalization and clamp only the magnitude used for the response.

[macroscopeapp]

🟠 High Main/AppMain.cpp:85

Launches using -useCwd or -setCwd keep the executable directory as the working directory, so relative asset paths resolve from the wrong location and files may fail to load. This unconditional SetCurrentDirectory(buffer) overrides an earlier parseCommandLineForStartup() call, while the later call at line 101 skips parsing once it has already run; remove this duplicate directory change and let the existing CommandLine/WorkingDirectory logic choose the directory.

- 	// Set working directory to executable folder
- 	Char buffer[_MAX_PATH];
- 	GetModuleFileName(nullptr, buffer, sizeof(buffer));
- 	if (Char* pEnd = strrchr(buffer, '\\'))
-	{
-		*pEnd = 0;
-	}
-	::SetCurrentDirectory(buffer);

🤖 Copy this AI Prompt to have your agent fix this:

In file @Core/Main/AppMain.cpp around lines 85-92:

Launches using `-useCwd` or `-setCwd` keep the executable directory as the working directory, so relative asset paths resolve from the wrong location and files may fail to load. This unconditional `SetCurrentDirectory(buffer)` overrides an earlier `parseCommandLineForStartup()` call, while the later call at line 101 skips parsing once it has already run; remove this duplicate directory change and let the existing `CommandLine`/`WorkingDirectory` logic choose the directory.

[macroscopeapp]

🟡 Medium Common/SDL3GameEngine.cpp:249

Typing committed text into a focused editable combo drops every character, so its text cannot be updated. GadgetComboBoxInput ignores GWM_IME_CHAR on the combo itself; resolve combo targets to GadgetComboBoxGetEditBox() before dispatching the characters.

Suggested change

	TheWindowManager->winSendInputMsg(targetWindow, GWM_IME_CHAR, static_cast<WindowMsgData>(wideText[i]), 0);
	TheWindowManager->winSendInputMsg(BitIsSet(targetWindow->winGetStyle(), GWS_COMBO_BOX) ? GadgetComboBoxGetEditBox(targetWindow) : targetWindow, GWM_IME_CHAR, static_cast<WindowMsgData>(wideText[i]), 0);

🤖 Copy this AI Prompt to have your agent fix this:

In file @Core/GameEngineDevice/Source/SDL3Device/Common/SDL3GameEngine.cpp around line 249:

Typing committed text into a focused editable combo drops every character, so its text cannot be updated. `GadgetComboBoxInput` ignores `GWM_IME_CHAR` on the combo itself; resolve combo targets to `GadgetComboBoxGetEditBox()` before dispatching the characters.

[macroscopeapp]

🟡 Medium GameClient/SDL3Input.cpp:416

An unmapped scancode makes getKey() return KEY_NONE while later keyboard events remain queued, so Keyboard::updateKeys() stops processing and delays releases such as an arrow-key release. Skip unmapped events in getKey() and return KEY_NONE only when the queue is empty.

🤖 Copy this AI Prompt to have your agent fix this:

In file @Core/GameEngineDevice/Source/SDL3Device/GameClient/SDL3Input.cpp around line 416:

An unmapped scancode makes `getKey()` return `KEY_NONE` while later keyboard events remain queued, so `Keyboard::updateKeys()` stops processing and delays releases such as an arrow-key release. Skip unmapped events in `getKey()` and return `KEY_NONE` only when the queue is empty.

[greptile-apps]

Minimized game will not close

Closing the game while it is minimized can leave it running indefinitely. When TheMessageStream is ready, this handler only queues MSG_META_DEMO_INSTANT_QUIT. The minimized loop keeps polling events but never calls GameEngine::update() to consume that message, so getQuitting() stays false.

Set a quit flag that this loop can see, or leave the loop when a close request arrives.

[greptile-apps]

Statement bodies share breakpoint lines

The new release handlers put each if body on the same line as its condition. The repository requires if, else, for, and while bodies on separate lines so developers can place breakpoints on the body. Split these statements across lines before merging.

The same pattern appears in the button callbacks at lines 1189 and 1243, and elsewhere in this file.

Rule Used: Always place if/else/for/while statement bodies on separate lines from the condition to allow precise debugger breakpoint placement. Prefer the format: cpp if (condition) doSomethingNextLine(); over: ```cpp if (condition) doSomethingOnSam... (source)

Learned From
TheSuperHackers/GeneralsGameCode#2067

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!

[greptile-apps]

Comments Outside Diff

These findings could not be posted inline.

•  m pos.z left uninitialized Core/GameEngine/Source/GameClient/View.cpp:63 ▶

  m_pos.zero() was replaced with explicit x/y assignments, but m_pos.z is never set. This propagates garbage into groundToCameraVector.z in GameAudio.cpp via groundToCameraVector.sub(&groundPos), which runs before groundPos.z is assigned from TheTerrainLogic. The wrong zScale = desiredHeight / groundToCameraVector.z value can misplace the audio microphone.

  The same omission occurs in View::init() around line 91.

  	m_pos.x = 0;
  	m_pos.y = 0;
  	m_pos.z = 0;