131–140 of 259 posts
Earlier quoted context omitted.
As mentioned in the article Godot has a low processor usage mode: > If true, the engine optimizes for low processor usage by only refreshing the screen if needed https://docs.godotengine.org/en/stable/classes/class_os.html...
I'd love to see a comparison of a simple application, e.g. a media player in Qt vs Godot using this mode, and see which one drains a laptop battery quicker.
I did an Ask HN [1] about this topic a little while ago. Most relevant comment [2], from gunibert is here: The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using somethi…
At first we were worried about the screen always updating and consuming so much energy, but reading the code it became obvious that it was extremely simple to fork the imgui with a very small update screen change, so it only updates when we do something.
Imguis and game engines are much simpler to code than conventional GUI because you don't need to handle so much state.
Earlier quoted context omitted.
Assuming that is true, it is an oversight. There is no actual technical limitation. I am confident if Godot sees usage as a GUI/app framework, they will take care of that.
Surprisingly, they won't. Text input and manipulation is so incredibly ugly and hard, that basically nobody cares it enough to to it really well. Unicode to start is complicated. Then you have things like bidirectional text. Line breaking is complicated. There are no accepted practices for a lot of use cases. Hyperlinks. Embedded content like images. Copying/inserting html and other formats. Styling content. Renderin…
> Why would you want to render text in a gaming engine in the first place ...
Just about every game needs text, including Unicode text. Every proper engine handles it.
Earlier quoted context omitted.
I'd love to see a comparison of a simple application, e.g. a media player in Qt vs Godot using this mode, and see which one drains a laptop battery quicker.
A media player is a bad choice since it usually requires a very specialized library.
Have both use the same specialised libraries.
If anyone wants inspiration, Winamp is the gold standard for media players with excellent GUI bling and skinning.
I did an Ask HN [1] about this topic a little while ago. Most relevant comment [2], from gunibert is here: The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using somethi…
It's perfectly reasonable to build a game engine that's possible to build these GUI-specific systems on top of (if you want lazy UI rendering simply don't call the update. For godot I believe the biggest block is the editor cuz it's geared towards game creation (haven't used godot for a while don't know anything about its usage without editor)
An underlying tone of this article which most people in this thread have missed, was the impact of hitting the ground running. Godot quickly gets something on the screen for someone to build on. Qt is difficult to get something running. The impact of this makes technical benefits one way or the other moot. After all, if it works, who cares what technology is better? I found the hassle of setting up Qt painful, but it…
Curious what you mean by that? What did you need Qt Creator for that you couldn't do otherwise?
I did a lot of tutorials on my YouTube channel on how to start making GUI applications with Godot. The visual scripting is really bad for now, so I would stick with GDScript (a Python like language) or C#. It is really a great piece of software to make something quick for non-technical people. I really recommend anyone to explore and play with it a bit and I'm sure you'll find a use for this amazing engine.
> visual scripting is really bad for now Are there any visual scripting languages that aren't terrible? The system in unreal works but every time I use it I find myself wanting a text editor (I have spent years learning to program well, be that C++ or shaders, just let me do that!).
There is so much bullshit and lies about Qt5, I won't bother finishing that piece of crap: Erik Engheim: Qt5 is 5GB Actual fact (on arch linux): qt5-base = 64.07 MiB, qt5-declarative = 24.72 MiB, qt5-quickcontrols2 = 8.56 MiB > Try having somebody look at a Qt design you made. “Oops sorry you need a 5 GB download to do that. Oh and btw you need to register an account on a website, login and search really hard to find…
There might be some confusion about Qt the runtime (ie: compiled binaries) and the Qt SDK for development. Last I remember (admitedly, >8 years ago) the Qt SDK certainly was a multigigabyte download. In this case, you need the SDK to develop a UI with Qt, so I think the author's comparison is fair. > Consider Qt Creator IDE which is quite minimalist, without Qt which it requires to run, requires over 200 MB Actual fa…
Earlier quoted context omitted.
Assuming that is true, it is an oversight. There is no actual technical limitation. I am confident if Godot sees usage as a GUI/app framework, they will take care of that.
it's too late for the engine to "take care of it" when the problem presents itself - because there are existing tooling and frameworks that already fixes this problem (such as native widgets, or electron). so godot will only see usage as a GUI framework for the use cases that won't see emoji or non-english IME.
Mentioning Electron to solve Unicode is like thinking about a bulldozer when you need to unclog your toilet.
Earlier quoted context omitted.
Why would any engine re-render if it's not needed? It will still have benefits even on desktops.
I think mostly because having scads of clever conditionals all over the place greatly increases the risk of subtle and hard-to-reproduce bugs. From a 2007 Carmack email [1] : > The way we have traditionally measured performance and optimized our games encouraged a lot of conditional operations -- recognizing that a particular operation doesn't need to be done in some subset of the operating states, and skipping it. T…