Live data from Hacker News

Godot 4 Beta 1

godotengine.org

111–119 of 119 posts

Re: Godot 4 Beta 1

#111
post #34

Earlier quoted context omitted.

> Fortnite, Risk of Rain 2, Valheim, and Deep Rock Galactic Those games are low poly but NOT visually simplistic. Memory tends to play tricks and we remember older games looking better than they actually did, so we imagine lower polygons = 2005 tech game. Those games you've mention run on advanced and heavyweight fragment and vertex shaders to create a specific look (cartoony graphics in Fortnite, there's a million e…

This logic doesn't hold up. > Memory tends to play tricks and we remember older games looking better than they actually did We compared what League of Legends, Valorant, and Inscryption look like now with what those other games look like now . There's no rose-tinted glasses involved - this is an apples-to-apples comparison. > Those games you've mention run on advanced and heavyweight fragment and vertex shaders to cr…

>If that same look is being created in a far more performant manner by other games, then that means that the game is poorly optimized.

LMFAO. Games are just visual looks now. Good to know. Would you like a spot on r/gaming ? You sound like you'd fit right in there. Let's start with the obvious:

League of Legends, Valorant: 2500 employees at Riot Games

Inscryption: A single developer

Risk of Rain 2: 5 employees

Games don't run well or badly just for the lulz. Focusing on running on your shitty ass laptop is about the last thing on a developer's mind when trying to both ship, and make enough money for the other game. Riot can afford doing everything for it to run better on crap PCs because they have so many players that tapping onto the low, low end is worth money for them.

Additionally, there is infinitely more to a game than just "haha cartoon graphics go boom". LoL is extremely simple in terms of mechanics, and so is DotA. Camera pointed down at a very simple map that never changes. Trees that can fall is about the most complex interaction that happens on the map. Compare that with RoR, Valheim and DRG that procedurally generate complex environments, in full 3D with a large view distance. Add to this various features (destructibility, which brings its own set of view culling issues as well as more complex algorithms and data structures), and yes, your shitbox cannot run them well. Fortnite is so simple that it only has 100 animated pawns at the beginning at the same time, a gigantic map with also large view distances, structure building, thousands of assets, and a much more complex rendering pipeline (that, no, does not look like league of legends, despite all you'd like to pretend)

> My lived experience, my understanding of computer graphics, and knowledge of things like the GTA Online incident[2] strongly indicates that this line of reasoning is incorrect.

With none of the due respect, your lived experience takes about a single, barely valid factor into account, your understanding of computer graphics seems to be just about the one of a college student that got in his first year, and your knowledge of things like the GTA Online incident is a single event. "Looking better" means absolutely shit. You may prefer the visual result, but no matter your metric, I can make you a game that will look better _and_ run like absolute crap. Is it polycount ? Sure, I'll make a 50 million poly character model. Textures ? Here comes the 16K textures baby. Lighting ? Have I told you about our lord and savior CPU-ran-ray-tracing ?

Re: Godot 4 Beta 1

#112

Earlier quoted context omitted.

And, as I explained, this line of reasoning is both fallacious and completely irrelevant[1]. [1] https://news.ycombinator.com/item?id=32859519

It's highly relevant. Devs aren't obligated to optimize for your friend's extremely weak computer. They may well be optimizing for a median gaming PC instead.

> They may well be optimizing for a median gaming PC instead.

This is how you get games that could run good if the user got more control over the model LODs, post processing effects and even render scale, but the developers/project management didn't care.

What's worse, a lot of modern games have great ability to scale back and run on lower end hardware when necessary, but the companies behind them only care about that ability when it comes to getting them running on Switch or a similar constrained hardware environment, that would still let them rake in more cash.

And outside of particular hacks (messing with config files, or using untrusted utilities), the users are often left powerless because a few configuration variables weren't exposed to them for whatever reason.

That's actually worse than Electron apps that are typically badly optimized by default (platform overhead): it's very much like a developer in an enterprise setting choosing to go for the N+1 by looping over data in the app and doing DB calls for each iteration, yet everyone actually is okay with it.

Except for the people who actually don't want their software/game to run slow, just because they cannot afford to throw unreasonable amounts of hardware resources at the problem the devs (and whoever is telling them what to do) inflicted upon them.

Essentially, it's Wirth's law: https://en.wikipedia.org/wiki/Wirth%27s_law

Best counterexample to this is probably e-sports titles that are optimized for stable frame times because it actually matters to the developers, or games like Skyrim that expose some of the engine internals to the users, so modders can choose what matters to them.

That said, many developers don't really consider it worth the effort to put lots of thought into options menu and sometimes don't even gate performance intensive post processing like SSAO behind options that can be toggled on/off.

In other cases, they might not have the necessary skillset to use a profiler properly and recognize what is particularly badly optimized, especially for smaller indie projects.

Other times, even large studios don't seem to care, or the actual reasons are convoluted and digging into things just isn't in the backlog: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

Re: Godot 4 Beta 1

#113
post #77
post #45

Earlier quoted context omitted.

Whoa, that's interesting -- does ENet have a good integration with Erlang, or something like that? I'm interested in both Elixir/Erlang and Godot, but haven't seen an opportunity to use them together previously. I'd love to hear more details about this project of yours, and how the Godot 4.0 release impacts it.

Someone made an effort to do a full protocol port to Erlang and I have a friendly fork I’m maintaining that makes it work better with the C version as used by Godot. Seems to work with unreliable/reliable/unsequenced packets but never tested in anger, much less production! I don’t want to derail the thread but I have a link to my GitHub in my profile - I’m working on a few things: 1. the aforementioned Erlang ENet fo…

We're toying around with elixir. We should share notes!

I also have a copy of libgodot written for elixir.

https://github.com/godotengine/godot/compare/master...V-Seka...

https://github.com/V-Sekai/godot/tree/elixir

Join our discord!

Re: Godot 4 Beta 1

#114

It would be nice if we brought the rule back where it's against HN guidelines to post submissions for every new version of some software. Every Godot thread ends up with the same comments posted, none of them particularly interesting or insightful. And in this particular case, it's not even an official release; it's just a beta!

I disagree. I want to see more actual software on Hacker News. This is a space for "hackers," is it not? While Godot fairly established, there are up-and-comers in software development, and one of the few ways I will ever know about these people and their projects are by Show HNs and product update submissions. It may be dozens of releases or years before I even hear about a project, and this type of comment clearly…

We're working on those, but at some point Godot Engine 4.0 needs to ship..

* https://github.com/godotengine/godot-proposals/issues/4435 (spatial audio)

* https://github.com/godotengine/godot-proposals/issues/3904 (network interest management)

* I can't find the proposal, but we, V-Sekai, call those physical materials or sound materials. Like a piece of concrete has different friction and a different sound. The worst part is it requires the Godot Engine 4 artists to conform to like 300 materials.

Re: Godot 4 Beta 1

#115

It would be nice if we brought the rule back where it's against HN guidelines to post submissions for every new version of some software. Every Godot thread ends up with the same comments posted, none of them particularly interesting or insightful. And in this particular case, it's not even an official release; it's just a beta!

I disagree. I want to see more actual software on Hacker News. This is a space for "hackers," is it not? While Godot fairly established, there are up-and-comers in software development, and one of the few ways I will ever know about these people and their projects are by Show HNs and product update submissions. It may be dozens of releases or years before I even hear about a project, and this type of comment clearly…

There's a form response for why choose gdscript here. https://docs.godotengine.org/en/stable/about/faq.html

Re: Godot 4 Beta 1

#116

Earlier quoted context omitted.

Yeah, everything about early id Tech is just, without exaggeration, decades ahead of Unreal. Of course, sex sells, so since Unreal renders fairly well, for this reason alone I think it attracts amateurs. I think Godot wants to do the same thing, and I'm sure it'll work, but the authors are just like the rest of the open source community in that they don't actually work on features meaningful to most games. Back to Un…

Interesting. I know that Frost Giant (heir apparent to the Starcraft/Warcraft part of Blizzard) has said that they're building their own gameplay logic engine and networking stack on top on UE5 for their RTS, I wonder if what you're saying is part of why.

UE is the last engine I'd use for RTS, though people have done wonders in spite of it -- check out the tech behind HŌRU game for some impressive examples.

Re: Godot 4 Beta 1

#117
post #56

It would be nice if we brought the rule back where it's against HN guidelines to post submissions for every new version of some software. Every Godot thread ends up with the same comments posted, none of them particularly interesting or insightful. And in this particular case, it's not even an official release; it's just a beta!

I actually agree with the idea of restraint, but this is a colossal release with literally dozens of major highly anticipated features and a huge load of bug fixes and performance optimizations. Given the development time frame and resources this is a spectacular delivery. Also highly recommend checking out the code base directly as the team have done a great job of keeping the sources well organized and clear.

> this is a colossal release

It isn't. It's (yet another) pre-release. There's a story about an upcoming Godot release posted every 1, 2, 3 weeks or so.

Re: Godot 4 Beta 1

#118

It would be nice if we brought the rule back where it's against HN guidelines to post submissions for every new version of some software. Every Godot thread ends up with the same comments posted, none of them particularly interesting or insightful. And in this particular case, it's not even an official release; it's just a beta!

This comment makes no sense. If it was some random alpha release of Godot (there have been more than a dozen) then sure, but this is the first beta release, which means it's now somewhat stable. That's a big deal, considering how much rewriting as been going on.

It makes a lot of sense. We have Godot submissions all the time.

Someone submitted one for a v4 alpha. (That it didn't get traction is irrelevant.)

Here's one for the beta.

When v4 is released, it'll inevitably be posted here, too.

Re: Godot 4 Beta 1

#119

Earlier quoted context omitted.

This comment makes no sense. If it was some random alpha release of Godot (there have been more than a dozen) then sure, but this is the first beta release, which means it's now somewhat stable. That's a big deal, considering how much rewriting as been going on.

It makes a lot of sense. We have Godot submissions all the time. Someone submitted one for a v4 alpha. (That it didn't get traction is irrelevant.) Here's one for the beta. When v4 is released, it'll inevitably be posted here, too.

> Someone submitted one for a v4 alpha. (That it didn't get traction is irrelevant.)

That's actually highly relevant, and no the comment made no sense.

Hitting the first beta version is a big deal. The next one won't be, but the 4.0 release certainly will.

Post reply on HN