Change embedded window options to use three stacked dots and add HDR info

[allenwp]

This PR depends on #118076. This parent PR's two commits have been included in this PR.

What problem(s) does this PR solve?

• Closes Add SDR/HDR mode indicator to game view godot-proposals#13903
  • See this proposal for details on the problems this PR solves.
• Implements a small part of Clean up & clarify game embed toolbar godot-proposals#14445
• Leaves the door open for further improvements to the "embed on next play" and "make floating on next play" checkboxes, such as what is proposed in Improve Run bar: include embed option & consolidate buttons godot-proposals#14491

What is the rationale for the approach used in this PR?

SDR Behaviour

State	Screenshot
Before
After

By moving the game window pop-up menu to a three dots icon, the issue demonstrated in this stream should be resolved, or at least mitigated until a better and more substantial change has been implemented. Placing this three dots icon next to the game window size label should be an intuitive location to find game window options, such as the embedded window sizing.

Additionally, the game window size label is now always visible when the game is running, even if it is not embedded. This change was needed for displaying HDR info when the window is not embeded...

HDR Behaviour

A tooltip explains what the floating point value beside the "HDR" text represents: it's the maximum linear value. Additional HDR info is presented in this tooltip.

Importantly, no further HDR configuration options are provided beyond toggling Window.hdr_output_requested. In the future, a slider should be provided to allow the user to limit the output maximum linear value to preview the appearance of different screen capabilities. This should be added in a followup PR when a maximum linear value limit parameter has been added to Godot. More details in this comment.

Much of the remaining design rationale can be found in godotengine/godot-proposals#13903.

Was generative AI (LLM AI) used to create a portion of this PR?

When starting this PR, I took inspiration from https://github.com/DarkKilauea/godot/tree/editor/hdr-game-mode, which was created using AI tools. Although I copied some of the functions and approach when starting, I have re-wrote and re-worked it to be my own.

Are there any parts of this PR that you are uncertain of or require special attention from reviewers?

• I really have no idea what I'm doing with the TTRC macro. Am I using it correctly throughout this PR? This has been resolved!

I've tested this to find it works well on Windows, macOS, and Fedora KDE plasma.

[allenwp]

I see that code that uses RD::get_singleton() is often wrapped with RD_ENABLED, but I don't actually know if this is appropriate in this case. Let me know if I shouldn't have this here.

[DarkKilauea]

It should be needed since RenderingDevice is not defined if that option is off.

[allenwp]

Should the rendering_device.h include also be wrapped in RD_ENABLED if that’s the case?

[Calinou]

I really have no idea what I'm doing with the TTRC macro. Am I using it correctly throughout this PR?

TTRC() means "extract this string for translation, but don't translate it immediately. Instead, let the engine's autotranslation handle it, typically in Control nodes."

TTRC() allows for runtime language changes without having to handle NOTIFICATION_TRANSLATION_CHANGED manually. Therefore, the editor tries to use it as much as possible to reduce the number of lines of code needed to support runtime language changes.

You should use TTRC() for text that does not use placeholders like vformat() and is part of a Control node that has autotranslation enabled (which is the default). Otherwise, you should use TTR() as the engine won't perform translation automatically.

[allenwp]

Thanks, Calinou! Very helpful explanation. And it also pointed me to TTR(), which has some good documentation in the comments of its declaration.

I've updated the use of TTRC() and TTR() to be what I believe is correct usage.

[Calinou]

Tested locally on Linux/X11 (no HDR support), it works as expected. Code, docs and UX look good to me.

Note that while the project is loading, showing the dropdown will show a section without any options:

The option appears once the project is done loading:

It's not a big issue, but I thought I'd mention it nonetheless. Maybe we should show a temporary "Loading..." item while the project is still loading, as a section without any items looks odd.

[stuartcarnie]

I have tested on a MacBook Pro M4 Max on Tahoe 26.4 and confirm it works as expected.

Built-in Display (HDR)	External Display (no HDR)

[AdriaandeJongh]

Tested and works as expected. Agree with @Calinou's remark though:

Maybe we should show a temporary "Loading..." item while the project is still loading, as a section without any items looks odd.

[allenwp]

I'm moving this back to "To Ratify" because I believe the suggestion that was provided by the reviewers to have "Loading..." written when the game is still loading is a good idea. It should also be fairly trivial to implement, so I should have it finished very shortly.

[allenwp]

I've pushed a change to add the "Loading..." text suggestion. I also added some cleanup code to make sure that subsequent runs don't display stale information while the debugger is loading.

Because this PR depends on #118076, it shouldn't be merged until that prerequisite has been merged.

[DarkKilauea]

LGTM, would like to see the luminance settings, but I understand the complications around that right now. Getting the HDR output status of the game is great for now.

[arkology]

Please note that "Renderer or..." line after translation will be much longer and will cover a big part of screen. This is already a problem with "Make Game Workspace...", but "Renderer or..." line will make it even worse.

[AdriaandeJongh]

Could perhaps be shortened to 'rendering driver'.

[allenwp]

I’ll change it to just be “Renderer”, since the rendering device driver is a configuration of the renderer.

I’ll also see if I can add a tooltip to these error labels that gives some instruction to the user on how to resolve this. It would include mentioning changing the renderer or rendering device driver for this error.

[allenwp]

I've adjusted the text to be shorter and added tooltips for instructing the user on how to change things to allow for HDR output:

Tooltip for when the display server doesn't support HDR output is:

Try changing the display/display_server/driver
advanced project setting to a display server
that supports HDR output."

I believe this resolves all outstanding comments.

Edit: hmm, maybe I should write “Change…” and “Move…” instead of “Try changing…” and “Try moving…”

[allenwp]

Sorry, it always takes me a few tries to get wording of user-facing text into an optimal state. I've pushed an update to tooltip text:

[Calinou]

Works great now 🙂 Code looks good to me.

One future improvement would be to change the unsupported tooltip on Linux/*BSD specifically to mention that the user should switch to the Wayland display driver, so that it's more explicit than just switching to "a display driver that supports HDR". This can be done separately still.

That said, maybe we can push for godotengine/godot-proposals#11583 for 4.8, making this less important to have in the future (since native Wayland would be the default).

[Repiteo]

Thanks!

[neikeq]

I'm getting SIGSEGV here because game_size_label is NULL.

_camera_override_menu_id_pressed is being called from the constructor before game_size_label is initialized. It's called with p_id: CAMERA_MODE_INGAME, which result in a switch case code path that calls _update_debugger_buttons.

[neikeq]

Opened #118547 with a bit more info.

[DySeath]

By moving the game window pop-up menu to a three dots icon, the issue demonstrated in this stream should be resolved, or at least mitigated until a better and more substantial change has been implemented. Placing this three dots icon next to the game window size label should be an intuitive location to find game window options, such as the embedded window sizing.

I don't think it mitigates the issue shown in this stream and, in fact, makes it harder to discover in some cases.

Assuming I'm not missing something obvious:
In the editor, the "window size label" is not visible. When running the game in non-embedded mode, it is not visible either because you would be focusing on the extracted game and not on the game tab in the editor.
It seems to be the case for the streamer you've shared since both "Embed Game on Next Play" and "Make Game Workspace Floating on Next Play" are disabled in the stream segment you've shared when he finally finds the setting.

Running the game in non-embed mode seems necessary when you want to record only the game. For example, I'm not a streamer but I make a short recording every day for my teammates with OBS, so I have to deactivate it.

I think for this use case, the three dots in the far right corner looks like settings for this part of the editor UI, instead of other settings for the game view itself, since they are separated from other game view settings.

I think the issue can be mitigated by aligning both window size and the three dots on the left with other game view settings.

I agree this issue will be solved if this proposal (godotengine/godot-proposals#14445) is implemented but for the time being it seems a usability regression to me.

For context I've tested in both 4.7 beta1 and 4.7 beta2.

I hope this message is clear enough and it helps. Thank you for your work. It is still very much appreciated.