Create non-game apps with Godot Engine
Create non-game apps with Godot Engine
My personal experience on how I use Godot Engine to create non-game applications
The main target of the Godot Engine are game developers. But Godot's easy workflow and functional UI elements, makes it also a good fit for non-game applications. There are already some out there you may know, like Pixelorama, an Open Source 2D sprite editor.
You're viewing a single thread.
There's tends to be one major difference between games and non-game applications, so toolkits designed for one are often quite unsuitable for the other.
A game generally performs logic to paint the whole window, every frame, with at most some framerate-limiting in "paused" states. This burns power but is steady and often tries hard to reduce latency.
An application generally tries to paint as little of the window as possible, as rarely as possible. Reducing video bandwidth means using a lot less power, but can involve variable loads so sometimes latency gets pushed down to "it would be nice".
Notably, the implications of the 4-way choice between {tearing, vsync, double-buffer, triple-buffer} looks very different between those two - and so does the question of "how do we use the GPU"?
Does this mean you're against using Godot for apps?
Personally, I feel like the extra load to reduce latency is worth it, but I honestly don't know how different the load is or how much it could be optimized. But really snappy reactive software, even when long-running processes are going, feel much better to use. I'm getting tired of using web apps for everything.
As far as what does the GPU do, right now if we're talking like b2b stuff you could do a lot more local number crunching or do really rich graphs with compute shaders etc. In the future, maybe the CPU handles most of the app and the GPU handles an AI workload in the background?
I guess I forgot to mention the other implicit difference in concerns:
When you are a game, you can reasonably assume: I have the user's full focus and can take all the computing resources of their device, barring a few background apps.
When you are an application, the user will almost always have several other applications running to a meaningful degree, and those eat into available resources (often in a difficult-to-measure way). Unfortunately this rarely gets tested.
I'm not saying you can't write an app using a game toolkit or vice versa, but you have to be aware of the differences and figure out how to configure it correctly for your use case.
(though actually - some purely-turn-based games that do nothing until user enters input do just fine on app toolkits. But the existence of such games means that game toolkits almost always support some way of supporting the app paradigm. By contrast, app toolkits often lack ready support for continuous game paradigms ... unless you use APIs designed for video playback, often involving creating a separate child "window". Actual video playback is really hard; even the makers of dedicated video-playing programs mess it up.)
I know many Mac users who use Safari just because it’s doesn’t drain the battery as much as Chrome. That's a big difference for desktop applications, and constantly redrawing the window at 60fps definitely will kill your battery.
For sure! However Godot has low processor mode that lets you control the frequency of the update when no changes are being made. That update time can even be changed from code so you can adjust it situationally.
Most UI frameworks are already graphically accelerated. But as stated above do the absolute minimum when updating the screen.
You don't need to redraw a static label 60 times a second.
They have totally different use cases and are written very differently.
Games use as many resources as they can to get maximum performance for rendering. This is not desirable in an application.
I mentioned above but Godot has a low processor mode that gives you some control over the refresh cycle when nothing is happening. I doubt this completely alleviates the problem but I think it's worth profiling it for individual use cases.
It's still the same essential issue. You only want to draw what has changed and only when it has changed.
Lowering the rate could make things look worse when they actually do update and cause unneeded redraws when they don't.
I get not wanting to learn something else. But it's a case of using the right tool for the job imo.