This worked perfectly - thank you!!

For anyone else looking here later, the final shader code (confirmed working Godot 4.2) is:

shader_type canvas_item;

uniform sampler2D screen_texture : hint_screen_texture;
uniform vec4 water_color : source_color;
uniform sampler2D wave_noise : repeat_enable;

void fragment() {
	vec2 water_wave = (texture(wave_noise, UV * TIME * 0.02).rg - 0.5) * 0.02;
	vec2 uv = vec2(SCREEN_UV.x , SCREEN_UV.y - UV.y) + water_wave;
	vec4 color = texture(screen_texture, uv);
	float mix_value = 1.0 - UV.y;

	float avg_color = (color.r + color.g + color.b) / 3.0;
	avg_color = pow(avg_color, 1.4);
	mix_value += avg_color;

	mix_value = clamp(mix_value, 0.0, 0.7);
	COLOR = vec4(mix(water_color, color, mix_value).rgb, texture(TEXTURE, UV).a);
}

Credits to Single-mindedRyan for creating this shader in the first place.

I’d done that a few days ago, but you’re right, not specifically to these suggestions. I tried the export VKD3D_DISABLE_EXTENSIONS=VK_EXT_mesh_shader VKD3D_FEATURE_LEVEL=12_0 VKD3D_SHADER_MODEL=6_5 %command% and variations of it. It reduced performance significantly, so would not suggest people on more recent Mesa versions try this anymore. When I looked into it, it seemed to mainly be in place for Mesa 22.x which was still lacking mesh shader support.

Thought I’d post an update. Performance is better now, playing in 1440p with FSR2 on Balanced, graphic settings on Medium. I’m getting around 45FPS.

I’m not quite sure what the fix was in the end, but I’ve installed proton-ge-custom-bin from the AUR, so I’ve got Proton GE installed onto my system (not just within Heroic). Both the AUR and Heroic are on Proton-GE 9.7. I then added the AlanWake2.exe file to Steam, and forced compatibility to use Proton GE. So whatever extra was happening with Heroic was taken away.

I tried changing my Mesa drivers, but it appears Manjaro is even with the nonfree repo at this point, so I’m still on Mesa 24.1.1, only on the Manjaro-approved version, not the mainline Arch version.

It appears that somewhere within that combination of (1) running the game directly from Steam, (2) using the system-installed Proton-GE package, and (3) reverting to the Manjaro Mesa package the framerate got bumped from lower 20-s to mid-40s. CPU and GPU usage still hover around the 40%, so I feel there would be more improvement to be had perhaps?

I tested the game on my second PC, which is running ChimeraOS, has a 5800X3D chip, 32Gb RAM and a 7600 XT card, where it’s easily hitting these framerates and better (but with higher GPU usage, hardly any CPU usage, that 5800X3D is a beast). So I wonder if my 10700K might be a bit of a bottleneck? ChimeraOS’ version of Mesa is on 23.2 so maybe there are just some kinks to be worked out in the 24.1 branch?

Anyway… long story short: I’m happy with the overall performance at this point. Happy to dive into the Overlap and deal with Nightingale!

Hi, I’ve checked but the Manjaro nonfree branch is the main one, just more up to date with the Arch main branch. Or are you suggesting a particular version?

These all sounds like good ideas to play with, thanks! I’ll have a go later tonight and will update here. It would be bonkers if the mesh shaders were at fault, since I got my 7800XT specifically for that feature…

Hi, sorry, the non-free is a very Manjaro-specific thing.

TLDR: They removed a lot of proprietary video codecs from Mesa, which means that Manjaro’s Mesa tends to lag behind the Arch repo. By using nonfree, the Mesa installation is pulled and compiled straight from Arch.

So yes, I’m using RADV through Mesa 24.1.1 instead of version 23.x (which is where Manjaro is still at). I wanted to be on a newer version since 24.x packed in a lot of 7000XT improvements.

Out of curiosity, have you tried AW2 with your 7800XT? How does it run for you?

Thanks for posting this here, just purchased it. Keen to dive into the 2D course and the Shaders course!

Still making my way through Phantom Liberty in Cyberpunk 2077. It’s really good, but I had already completed the base game and I find it difficult to engage/care about it, since I already know it won’t impact the endgame. I think. Unless it does? But then, I was happy with the ending I got. So yeah, something set post-ending would’ve had me more excited, I think.

Apart from that, spending some time reacquainting myself with my zoo in Planet Zoo. It’s been two years, so that’s a fun game to return to.

As an open source alternative, I prefer a Jellyfin server and then using Feishin as a client. Nicer UI and options. Plex is a major no-no for me since they’ve started emailing people what they’ve been watching on their own servers. Privacy issues and required online login/plex-owned accounts for my own media? No thank you.

This is true! I’ve only dabbled with the tilemap features, but the changes made are impressive. And for more advanced users in 3D, it seems really quite phenomenal.

So much cool stuff to play with! Great summary by GDQuest. Integer scaling for pixel art - finally! Very chuffed with this.

That is weird! Once my project is in a shareable state, I’ll post the link here. Maybe it’s because (so far) it’s not awfully complex…

You may want to change the fact that web exports don’t work on macOS. MacBook Pro M1 user here. I’m happily running my Godot 4.1 as web exports on my server. Setting the headers is required for any browser / operating system, but things seem to work fine for me on Mac.

Oh, absolutely, and more power to them. Godot 4 has been an incredible piece of work and each update things are getting better and better. The thought of more developers using Godot is exciting, since it feels like we’re nearing the tipping point where it will really take off.

Managed to fix it by using await get_tree().process_frame instead. It seems that idle_frame appears to no longer exist in Godot 4.1?

So my full code for triggering the screenshot function is:

func _on_SaveReport_pressed():
	await get_tree().process_frame
	$"%SaveReport".visible = false
	$"%BackMainMenu".visible = false
	await get_tree().process_frame
	
	take_screenshot()

	$"%SaveReport".visible = true
	$"%BackMainMenu".visible = true

For some reason, I have to await before I turn the interface elements off, and after I’ve turned them off. It now works a treat for my app. Thank you for your assistance!

await get_tree().idle_frame

Thank you for this! I just tried it out but unfortunately Godot throws an error on await get_tree().idle_frame : Invalid get index 'idle_frame' (on base: 'SceneTree').

Could it be because I’m running in application mode, which only refreshes the screen if there’s an update?

As an alternative, I’ve put the code to turn things off into its own function:

func turn_off():
	$"%SaveReport".visible = false
	$"%BackMainMenu".visible = false

I’ve then tried an await turn_off()

The code runs, but doesn’t do anything and the screenshot still gets saved with the buttons visible.

I’m trying both await functions just before the take_screenshot() function like so:

	await turn_off()
	await get_tree().idle_frame
	
	take_screenshot()

Am I missing something very obvious here? Any help would be much appreciated!

I took away the 2 .visible = true commands at the end, just to see if they were the culprit. They are not. It appears that the get_viewport().get_texture().get_image() command gets called before the interface elements are turned off, even though the order of code would make me think otherwise.

Very excited about this update because it’ll finally fix Godot minimising at random (and getting stuck) on Linux Gnome when using certain extensions. It’s been a head scratcher for a long time!

Thank you! I had a look through the documentation and managed to fix the error.