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

Godot 4.0 development enters feature freeze ahead of the first beta

godotengine.org

Post reply on HN
Print view View original

111–120 of 122 posts

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#111

Post by Mikeb85 »

pjmlp wrote: post #109
Mikeb85 wrote: post #84

Earlier quoted context omitted.

> gimped, less expressive That's the point. Lots of what Python does isn't required in a game engine and is slow. It's basically visual scripting but quicker to produce, the whole thing is C++ underneath.

So basically instead of number_list = [ x for x in range(20) if x % 2 == 0] print(number_list) one gets to write something like this, auto number_list = std::views::iota(0, 20) | std::views::filter([](const int n) {return n % 2 == 0; }); for(int num: number_list) std::cout

Maybe look at the code of real games out there to find out why list comprehensions aren't needed in a game engine specific language and what typical code looks like...

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#112

Post by pjmlp »

Mikeb85 wrote: post #111
pjmlp wrote: post #109

Earlier quoted context omitted.

So basically instead of number_list = [ x for x in range(20) if x % 2 == 0] print(number_list) one gets to write something like this, auto number_list = std::views::iota(0, 20) | std::views::filter([](const int n) {return n % 2 == 0; }); for(int num: number_list) std::cout

Maybe look at the code of real games out there to find out why list comprehensions aren't needed in a game engine specific language and what typical code looks like...

Once upon a time I was on SCEE offices in SOHO, was IGDA member for almost a decade, attended a couple of GDCE back in the day, regular visitor of Flipcode and GameDev.net back when they actually mattered.

Maybe don't try to guess the possible lack of knowledge of random people on the Internet.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#113

Post by Mikeb85 »

pjmlp wrote: post #112
Mikeb85 wrote: post #111

Earlier quoted context omitted.

Maybe look at the code of real games out there to find out why list comprehensions aren't needed in a game engine specific language and what typical code looks like...

Once upon a time I was on SCEE offices in SOHO, was IGDA member for almost a decade, attended a couple of GDCE back in the day, regular visitor of Flipcode and GameDev.net back when they actually mattered. Maybe don't try to guess the possible lack of knowledge of random people on the Internet.

Fair enough but while I've used list comprehensions or similar constructs while doing stats, never seen it in game code.

Usually it's just incrementing things in a loop, rather than creating lists...

Like why wouldn't you just do:

for x in range(20):

  if x % 2 == 0

    print(x)
Or push it to a list or something. The specific type of list transformation that comprehensions make slightly easier isn't common in game code and doesn't make things more readable versus for loops.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#114

Post by pjmlp »

Mikeb85 wrote: post #113
pjmlp wrote: post #112

Earlier quoted context omitted.

Once upon a time I was on SCEE offices in SOHO, was IGDA member for almost a decade, attended a couple of GDCE back in the day, regular visitor of Flipcode and GameDev.net back when they actually mattered. Maybe don't try to guess the possible lack of knowledge of random people on the Internet.

Fair enough but while I've used list comprehensions or similar constructs while doing stats, never seen it in game code. Usually it's just incrementing things in a loop, rather than creating lists... Like why wouldn't you just do: for x in range(20): if x % 2 == 0 print(x) Or push it to a list or something. The specific type of list transformation that comprehensions make slightly easier isn't common in game code and…

I was pointing out how much Python like code it is possible to write in modern C++, everything else is irrelevant.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#115

Post by jbluepolarbear »

unsafecast wrote: post #95
jbluepolarbear wrote: post #91

Earlier quoted context omitted.

Boxing is taking a Value Type (struct, int, enum, etc) and converting it to an Object. So Objects aren’t boxed.

Apparently we have different definitions of boxing. To me, and I've always used it (and seen it used) like this, a boxed value is a value that's stored on the heap and passed as a pointer. Maybe C# has a different definition?

That’s correct, but not what you said. You said objects are boxed. Values are boxed to create a reference by wrapping it in an object, objects are already reference types so there’s no boxing.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#116

Post by jayd16 »

stu2b50 wrote: post #31
Waterluvian wrote: post #6

Earlier quoted context omitted.

I won’t use the word “serious” but my limited personal experience is that C# feels like the right balance between flexibility and performance. Rust is a joy to write in but I personally find that it asks a lot from you when you just want to ship a game that doesn’t need to be safety rated. C++ is a great choice but it’s C++ and I’m just not good enough to enjoy a language with fewer guardrails. It also has similar ve…

I find it hard to imagine whatever glue language you choose for an engine like Godot would really matter that much. All you’re implementing is the business logic. Even the slowest language can run through basic business logic in the blink of an eye relative to the heavy duty that the Godot systems are doing. Eve Online runs on *python*, for instance. So does Blender. For a glue language, I am highly doubtful that the…

So you think all the talk about performance tuning in games is just made up, or what?

What ends up happening is you write scripts for lower compile times and ease of use. Then if something is too slow you rewrite it in native. The speed of the scripting tier lets you write less in native. Its not irrelevant at all.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#117

Post by krapp »

jayd16 wrote: post #116
stu2b50 wrote: post #31

Earlier quoted context omitted.

I find it hard to imagine whatever glue language you choose for an engine like Godot would really matter that much. All you’re implementing is the business logic. Even the slowest language can run through basic business logic in the blink of an eye relative to the heavy duty that the Godot systems are doing. Eve Online runs on *python*, for instance. So does Blender. For a glue language, I am highly doubtful that the…

So you think all the talk about performance tuning in games is just made up, or what? What ends up happening is you write scripts for lower compile times and ease of use. Then if something is too slow you rewrite it in native. The speed of the scripting tier lets you write less in native. Its not irrelevant at all.

Most of it is, because most of it is cargo-culting by amateurs who just believe what they read on SO and forums and who have never actually written anything non-trivial, much less shipped a game.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#118

Post by jayd16 »

krapp wrote: post #117
jayd16 wrote: post #116

Earlier quoted context omitted.

So you think all the talk about performance tuning in games is just made up, or what? What ends up happening is you write scripts for lower compile times and ease of use. Then if something is too slow you rewrite it in native. The speed of the scripting tier lets you write less in native. Its not irrelevant at all.

Most of it is, because most of it is cargo-culting by amateurs who just believe what they read on SO and forums and who have never actually written anything non-trivial, much less shipped a game.

Are you saying they misunderstand what they're cargo-culting or are you saying amateur game scripts run fast enough? To cargo-cult it needs to be relevant somewhere, so either way it shows the blanket statement is false, no?

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#119

Post by krapp »

jayd16 wrote: post #118
krapp wrote: post #117

Earlier quoted context omitted.

Most of it is, because most of it is cargo-culting by amateurs who just believe what they read on SO and forums and who have never actually written anything non-trivial, much less shipped a game.

Are you saying they misunderstand what they're cargo-culting or are you saying amateur game scripts run fast enough? To cargo-cult it needs to be relevant somewhere, so either way it shows the blanket statement is false, no?

I'm saying most amateur games do run fast enough, and that for those which don't, the bottleneck is more likely to be related to poor caching, unnecessary allocations or unoptimized assets, etc, rather than just the language used. You really have to go out of your way nowadays to actually slow a game down with just bad code.

And many of the idioms people abide by may no longer be relevant, or may only be relevant in niche but not general cases.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#120

Post by unsafecast »

jbluepolarbear wrote: post #115
unsafecast wrote: post #95

Earlier quoted context omitted.

Apparently we have different definitions of boxing. To me, and I've always used it (and seen it used) like this, a boxed value is a value that's stored on the heap and passed as a pointer. Maybe C# has a different definition?

That’s correct, but not what you said. You said objects are boxed. Values are boxed to create a reference by wrapping it in an object, objects are already reference types so there’s no boxing.

I'm not extremely familiar with C# objects, but I think I get the confusion now. My point was that objects are boxed values, and that most things in C# are (to my knowledge) objects. I guess I used slightly the wrong words.
Post reply on HN