Non-Thrive related Godot 4 things

[hhyyrylainen]

Godot engine problems that impact Thrive:

• Godot 4.0 editor opens on wrong monitor (DisplayServer regression) godotengine/godot#56340
• Implement support for seamless display scaling on Windows and Linux (for multi-monitor setups with different DPI) godotengine/godot#56341
• Godot 4.0 does not find .NET native DLLs that aren't in the directory the editor is installed in godotengine/godot#65866 (discovered through: FileLoadException when trying to call Steamworks functions in Godot 4 chickensoft-games/GameTemplate#1) Not actually a problem thanks to the more flexible C# native library loading in .NET 6
• The godot older (non-vulkan) fallback renderer needs to have the 3D support finished for it
• Testing Godot 4 on a Windows 7 machine and with integrated graphics to confirm older hardware compatibility is ready in Godot 4
• Add Breakpad for crash dump generation godotengine/godot#56014 getting that merged to the engine would be really nice to no longer have to make our releases with an engine fork
• DevBuilds will need to keep working (the tool for those will need at least some changes: Add support for writing Godot 4 .pck files hhyyrylainen/GodotPckTool#33)
• Reimplementing unhandled exception printer for launcher easy detection Options for dealing with unhandled C# exceptions present in Godot 3 are missing in Godot 4 godotengine/godot#73515 opened as a separate issue: Launcher cannot detect game exceptions anymore with Godot 4 #5623
• Tracked with another issue: Crash in Godot engine 4 on shutdown #4998

Some notes for when we need to do the conversion:

• x11 renamed in godot 4.0 to linuxbsd (though not everywhere...)

[Zireael07]

You'll likely need to run godotengine/godot#51950 , too (I have my own project that is slowly being converted, and it looks like it'll be the only way as the project is fairly big)

[hhyyrylainen]

Good to know that kind of thing exists. Seems like it's missing csproj conversion meaning there'd still be at least some manual work for us...

I doubt we'll need it anytime soon as I don't think we'll be changing to 4.0 before it has been released as the stable Godot version. We'll maybe hold off on that until the first patches 4.0.1 or 4.1 come out.

[hhyyrylainen]

4.0 should fix the marshalling type width problem that I had saved a link to: https://github.com/godotengine/godot/blob/3.4.2-stable/modules/mono/mono_gd/gd_mono_marshal.cpp#L577

[hhyyrylainen]

Seems like my PR to Godot that has been open for a really long time didn't get any attention after 4.0 release: godotengine/godot#56014

I guess the Godot developers are really busy... If anyone more familiar with Godot development reads this, any help with getting that PR and the blocking bugs in Godot 4 resolved would be awesome. It's not out of the question for us to sponsor specific Godot engine development monetarily to get Godot 4 into shape for use in Thrive much faster.

[Zireael07]

If anyone more familiar with Godot development reads this, any help with getting that PR and the blocking bugs in Godot 4 resolved would be awesome

Unfortunately the only way to get a PR in seems to be "hurry up and wait"... :/

[hhyyrylainen]

One more thing I remembered was that I read that the OpenGL renderer for older hardware support was maybe not fully ready yet in time for 4.0. Can someone check that? As that's something we need to confirm works before officially switching.

[Zireael07]

@hhyyrylainen I tried the renderer for a 2D game and it works great, zero issues. But I know from browsing the issues/PRs that e.g. 3D shadows are NOT implemented in OpenGL yet.

[hhyyrylainen]

Okay, so it maybe partly works? We use 3D rendering for the entire game so that has to work. But thanks for at least confirming my suspicion that some parts of the OpenGL renderer are not ready yet.

[GameDungeon]

godotengine/godot#65866 Seems to have a user-side workaround now, though reading the comments it looks unlikely we will see anything on the godot side to resolve it.

[hhyyrylainen]

Well the situation with the new .NET runtime is better as we can specify the load paths manually (also can intelligently automatically pick debug or release library version). Right now it took a huge amount of trial and error to find out how to determine which folders Godot 3 actually looks for DLLs in to load when told to from C#.

[skyace65]

The compatibility renderer is still missing stuff I believe, (not sure if there's a tracker for it somewhere) but 3D shadows were added in 4.2 godotengine/godot#77496

Additionally, not sure if this changes the want for Win 7 compatibility but Steam is going to be dropping support for Win 7 machines (as well as 8 and 8.1) https://help.steampowered.com/en/faqs/view/4784-4F2B-1321-800A

[hhyyrylainen]

Windows 7 compatibility is no longer required (with Steam finally dropping it we might be safe to drop it as well without getting more negative Steam reviews). So that's one less consideration. With the fallback renderer I guess it just needs to be tried unless there's still a known list of missing features we could check out. Things are looking like Godot 4.3 would be ready for us to switch, and well if not we'll just need to deal with it while prioritising getting the game working again on lower end hardware.