this post was submitted on 18 Sep 2023
76 points (97.5% liked)
Godot
5918 readers
58 users here now
Welcome to the programming.dev Godot community!
This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.
Make sure to follow the Godot CoC while chatting
We have a matrix room that can be used for chatting with other members of the community here
Links
Other Communities
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Rules
- Posts need to be in english
- Posts with explicit content must be tagged with nsfw
- We do not condone harassment inside the community as well as trolling or equivalent behaviour
- Do not post illegal materials or post things encouraging actions such as pirating games
We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent
Wormhole
Credits
- The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
- The banner is from Godot Design
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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?
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.