@Calinou

Unfortunately, handling CTRL-C and ensuring the child process terminates is a lot more challenging, as the macOS app terminates without cleanly tearing down.

I might be able to have the child process monitor the debugger connection and shutdown if it is terminated.

Unfortunately, handling CTRL-C and ensuring the child process terminates is a lot more challenging, as the macOS app terminates without cleanly tearing down.

Doesn't it work with the SIGINT handler we register in

void OS_Unix::initialize_debugging() {
        if (EngineDebugger::is_active()) {
                struct sigaction action;
                memset(&action, 0, sizeof(action));
                action.sa_handler = handle_interrupt;
                sigaction(SIGINT, &action, nullptr);
        }
}

I'm not too familiar with macOS but I'd be surprised if it couldn't react to SIGINT in a customized way so we can clean up child processes before terminating the editor process.

Doesn't it work with the SIGINT handler we register in

That is installed in the child (embedded) process. If we send SIGINT to the editor, when running via a terminal, it immediately terminates. I expect I can install a SIGINT handler that posts a quit to shut down gracefully.

I will try that!

@Calinou / @akien-mga SIGINT is now properly handled and Godot terminates child processes

@Calinou temporarily moving to draft, until I fix the following issue:

#106134 (comment)

I can replicate it, so I'll be able to resolve it.

@Calinou I've now resolved the scaling issue described by a couple of our users, so this PR is ready for review

It's better now. 24" Full HD (1920 x 1080)
It just needs to be initialized properly at startup.

There are still minor issues, but not critical.
For example, in pause mode, it doesn't always scale correctly.

Good feedback, @Alex2782, thanks for testing! We should be able to address both issues.

Pause Mode issue

We would need to re-render the frame, but I am not aware of an API in Godot we can use. I'll ask around. The alternative is to step by one frame to refresh the rendered output at the new resolution, but that is less than ideal, as the gameplay would be moving forward.

Initialised at startup

I'll check that out – it seems the startup parameters don't match when the display is 1x 👍🏻

@Alex2782 I haven't been able to reproduce the incorrect initial size. I've reordered the messages sent at startup, so that the window size should be correct, based on the current desktop window scaling.

The paused output is an issue when not embedding too, as the frame is not re-rendered. The difference is that the background colour is updated when the window redraws. We can probably do something similar, which I will look at.

I'm not entirely convinced about graceful shutdown on Ctrl+C, I would expect it to kill process instantly, but I guess it's just my personal preference.

SIGINT and SIGTERM are expected to gracefully terminate, if possible, by handling the signal. SIGKILL can't be handled, so it always kills the process instantly. If we don't handle it, it results in unexpected and undesired behaviour, as the embedded process continues to run in the background, consuming CPU, and the user isn't aware. The user would have to manually kill the process, via Activity Monitor or other means.

Thanks!

Merging now to include in 4.5-dev4, Stuart will work on the remaining points in a follow-up.

When using Metal in Truck Town (Forward+/Mobile), the sky takes the background color of the game window

I broke this in #106340, should be fixed by #106355 (while keeping transparency support).