Unity and Unreal both have this feature, but I found myself missing it in Godot. Also one or both of them allow you to see where the draw calls are coming from (even a basic Spatial/Particles3D split would do wonders, not the whole battery of details that RenderDoc can show)

It is possible to get a fps/vertices/polys/draw calls display done in GDScript, but I am not too sure about the other screenshot (OS/CPU/GPU/RAM). For actually shipping Godot games, the latter would be even more useful than the former (players just sending you a screenshot and/or writing it down instead of wondering 'which card does this game use' which can be common in multi-gpu machines).

Unity and Unreal both have this feature, but I found myself missing it in Godot. Also one or both of them allow you to see where the draw calls are coming from (even a basic Spatial/Particles3D split would do wonders, not the whole battery of details that RenderDoc can show)

It is possible to get a fps/vertices/polys/draw calls display done in GDScript, but I am not too sure about the other screenshot (OS/CPU/GPU/RAM). For actually shipping Godot games, the latter would be even more useful than the former (players just sending you a screenshot and/or writing it down instead of wondering 'which card does this game use' which can be common in multi-gpu machines).

My opinion is that more debug features => better for developers and players. I tried to follow guidelines for this proposal (even though the form is not 100% correct, apologies) and keep it as simple as possible for this time. However, I wouldn't be really scared to talk about even more advanced debug features/options but maybe it's too early for that. I have huge hopes in Vulkan implementation which can open for us large palette of new possibilities.

Even though you can maybe display some information on screen via GDScript, I think it would be safer to have it as essential part of engine itself, especially if we talk about hardware detection/resources management. I find it to be "safer" solution as well, compared to only allowing users to make their own GDScripts. + I think fps/polys/draw calls/etc. type of info is very important and maybe there is certain benefit in case where engine handles this directly compared to situation when script is asking engine for the information and then drawing it on screen.

I remember hearing about plans to add a more precise profiler in Godot 4.0, but I'm not sure.

As for exposing graphics card and API information to GDScript, this could likely be implemented with relative ease. See godotengine/godot#28404.

Please update your proposal using the template provided or else it will be closed in accordance with the first rule of godot-proposals (see rules here).

This seems like a useful idea so it would be a shame to close :)

Please update your proposal using the template provided or else it will be closed in accordance with the first rule of godot-proposals (see rules here).

This seems like a useful idea so it would be a shame to close :)

Updated. If there is something I forgot, please let me know. And thank you.

Related issue: godotengine/godot#21486

@Zireael07 That proposal isn't related to this one. That issue is about retrieving the display refresh rate, so you can do things like limiting FPS to the display refresh rate or setting the physics FPS to match the display refresh rate. This is probably not too difficult to add; it mostly involves digging into SDL's source code and picking up the relevant parts 🙂

Ah, I misread, I thought they wanted the refresh rate for debugging purposes :)

Ah, I misread, I thought they wanted the refresh rate for debugging purposes :)

Afaik Vulkan API provides insane amount of ways how to log and/or display all kinds of information, not only refresh rate (I made basic 3D engine using Vulkan long time ago and I was surprised how much information I could get just after initialization process in core of engine, much easier process than D3D12). As game developer seeking optimization, you probably care about everything related to hardware and usage of hardware resources, not just refresh rate. Refresh rate is more of a result but other information can help you understand why your refresh rate went down. This is one of the reasons why I am looking forward for Vulkan implementation in Godot because even in case this will not be default part of Godot, if I'm very lucky I might be able to implement it myself.

I'm pretty sure you are aware of it, I just wanted to clarify more while I'm here. Anyway, I would like to thank to everyone who participates in process of implementation of Vulkan in Godot, that's massive work.

I've been learning Godot recently, and I found this will be helpful. There are data in editor's Monitors sections, which works good. But sometime people want to see it on screen with game play together. I found this Monitor Overlay plugin is doing exactly this. Probably can have a offical MonitorNode?

I've published a Godot 4.x add-on (and an associated demo project) that features a debug menu similar to the one proposed here.

• Add-on: https://github.com/godot-extended-libraries/godot-debug-menu
• Demo project: https://github.com/godot-extended-libraries/godot-debug-menu-demo

Edit: I also have a WIP C++ port of the above add-on (functional, but it's missing the graphs): https://github.com/Calinou/godot/tree/add-debug-menu

@Calinou This is absolutely huge, thank you, I can not wait to try it out. At the end, I'm glad it works as add-on.

Perhaps it makes sense to bring the debug menu into Godot and let extensions add to it?

I've opened a PR for the C++ port of the add-on: godotengine/godot#100829