With the Godot Tomorrow #20 vod from yesterday freshly in mind I wanted to add my two cents about one of the talking points.
It was mentioned in passing that the one thing that might be subjected to change in Godot’s mission statement is the “not just for games” part.
Since that directly impacts me, I thought I’d explain why I am using godot for application development. I would love to hear from others about this.
I think, godot has, intentionally or by chance, created one of the most approachable application development platforms currently available.
In no particular order:
Porting between platforms is almost effortless. I previously had many issues porting software between Linux and Windows. It’s one of the reasons I started to use Godot in the first place.
The UI framework is one the best around. Seriously. Others may have more features and offer better integration with things like OS styling, but they are a pain to use.
UI frameworks are a big pain point for me (especially when developing for more than one platform) and the Godot UI control system is possibly the most convenient one I have used since WinForms.
A good WYSIWYG editor! This is such a huge feature that so many UI frameworks and development platforms just don’t offer.
The forgiving nature and ease of use of GDScript are huge boons for quick development. It’s so easy to get things done quickly in Godot. It feels a lot like writing python, but in a vastly more useful environment.
The ease of performance optimization. GDScript performs very well as is and with the integrated profiling tools, I have been able to solve any performance issues I have run into.
Of course, being a game engine, Godot has some shortcomings as a platform for general GUI applications, but so far I have been able to compensate for all of them with extensions. (love the rust bindings )
All of this ends up creating a platform that is so approachable that even some of my non-programmer friends have written software in Godot. It’s great. I hope we can keep it going.
One of my personal side projects is a GUI app. I’m not sure what I have to setup for it in the engine. I have read about “Low Processor Usage Mode” with low_processor_usage_mode_sleep_usec to define the time between frames to update the GUI. And to use only compatibility renderer for GUI apps. And in other frameworks than game engines, the rendering is handled a little bit different, with updating only the changed parts of the window.
What do I need to keep in mind building a GUI app in Godot?
Is there something to not use _process or _physics_process in GUI apps?
Low processor mode is really the only important setting you need. You can ignore the sleep time setting, the default is fine.
The main feature of low processor mode is that you don’t redraw the UI on every frame. Normally games redraw the entire screen with every frame, but for a GUI tool that would be a waste of resources. Only drawing when something changes is the right way to go here.
How UIs are drawn indeed depends entirely on the framework. Godot is rather unique in its ability to support both immediate mode (draw on every frame, other example: IMGUI) or on-demand (example: QT).
I do not use the compatibility renderer, though I am only building software for desktop PCs, not mobile or web.
Is there something to not use _process or _physics_process in GUI apps?
This will depend heavily on what your software actually does. For most UI software, running code on every frame is an indication of a design flaw. You want to avoid that as much as possible to conserve performance.
However if your software does something like real time analysis of incoming data, or has a live rendering component, that consideration would not apply. (Or apply less.)
For me the rule of thumb is: Cache everything, recalculate as little as possible.
I think my entire project only has one single occurrence of _process, which is used for dragging a graphic.
If you want to see a somewhat bigger godot UI project you can look at my code over here: link
Not sure if it’s an example of good code, but it’ll give you some insight^^
I might have not make myself clear with that one in particular, what I wanted to say is that in the past, this wasn’t something that we had in our vision of the project but with time it got there, which also means that any of the points there could potentially change in the future, but we are using this current version as a north star for the development of Godot.
So, there are no plans to remove that from the vision statement from now!
)
Yeah this, seriously. It’s surprisingly good.