Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Advanced GUI Applications with Godot

medium.com

Post reply on HN
Print view View original

101–110 of 259 posts

Re: Making Advanced GUI Applications with Godot

#101

Post by bscphil »

m3at wrote: post #40
Shared404 wrote: post #30

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…

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.

Re: Making Advanced GUI Applications with Godot

#102

Post by TheMagicHorsey »

I feel strongly that OP should check out Google's Flutter project. It has many of the benefits he sees in Godot, with a more general focus rather than the singular focus on games.

Flutter is very "game-like" in the way it does its UI. It does not use the native graphics elements. Everything is a component that is rendered by Flutter's own rendering engine ... AND even the inputs (like touch) are handled directly in Flutter.

Re: Making Advanced GUI Applications with Godot

#103

Post by tonyedgecombe »

jordwest wrote: post #94
privateSFacct wrote: post #86

My question - what happened to microsoft in this space? The get up and go speed of the super old windows forms approach was fantastic. Now I'm supposed to use - XAML? UWP? WPF? Do these have great windows form designer still? I'm talking speed between download and go with an GUI, a button, a text box (maybe data bound) etc. This will age me, but for all the decades of "improvements" this tooling has, every time I've…

I'm pretty excited to see where the new .NET MAUI [1] goes. It's still in development, but it seems like it could be a great contender for fully cross-platform native UIs. Paired with F# the proposed Elm-like model-view-update style would be the dream. [1] https://devblogs.microsoft.com/dotnet/introducing-net-multi-...

I was just thinking we are about due another UI framework from Micrsoft.

In addition, we are enabling developers to write fluent C# UI and implement the increasingly popular Model-View-Update (MVU) pattern.

Ah, some SwiftUI envy.

Re: Making Advanced GUI Applications with Godot

#104

Post by tonyedgecombe »

privateSFacct wrote: post #89
numlock86 wrote: post #87

Earlier quoted context omitted.

You can do the "WinForms approach" with WPF/XAML still, but once you got the ideas and concepts behind MVVN, observables, bindings, converters, collection controls and so on, there is absolutely no turning back and you start to miss that stuff on WinForms.

Is WPF/XAML the right way now to do quick get going windows app development?

It wasn't for me, it felt like wading through treacle.

However if you want to unit test your UI then it makes more sense.

Re: Making Advanced GUI Applications with Godot

#105

Post by ChicagoDave »

privateSFacct wrote: post #89
numlock86 wrote: post #87

Earlier quoted context omitted.

You can do the "WinForms approach" with WPF/XAML still, but once you got the ideas and concepts behind MVVN, observables, bindings, converters, collection controls and so on, there is absolutely no turning back and you start to miss that stuff on WinForms.

Is WPF/XAML the right way now to do quick get going windows app development?

Still think WPF/XAML was the best layout engine and I'd cry if it replaced CSS.

Re: Making Advanced GUI Applications with Godot

#106

Post by bscphil »

userbinator wrote: post #82
kodablah wrote: post #2

QtWidgets works really hard to try and remain native (both by reusing the platform window pointers, and mimicking style and functionality). That for me is worth it. While the article constantly complains about dev tooling size, a reasonable complaint, my DLLs I ship w/ my Qt program are just 20MB (so I'd suspect a similar size increase to a single binary were I to statically link). If I didn't care about native look…

It's odd to see the "just 20MB" phrasing. I guess even native applications have expanded to the point where 20MB seems small, but in absolute terms I still consider that quite large --- to put things into perspective, a full installation of Windows 3.11 , the OS with all of its included applications, is less than 20MB. I wonder if, in another 20 years, we may see people speaking of "just 20GB"...

> It's odd to see the "just 20MB" phrasing.

I agree with you, although one thing worth pointing out is that with Qt (or similar) application frameworks on any decent operating system, you only have to download those libraries once, which means the individual overhead of an application remains extremely low.

For example, the LXQT default terminal, qterminal, comes in a package that is only 200 KB on Arch Linux, for the entire thing. (To be fair it directly depends on a library that provides a terminal widget, which is another 200 KB.)

Re: Making Advanced GUI Applications with Godot

#107

Post by mrec »

ladberg wrote: post #58
m3at wrote: post #40

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...

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. This gives better demo timing numbers, but a huge amount of bugs are generated because skipping the expensive operation also usually skips some other state updating that turns out to be needed elsewhere.

> We definitely still have tasks that are performance intensive enough to need optimization, but the style gets applied as a matter of course in many cases where a performance benefit is negligible, but we still eat the bugs. Now that we are firmly decided on a 60hz game, worst case performance is more important than average case performance, so highly variable performance should be looked down on even more.

There was fascinating breakdown [2] of a single GTA V frame about five years back. It was a real eye-opener for me - whole full-screen rendering passes for things like water reflection and refraction when there isn't even any water visible in the scene.

[1] http://number-none.com/blow/john_carmack_on_inlined_code.htm...

[2] http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic...

Re: Making Advanced GUI Applications with Godot

#108

Post by Tossrock »

ngold wrote: post #68
coppolaemilio wrote: post #4

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.

Working with unity that also does not have a visual script feature, sorta, I like using c#. It's simple and straight forward.

Unity just bought Bolt, so Bolt visual scripting is included in all Unity licenses for free, now. There's also the vfx graph and the shader graph node editors.

Re: Making Advanced GUI Applications with Godot

#109

Post by pjmlp »

numlock86 wrote: post #87
privateSFacct wrote: post #86

My question - what happened to microsoft in this space? The get up and go speed of the super old windows forms approach was fantastic. Now I'm supposed to use - XAML? UWP? WPF? Do these have great windows form designer still? I'm talking speed between download and go with an GUI, a button, a text box (maybe data bound) etc. This will age me, but for all the decades of "improvements" this tooling has, every time I've…

You can do the "WinForms approach" with WPF/XAML still, but once you got the ideas and concepts behind MVVN, observables, bindings, converters, collection controls and so on, there is absolutely no turning back and you start to miss that stuff on WinForms.

You can partially use them on WinForms, I have done so in several projects.

https://docs.microsoft.com/en-us/dotnet/api/system.windows.f...

It isn't as powerful as WPF/UWP, and it has some caveats depending on the .NET Framework version, but it does the job.

Re: Making Advanced GUI Applications with Godot

#110

Post by pjmlp »

privateSFacct wrote: post #89
numlock86 wrote: post #87

Earlier quoted context omitted.

You can do the "WinForms approach" with WPF/XAML still, but once you got the ideas and concepts behind MVVN, observables, bindings, converters, collection controls and so on, there is absolutely no turning back and you start to miss that stuff on WinForms.

Is WPF/XAML the right way now to do quick get going windows app development?

Yes, although the future is WinUI.

https://microsoft.github.io/microsoft-ui-xaml/about.html

Post reply on HN