Has Godot Reached The Event Horizon?

MagickPanda

For cellphone games, unity is a better. And cocos or laya is probably more proficient at making web games.
Godot's pitfall is trying to reinvent alot of wheels, and the new wheel became borked due to frequent changing of contributors and maintainers.
I myself found it's hard to understand my own code I wrote like a few months ago, even with comments. For modules in project like godot, without a consistent coding style and stable contributors, I guess it will be more chaotic than a single-person project.
Godot's built-in physics is a prime example of such pitfall, sux at both stability and performance, compare to bullet or jolt or box2d, or any other relatively mature libs.

duane

MagickPanda For cellphone games, unity is a better. And cocos or laya is probably more proficient at making web games.

How so? One of the things I haven't had any problems with in 4.1 was exporting. If I can get it to work, it works on android and web.

fire7side

duane Well, that's good to know.

MagickPanda

duane
I tried exporting one of my demo to android apk with 4.1, it just crashed with blank screen in simulator in android studio on friend's PC(he doesn't have a physical android device), it turned out to be simulator device does not support vulkan render, and the apk got exported with vulkan renderer, even I exported with mobile or compatible settings.(Force all renderer to opengl seemed fixed the problem)
4.1 vulkan also has problem on certain non-mainstream linx distro, like freeezing OS or virtual box if you export with vulkan render.

Megalomaniak

synthnostate One time I suggested C to Juan and he made a dismissive reply like "C++ ain't pretty but it's designed to solve problems". It's a sunk cost.

I see no lie there. Of course features of C++ were added for a reason. But just because a feature is there doesn't mean it's right for your project. This is why collaborative projects need style guides and enforcement of them. Plenty of patches/pull requests that won't get accepted because the code is a mess to maintain(even if on it's own it's well written, internally consistent and fine) because in the context of the wider code-base it just doesn't adhere to style guide and would be alien to anybody but the author. So ultimately unmaintainable technical debt.

Blender - coded in C, fast and relatively reliable.

Blenders codebase is a mix of languages(including the rather esoteric D IIRC) and C++ portion is increasing/trending upwards.

synthnostate Third mistake: not using a third-party physics library.

As with anything there's pros and cons to this. Positive: Don't have to maintain your own code for this(i.e. don't need to reinvent the wheel) Cons: Should the upstream stop maintaining it you are screwed. Plus unless you wrote the engine from scratch around the physics engine you've picked you'll probably have lots of odd bugs(see godox 3.x and bullet) or just straight up some of your engines features might not be able to integrate with or benefit from physics.

synthnostate

Kojack Blender must have a lot of small C++ files because Github says it's 70% C and 21% C++.

Might be a good strategy though, primarily using C and only C++ where necessary, for example to interface with really useful C++-centric library.

Megalomaniak Plus unless you wrote the engine from scratch around the physics engine you've picked you'll probably have lots of odd bugs(see godox 3.x and bullet) or just straight up some of your engines features might not be able to integrate with or benefit from physics.

Right, but I'm pretty sure there was a competition to develop both approaches for 4.x (custom 3D physics and multi-backend support) and supposedly multi-backend is winning. Haven't tried it, and I'm skeptical how well it actually works, but it should work if the APIs align close enough. A mature and well-designed library will have all the integration hooks you possibly need.

I don't know how bad 3.x was, but 4.x physics is janky and people are calling it a downgrade. A few issues in 4.0 were acceptable but if it's still a mess in 2024 people will jump ship and we can say yeah, custom physics was a mistake. No doubt it seemed like a good idea after struggling with Bullet, but the grass is always greener on the other side, and maybe half the problem was Godot 3.x being a mess.

Kojack

Ignoring all the dependencies, Blender itself has (including headers) 1583 C source files and 4147 C++ source files.

I don't see any D source in it though. D is a great language, I love the combination of compile time function evaluation with string mixins.

Megalomaniak

Kojack I don't see any D source in it though. D is a great language, I love the combination of compile time function evaluation with string mixins.

I recall D being in use somewhere about a decade ago, may well have been refactored or otherwise removed since then.

xyz

synthnostate Writing an engine whose central architectural premise revolves around class inheritance in a language like C that doesn't even have classes, sounds rather scary. But to be hones I haven't touched C in decades so I might be biased there.

JusTiCe8

xyz Writing an engine whose central architectural premise revolves around class inheritance in a language like C that doesn't even have classes, sounds rather scary

That's quite funny actually because object model have to be created somewhere between the native assembly language of the processor and the user's IDE.

synthnostate

xyz It's not hard at all. C has structs which are just C++ classes without the method/operator syntax sugar and the horrible inheritance system.

typedef struct Node {
    ...
} Node;

Node* node_new();
void node_free(Node *node);
void node_rotate(Node *node, Quaternion *quat);

The typical convention is to pass the 'object' struct pointer as the first argument, as you do behind the scenes in Lua, Python, etc, so you write e.g. Node.rotate(quat) as node_rotate(node, quat). It's actually nice not having to think of every function as a member of one class or another. Sure, function names are a little awkward but not nearly as awkward as C++ iterator and template syntax.

xyz

synthnostate Well, coupling code with data is one of the key concepts in OO. So saying that structs are just classes without code sounds really funny. Almost like saying that C is just C++ without objects, generics, execeptions... and rvalue references 😃

You're making it sound like one can't have non-member functions in C++. Good thing with C++ is that you can still do stuff pure C style or go with "horrible" C++ style... or be somewhere in between depending on your preferences and project needs. The point is, you have more options, which is generally better than having less options 🙂.

At this point I'm not sure I could endure a chunky project in C without all the STL goodies, to name but one C++ benefit over C. Template syntax can get beffuddling only if you need to build some elaborate template classes yourself or read compiler error messages they generate. But that's reserved for uber-geeks. Using someone else's templates is generally fine. And addition of range for loops over a decade ago made iterator syntax quite clean for majority of typical iteration cases.

I use quite a few major C apis and I dislike the interface in every single one of them, Python api being the notable example.

The simplicity of C is pleasant, but lots of times you just want to be able to wield some heavy weapons when coding close to hardware, even if they look a bit fugly.

synthnostate

xyz You can't use STL or Boost in a game engine, not if you're serious about performance and maintainability. In a big project with lots of developers you want to keep language complexity and compile times to a minimum. Heavy weapons, lol, you'll shoot your eye out!

I know you know what you're doing, I've learned a thing or two from your posts, but I think you underestimate the cost of all this complexity.

xyz

synthnostate My point was, you're not force fed complexity with C++. You can dose it as needed. C++ is a very pragmatic language by design. Listen to any Stroustrup talk where he addresses all the typical criticism points. One of its key powers is backward compatibility with C. Unfortunately this is also the main reason for some of the awkwardness in its implementation of higher level concepts including object orientation. But imho retaining this compatibility while getting access to many of modern high level language features is worth the quirks.

I've used STL in game projects, although I do agree that using it in a multi platform engine like Unity might get problematic, but it's surely not impossible. It really depends on the STL implementation.
I wasn't talking specifically about game engines though. STL is generally very useful productivity wise.

Besides, you can shoot your eye... and possibly a foot... with plain C too 🙂

« Previous Page