Godot 4.0 uses borderless fullscreen by default, but exclusive fullscreen can also be chosen.
Godot 3.x automatically uses exclusive fullscreen if the window size matches the screen size. You can work this around by making the window size one pixel smaller on either axis (or both).
Note that this only affects Windows, as macOS/Linux don't have a concept of exclusive fullscreen.
@Calinou said: Godot 3.x automatically uses exclusive fullscreen if the window size matches the screen size.
Why is that though, for performance reasons?
I do believe there used to be performance benefits from exclusive fullscreen but, AFAIK, this is far in the past. There is little, if any, difference now. And exclusive just makes it more difficult, black screens, slow alt + tab, worse support for odd resolutions, etc. It's just not worth it, even if there was some small 5 fps gain.
@cybereality said: I do believe there used to be performance benefits from exclusive fullscreen but, AFAIK, this is far in the past. There is little, if any, difference now. And exclusive just makes it more difficult, black screens, slow alt + tab, worse support for odd resolutions, etc. It's just not worth it, even if there was some small 5 fps gain.
Exclusive fullscreen performs a bit better, but most importantly, it has much lower input lag since it can bypass compositing. Unlike some Linux window managers, Windows no longer allows disabling compositing, so exclusive fullscreen is now the only way to attain this.
Note that on Windows 11, you can enable windowed gaming optimizations which do the same thing. However, this is disabled by default and only works on DirectX 10, 11 and 12 games, not OpenGL, Vulkan or DirectX <= 9 games.
Ah, I see. Yeah, I read an article on the Microsoft docs page, but I guess that was for DX12.
@Calinou said: Godot 3.x automatically uses exclusive fullscreen if the window size matches the screen size. You can work this around by making the window size one pixel smaller on either axis (or both).
I actually tried that option. but that makes it somewhat difficult cos of taskbar. Some users(including me) prefer it hiding in pc mode but others leave default non hiding bar. That leaves me only option of making window being "always on top" and then it leads it into problems related to those. Well I guess Ill ditch idea of custom title bar in favour of ease of use :/
Godot 3.x supports borderless in the window options. However, custom title bars are difficult. Drawing them is easy, but dragging the window can be choppy, since it doesn't go through the OS (unless I missed something).
@cybereality said: Godot 3.x supports borderless in the window options. However, custom title bars are difficult. Drawing them is easy, but dragging the window can be choppy, since it doesn't go through the OS (unless I missed something).
Oh that actually is very easy and it runs smooth starting even on low end PCs. Optimization wise Im building an app for creating json files and it will not drop frames as much if any.
code is just this:
extends Control
var fixed = bool(false)
var dragging = bool(false)
var mouse_pos = Vector2()
func _process(_delta):
if !fixed and dragging:
OS.window_position = OS.window_position + get_global_mouse_position() - mouse_pos
func mouse_input(event) -> void:
if event is InputEventMouseButton:
if event.get_button_index() == 1 and event.is_pressed():
fixed = get_tree().get_current_scene().fixed
mouse_pos = get_local_mouse_position()
dragging = true
elif event.get_button_index() == 1 and !event.is_pressed():
dragging = falseIt works fine for me and has no "jitter" to it! showcase
Also on the side note I failed miserably trying to understand how new window system works in godot 4. I get that it is really cool when you have multi window application. And i think it is future of games to utilize 2 screens. Especially cus steam's research showed that most gamers use 2 1920x1080 screens. :D
GibberishDev In my case, with this code don't work well. When I slide the screen, this is moved with jitter. How can I solve this?
