Add support for embedding subwindows and dual screen GameViews #104079
+694
−277
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit allows the `GameView` to select either the "Main Window" (default view of the running game) or a subwindow to become embedded when running the project. This information is communicated to the built game via a new `--swid` (subwindow ID) command line parameter which matches the `--wid` implementation created for the original embedding feature. The subwindow is chosen by matching the name of the window to a user provided name which is given in a text box in the `GameView`. This is implemented only for Windows and a follow up PR should be able to match the functionality for Linux easily. Additionally, to utilize this new behavior, there is now the option to enable a second `GameView` that sits above the main one. The second view can embed a different window and has its own embedding controls to improve user debugging. For now, in order to keep the PR smaller, the secondary `GameView` does not utilize its own SceneDebugger, so only the main view can use the runtime selection options. A future PR can open up more functionality for parity with the main view.
RobProductions
force-pushed
the
game-tab-dual-view
branch
from
628d091 to
2fc4344
Compare
|
Rebased to handle the new mute audio button. Like the other debugger controls, it works the same as before on the main game view and is hidden on the secondary view for now to prevent confusion :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes godotengine/godot-proposals#11091
Thanks to guidance from @Hilderin this PR adds two new features to the Game tab and embedding tools that were introduced in Godot 4.4. The first change extends the embedding functionality to allow embedding of "subwindows" (as they're known in
DisplayServer) when provided with a unique window name. The user can now select whether to embed the main window or a custom window that matches the name provided via a text box in the GameView:Capture2025-03-12.13-46-20.mov
This allows developers of multi-window games to embed the game window that makes the most sense for their project rather than being stuck with the main window. This is accomplished through modifications to the display server so that a subwindow can be parented much the same as the main window. In order to send the parenting data to the built game, a new
--swid(subwindow ID) command line parameter was created that matches the--widimplementation for the main window. Then, when theGameViewmodifies the instance parameters, it can optionally send the--swidwith the user provided window name.As suggested by @Hilderin , I took the next step in the proposal to better utilize subwindow embedding here by adding an option to split the Game tab into two GameViews for better visibility while debugging. This was largely done by splitting out functionality that used to be handled by the
GameViewinto theGameViewPluginand having the plugin manage two instances, but all together it works pretty cleanly! A button in the embed options popup lets you split the view and the layout is saved as project metadata, with the default setting being the regular single view that people are familiar with:Capture2025-03-12.13-58-35.mov
Since this PR was already looking like a lot to review, one step I left for a future PR was getting the secondary view's game debugger working properly. This proved challenging to do immediately because we would either need to make the RuntimeSelect stuff not a singleton or we'd need to pass window data through every message sent via the debugger, but I'm certain that one of these solutions will be easier to work out when this initial PR is wrapped up. Besides that, the regular debugger controls for the main GameView are still fully functional:
Capture2025-03-12.14-02-01.mov
Note: This PR only implements subwindow embedding for the Windows display server. Sadly I don't have a Linux machine to test on but Hilderin said it was fine to leave it like this so that a follow up PR can tackle the Linux/Android support which I believe shouldn't be too tough to match from Windows.
Thank you to everyone who offered ideas about the future of embedding in #99010 and I hope this new functionality proves to be helpful for developers looking for more debugging options! Let me know if there's anything I've missed and I'll be happy to make adjustments :)