The anatomy of a Godot API call
sampruden.github.io
sampruden.github.io
To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for Godot and C# ecosystems, and more emphasis on the ability to use very rich selection of libraries written for .NET would not hurt either.
And while it's desirable to optimize the glue and make scripting fast, that's also a much larger engineering project; Unity did it by spending big.
Pretty straightforward API changes. After a design is decided on just some tedious typing work. Heck, it could be dog piled easy enough.
if that's my go to solution, why am I using Godot instead of Unreal? Or even a more mature C++ renderer framework like bgfx, or even Ogre3D? In the context of a decent 3D game, I'll need that performance the lion's share of the time, only scripting to move GO's/Actors around the scene.
No revenue split would probably the biggest reason. Also Unreal could still pull a Unity since it is not FOSS (unlikely, but still).
Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.
> even a more mature C++ renderer framework like bgfx, or even Ogre3D?
IMO this is actually the way to go & it is probably the way I'd do it if I had the time to build editor-like tools by myself. But these days content is the hard & time-consuming part of building games. Which means you want non-coder gamedev to be able to do as much as they can, which implies a powerful editor. Godot & Unity have the advantage of pushing the game development to the editor instead of the code.
Indeed, but even Unity isn't known for its high performance 3D titles. It COULD viable do them, but not without a lot of work.
That was supposed to be something that DOTS would address, to take out "a lot of work" and make that performance almost be taken for granted. But... well, I don't want to go on that rant again. You can excuse some performance and optimize later, but the sounds of things from this article (with general sentiments even from diehard Godot fans that Godot isn't ready or serious 3D development) makes it sound like that optimizing will in fact exceed the content creation time.
I've seen enough of the guts to know that Godot will likely never make its own DOTS. At least, not its own Burst compiler to get around the c# issues. Likely not IL2CPP either. Fortunately, you don't need that and can get maybe 80% of the performance by simply following some data oriented principles. More than enough for all but the most lofty AAA games (think GTA6 levels of scale).
----
>Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.
that's good to hear, and I get it (Unity rushed out tons of features itself. Including DOTS). I hope I can one day contribute to that effort myself. Would make my future game dev life much easier and would be a good way to give back.
One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying:
> As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq enthusiasm ).
It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then.
Further down though somebody points out:
> Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects.
This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places:
> C# is faster, but requires some expensive marshalling when talking to Godot.
I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..".
EDIT: That said, I'm very impressed with Godot in general and a lot of the C# integration. They are making pretty good use of source generators making a lot of string magic replaceable with type-checked property accesses. Signal creation and exporting properties to Editor members works this way; cool! I think they will end up working through the worst of these interop perf issues.
As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.
Maintaining two API binding layers is perfectly feasible with the attention and resources Godot is attracting.
Unlike with Unity interested parties can jump in and lend a hand. You'll have two groups(perhaps overlapping) maintaining the compiled and script bindings.
Maybe GDScript could just get the concept of a struct and the differences minimized over time too.
But yes, I think it'd be best long term to treat GDScript ad C# the way Unity treated GameObjects and DOTS. DOTS's goal wasn't to kill gameobjects, and in fact a lot of work went into bridging between the two with hybrid packages. I guess we'll see if that kind of initiative gets some momentum (and I'd love to help out if so!)
How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey
Not a terrible thing if you want to concentrate on their needs, but not the best questions for filtering ideas for expanding adoption (perhaps).
The community will dislike a change that will drop GDScript, check the Godot subreddit submission (linked by the article), a ton of comments were pro-GDScript and how easy and fast (development-wise) it is to use.
If that change can happen without affecting GDScript i doubt anyone would have any negative thoughts. There have been a couple of suggestions in the subreddit post on how that could happen and the Godot developers seem to be thinking about it.
That ease of use is important, but also may be holding back Godot's true 3d capabilities. From a cursory glance as someone wanting to work on a decent scale 3D game, I'd need to treat GDSCript as I do Unreal's Blueprints as of now: miniize use only to high level scripting and maybe UI/Shader code. That's not me saying that GDScript nor blueprints is bad, just that it gets in the way of my specific use case.
If I can help speed up the engine underneath as a whole in the process: wonderful. I don't necessarily want to disrupt GDScript for my convenience either, but like any refactor some breakage is inevitable.
UE’s blueprints are much(!) slower than native code, but they’re still an incredible tool in the toolbox. GDScript is kind of the same; it’s covering a critical role of non-performance-sensitive glue.
That said, I’d really like to see Value Types added, as well as these sorts of heap allocations addressed in Godot 4 at some point.
(not that that should be an issue due to python being able to directly output C code, but you understand the point).
To be honest, I'm surprised how dismissive parts of the gamedev community can be about improving performance of their game engine. That was a huge complaint from Unity and you'd think people would be interested in not repeating those mistakes with Godot.
That said, how prevalent is the former vs the later really?
Unity took several years, and a huge amount of investment, along with improvements in the wider ecosystem, before performance became much less of a concern for normal developers. A lot of the work they did around C# usage to achieve this is really surprisingly intense.
In the near future I seriously think 2D (and some subset of simple 3D) game devs would be better off looking at Defold, and if you want to make immersive 3D just bite the bullet and move to Unreal. These days cost of preparing assets drastically exceeds coding time anyway.
The developer experience is very similar to Godot, especially if you work on your scripts with external editors. Everything that has to do with building and running the app is faster than Godot though.
Initial builds with Defold are very fast, it has on demand hotreload, and very small binary sizes. The small binary size makes it well suited for working on web games.
The Godot Editor is still a tad bit nicer to use, but I do like the fact that the Defold editor is written in Clojure. I imagine it makes extending it fairly quick.
The main reason I see myself sticking with Defold over Godot is because scripting is done in Lua.
The Lua ecosystem has a lot history in the game dev space making it easy to search for answers. Lua is trivial to extend and has multiple statically typed options that compile to it. Notable statically typed languages are Typescript and Haxe. Also Lua has a lot practical use in many domains outside of the Defold editor unlike GDScripts lock-in to Godot.
Defold has no where near the size of the community of Godot, but the developers seem very active on the forum and GitHub.
I need to play around with it more before I’m 100% sold. Both Godot and Defold are great looking choices for 2D.
Since Godot is right there, I'd rather try and bring up a current up and coming engine to somewhat parity rather than give up to Epic.
Also, iteration is godawful in Unreal. Not everyone is trying to make Gears 6, so I wouldn't mind a more lean 3D engine to work with if I have low-poly or simply not-dense scenes to manage.
>These days cost of preparing assets drastically exceeds coding time anyway.
Only if performance isn't a concern. There's a reason engineers are still paid more than the equivalent artist at studios. That performance is still hard to work with or around, even in Unreal Engine
Defold is basically a pile of interesting simple subsystems, especially around game logic, that in combination become surprisingly powerful, and the experience of the devs shows. It is one of those tools that even if you never use it again some of the ideas stay with you.
Is this true really? It appears to have been bought by King (Candy Crush Saga) and used internally (see the Defold about page). So while it may be associated with mobile/casual gaming it was worthy of being purchased and used by an otherwise successful company -- at least along some metrics.
Acquiring anything usually has a period of investigation and inquiry which Defold passed.
Seems at least worthy of consideration next to Heaps and Godot.
Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.
We are talking about GDScript not JavaScript.... Oh wait, the parallels are remarkable
Simple language designed to be easy to learn: Check
Turns large codebases into a tangled lovecraftian mess of spaghetti code: Check
Likely to be someone's first introduction to programming languages: Check
Honestly reading the criticisms of GDScript so far is convincing me more and more that Godot is quickly going to become the next big thing, especially if the developers can figure out how to get people to use it for thier first programming project. After all most people I know who got into development started because they wanted to make their own video game.
How likely would you say the same effort is gonna go into GDScript?
Hard to predict. We're still in the web 1.0 phase of Godot and dealing with questions like why we made a <blink> tag. We could get serious talent addressing the binding layers, we could simply have a few key bottlenecks addressed, or we accept GDScript as the slow path and diverge. It could also simply fade away, but many don't want that, and I'm also not too interested in deprecating something many have used to launch full games.
Personally, my goal is less about making a scripting language perform as well as c++ and more about having options to make sure people can port from GDScript to some faster binding if/when they run into performance bottlenecks. At worst, maybe a migration tool may be needed. Hard, but more doable than any of the above overhauls.
My point being that a lot of the concerns are not foundational to Godot and GDScript and can be improved if there is an investment. But that investment will come with adoption, not the other way around.
Its hard to compete with an almost 25 year old battle-tested language, but given the domain and the team size, its a good product and worth pursuing IMO. With that said, I wouldn't want to give up the ability to have C# interop when I need it, and I imagine many games would need to be rewritten in C# after a certain point.
Other scripting languages are also easy to learn. Vanilla Javascript is much easier than GDScript. And so is Lua. Kids learn coding in Lua. Even Python isn't that difficult compared to C#.
It's only benefits are native integration with the client, and guaranteed support in perpetuity, and it's easy to write, and easy to learn, and teach, it almost never surprises you in ugly ways (which is awesome), it comes with a good enough debugger, its library pretty much covers what you need to make your average indie game... But what did the romans... I mean, GDScript, ever do for us?
Hey, if GDScript could run my idea for a 3D Open hub Action RPG at 60fps with little concerns for performance, I'd have no issue.
But alas, my desire for a proper binding or directly tapping into the c++ comes out of necessity, not some pride as a "real game developer". It's not impossible for GDScript to one day become the WebASM of Godot, but we both know that WebASM was, and still is, decades in the making. I imagine it's simply faster to forge a fast path API and let the slow path work for non-performance intensive games.
There's almost no nasty surprises. Nothing like learning JavaScript and then discovering the weird behaviour of this, or using Python and discovering for the first time that the weird bug you had was because you set a dictionary as a default value for an argument.
It's got some of the syntax sugar you might expect from modern languages. Not as much as Python, but that might be for the best if they're trying to keep things simple.
Some of the syntax sugar (@onready, $, %) is specifically there to integrate with the engine and it is very very nice.
Documentation is good, integrated with the editor and the inspector.
The debugger works well (98% of the time, hopefully it'll keep improving).
It's one of the nicest languages I've learned in a long while. I think it's because it's only trying to do one job and it does it fairly well.
When I started learning it I noticed many things that were done better in other languages I've used (it's specially tempting to make comparisons with Python since it looks similar). After a few months using it almost daily to make a somewhat simple game I realised most of those things don't matter and for the purpose of making games in the engine it's pretty solid.
I also very much like the way signals are declared compared to C#’s code generation.
I’m also a fan of TypeScript, so being able to do gradual typing while prototyping is a huge plus. It’s going to be a big advantage if they ever get JIT.
Everything being reference-counted, rather than fretting about GC pauses is comforting too.
Also, having used both Boo back in the day and GDScript in Godot more recently, I'd say that one big difference between the two is that Boo was really bad, and GDScript is actually pretty good.
I don't think Godot should go that route.
Unreal seems to have the most features and the steepest learning curve.
Unity is comparatively easier to learn. Fewer features but C# support is a big plus. The major downside is that the company is run by incompetent MBA brains.
Godot is open source (awesome!) but doesn't seem ready for prime time. It doesn't have as many features as the other two and the commitment to GDscript seems... odd.
If I were picking a game engine today, it'd be between Unreal and Godot, but I'm not sure I'd feel great about either choice.
not much odd about it. 3d game engines are a large endeavor, somewhere between making a Large desktop application and making a full blown OS. I'd say the largest ones are comparable to making a web browser engine or even a full blown IDE suite.
There's also some slight snide in that there is no truly "good" game engine. Just ones that teams put up with enough to get across the finish line. The sheer scale of the engines and the nature of them being developer suites means running into edge cases is inevitable.
There are several mature 3D solutions out there, but the ones mentioned have the 3 largest communities and are strongly supported. But to throw out a few others
- Open3dEngine (O3D3), and fork off Lumberyard, which is a fork off CryEngine, is probably the biggest off-the-shelf competitor to UE when it comes to delivering AAA level games.
- Stride is an engine mentioned often in discussions, and it has a similar feel to Unity. But it simply isn't as mature as Godot and lacks some platform support like Mac
- UPBGE is the spiritual successor to the defunct Blender Game Engine, with a similar pitch: create your game without ever leaving your modeling suite.
-Finally, while not a fully featured game engine, I do want to give some note to Ogre3D. It's one of the oldest and most battle-tested graphics libraries out there, is MIT open sources, and is there for the kinds of developers who rolled their own engine/framework and simply used Unity as a rendering backend. Ogre doesn't include physics nor input (nor an editor), but it's really good at throwing your hand rolled game logic and giving it something visual. I could make similar other recommendations for stuff like Raylib and BGFX, but Ogre still being supported after over 20 years is admirable.
There aren't tons of choices, but there are choices out there if you are willing to get your hands dirty.
I'm a fan of Love but I have to admit the amount of Lua I wrote for just my prototypes did start to get a little scary.
I might have a play with raylib.
I think its probably better to look at Unreal as state of the art but licensable. Other big game companies have cutting edge engines but they're proprietary and not available to license.
Unreal isn't good just because of the graphics. It has loads of tools built in, and that's where most of the value is in my opinion.
This video will give you an idea: https://www.youtube.com/watch?v=k2IP5DYQ0-0
As much as I love Godot, the GDExtension interface really has no redeeming qualities and needs to go back to the drawing board.
That would be Joachim Ante, who is no longer CTO. He's "on sabbatical" and hasn't contributed any posts to the forums for over a year. (He used to be quite active on Unity's forums.) The entire leadership of the ECS/DOTS team has resigned.
And of course the moment he silently stepped out, Unity rolls all this BS out in less than 6 months. Joe wasn't just champion of the tech, he was likely one of the last of the old guard up top keeping things focused on the actual product instead of how to extract infinite monies.
Recently because of the drama or unrelated? That’s sad to hear as I was very excited on that effort.
EDIT: It was in May.
Unity has their fair share of bolted on methods with a "NonAlloc" suffix. Seems obvious to prioritize raycasts / intersection / collision code to receive this treatment.
I've noticed a few lower lift things I'd like to submit PR's for, just to see how/if I can help.
Nothing stop you from modifying the engine code, but the problem lies in the binding layer, not the engine perormance (as you see in the blog, the raw engine performance for a raycast is about the same as Unity). That's a bit trickier to fix without intimate knowledge of such bindings, and you'll likely break a lot of GDScripting support (so by extension, c# scripting) in the process.
[0] https://crates.io/crates/netcorehost
*edit* everything in the article is on point. Function pointers as binding glue sucks. There’s tons of optimizations to be done in the engine for sure. However, having a robust C# api is on top of list since it was introduced. I do think Godot 5 should make a hard choice and just support C# instead of GDScript.
discussed here https://news.ycombinator.com/item?id=37598985
Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#.
This dismissal of honest performance benchmarks is why I'm glad you're not leading Godot. We're not talking about some esoteric cloth simulation code being nitpicked. These are core architectures issues costing you 2x performance minimum, simply due to how the c++ and C#/GDSctipt/GDExtension layers talk.
Take this as a warning, not a dismissal. Unity went down this exact path and we see how viable it became for large scale game development. I sympathize with you for those who are outright trashing the GDScript for being a scipting language, and I do wish those arguments would die down (it's simply language wars). But there are definitely fixes here that would improve all diferent bindings, even if they never diverged (which IMO, they should).
>This is like showing up for dinner and insulting cooking before you’ve even tasted the meal
cooking is subjective (mostly), performance is not. This is more like asking why the cook is trying to carefully drain out the water with a loose lid instead of using a strainer. Sure, it may work for the cook and they've done it all this time, but I'd rather give a safer solution that won't burn them long term, or spill out excess food.
No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting.
If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Better memory utilization, better processor performance[1], and no more garbage collection stutters. Oh right, it’s not your preferred language.
I’d rather we all just make games instead of fighting language wars, but seeing so many of these posts in the last week makes the community feel hostile.
[1] https://programming-language-benchmarks.vercel.app/rust-vs-c...
The author has already crossed the part out suggesting to remove GDScript. Which was overblown as it was one of 3 different suggestions.
Either way, even for the rude provocateurs, two wrongs don't make a right. I've follow Godot with a loose ear and it's not a surprise that there are significant performance issues in the engine. I'm glad someone is digging deeper rather than just saying "Godot isn't ready for 3D" and dismissing opportunites to grow.
>If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively?
Because you didn't get to the part of the article where it is mentioned that GDExensions uses the same api bindings as GDScript. So they are all affected by this, no matter what binding you make. Your only recourse is diving into the guts of Godot and rearranging how it works. Which is first of all, already in flight by the core team (redundancy) and secondly, not a kind of change you can easily PR in if you want to contribute (which is more hostile to the engine than any random post on social media).
And yes, this is the dismissal I'm talking about. "well just use another engine" is a pretty bad approach for a growing community when receiving honest feedback with benchmarks to back it up. The author makes a long post detailing the inner guts of the engine and people cherry pick one conclusion they don't like and want to push the author out of the community.
I am aware of the part about how this affects bindings for all languages. My point still stands that this is premature optimization. The author even admits, “In some projects 95% of the CPU load is in an algorithm which never touches the engine APIs. In that case, none of this matters.”
So again, if this is about performance then why not remove c# as well? If we’re to “tear it all down and start again” we might as well do it in rust. Oh? If I want a rust game engine I should look at Bevy. Is saying that really a second “wrong”?
I don’t have anything against this author specifically. I respect that they did more than simply look at the showcase screenshots to make their assessment. My initial comment was more a general expression of frustration with the prevailing attitude on various forums. I like reading r/godot to see individuals creating games, not creating grief. (Frankly, I found the Unity memes to be a bit mean spirited as well.) I acknowledge my initial comment did nothing to remedy the situation but I was tired of hearing it. I have since stopped reading that subreddit. Enjoy your c# crusade.
Given that the author knows they will make hundreds of raycasts a second, and that the perf suggested that they can at most make 700 for an entire 16hz frame, I can't agree in this case. This is the exact kind of "we'll fix it later" kind of unoptimization that makes gamers wonder why games still hit 30fps on modern hardware (I've worked on such a tile, in UE4. the engine doesn't save bad practices and useage).
>My initial comment was more a general expression of frustration with the prevailing attitude on various forums.
don't generalize your rants when you see a good example of criticism. That just lumps in the good with the bad and makes you look like you're lashing out at any criticism.
>Enjoy your c# crusade.
Enjoy prowling r/godot, I suppose. If that's the conclusion you gleam out of my comments, you fit right into Reddit. Making unrelated rants and being confused on the disagreement and seeing everyone as out to make your life specifically, miserable. Glad I left that behind months before it became fashionable to leave.
Is this in response to the article in question? Because they are spot on with their assessments and those API issues need to get sorted. They impact bindings and all extensions including C++. The core devs seem to concur on this, it's just a matter of how it happens.
I think Unity was like 3MB with C#
Not a big deal for a lot of cases. Don’t let it deter you. But for my specific target it was a problem.
To be honest I’m not sure how Unity can be so small. Does it compile the C# or something avoiding the need for a beefy runtime?
I ended up sticking to GDScript in the end, but the typing system is very basic and the code can get very messy quickly. Plus, as far as I could tell, there is a race condition between signals and the process function, but I need to debug that more thoroughly to be sure.
From the subreddit submission about this blog post (linked in the post itself) it seems this is something some people already do.
The GDExtension API seems something to use only if you want to write C++ extensions/plugins to be usable by other people, but i don't see much of a point in restricting yourself to it if you are making your own games.
> The main difference between the .NET collections and the Godot collections is that the .NET collections are implemented in C# while the Godot collections are implemented in C++ and the Godot C# API is a wrapper over it, this is an important distinction since it means every operation on a Godot collection requires marshaling which can be expensive especially inside a loop.
> Due to the performance implications, using Godot collections is only recommended when absolutely necessary (such as interacting with the Godot API). Godot only understands its own collection types, so it's required to use them when talking to the engine.
TL;DR is that they know this & working on it
So on the one hand, yeah, 4.0 lacks polish, and I certainly have felt some strong feelings working with GDExtension... but I also believe there was a reason for that, and I believe the team when they say they're working on improvements now
That said, I'm still enjoying Godot, the only fun part in the past week.
This is probably the biggest red flag for me, why would you use an untyped dictionary for something as essential and commonly used as a raycast result?
I know it's not the same thing at all but it's as close as you're going to get.
I think Godot has this really nice looking editor, and the nodes look nice, but the engineering foundations are just not there.
I think a lot of people start Godot projects but not many finish them because they run into these WTF issues.
Like, my reaction to the blogpost is, "oh, OK, if raycasting nodes are fast, and I need a lot of raycasts, then worst case, I will introduce a custom node designed to do 300 raycasts in one call or whatever."
The corresponding WTF in Unity tends to be "sorry, no code access, SOL" so the inclination of a Unity dev is that they need as direct an API as possible and it needs to be as fast as possible. There are tremendous numbers of shipped Unity games that don't trust the engine to do what it's supposed to and just use it as a HAL, and so there's a culture clash in approach which makes Godot the wrong tool for a dev that wants that kind of system.
Godot has a beautiful editor and great tooling for a free engine ... but I worry about the choice of C# and GDScript as the expected way for devs to interact with the project (what if performance is a concern or you need to develop some low-level features).
Another post in this thread said the C++/native interface was not great and difficult to work with. And C++ even in the best of times is not my favorite thing to work in.
Either way, I don't think either is ready for prime time as its still early development.
https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_be...
1. the engine isn't stable and has breaking updates (why does that sound familiar...)
2. ECS is hard to learn and Bevy is too strict with ECS.
It's hard in the same way OOP is hard, I guess. But it's just that: a paradigm. It's harder to google because ECS is a specific paradigm for applications that want to follow data oriented design. If you don't care about that, then you lose all that benefit and google-ability for not much gain.
I guess that's just the state of FOSS game engines right now. People basically just want Unity/Unreal without the copporate overlords. But while oppressive, they also did fund the engineers to make those solutions so attractive to begin with. You'll inevitably get your hands dirty if you go of those smooth UE/Unity roads. Especially if you're choosing an up and coming language like Rust on top of all things.
There's been no real demand or contributors to improve it, but it's open source so there's no reason you or anyone else could stamp out the bugs https://github.com/gfx-rs/wgpu#supported-platforms.
Besides, for the scale of games currently coming out of Bevy, you should be able to use Vulkan to pipe your game into a PS port.
Haven't tried it in a project yet myself
> However, one major issue holds it back - the binding layer between engine code and gameplay code is structurally built to be slow in ways which are very hard to fix without tearing everything down and rebuilding the entire API from scratch.
If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly quickly if people start flocking to a tool.
This is wonderful criticism! It's thoughtful and well-researched. Hell, even I'm inspired to finally dive into Godot's internals, which I've yet to do despite following the project for several years. I hope this inspires even more contribution and constructive criticism.
They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.
That's more the problem of Reddit's code being a pile of bull dung. Someone high-level in there decided to ditch the "old" API for the "redesign" in favor of GraphQL and as everyone who has ever worked with GraphQL is likely to have discovered, GraphQL is a hell in itself.
And because whoever was moronic enough to call that decision doesn't want to admit they have fucked up and Reddit can't/doesn't want to afford maintaining two distinct APIs, they decided to rather shut down the old, working and performant API.
Reddit is being killed by corporate bullshit.
There's no point comparing year 30+ of Javascript to year ~10 of Godot. Remember that year 10 of JS was the time when Flash reigned supreme.
>They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.
I agree and am glad that we're finally putting a halt to bandaging up the leaky pipes known as JS and releasing stuff like WebASM. Fortuantely, Godot is nowhere near as heavily bandaged and has easier access to change.
I'm glad to see that tools can exist in only one of 2 states, massive world wide adoption and support by big corporate, or a couple of devs screwing around. I wonder if it is possible for a tool to transcend this limitation?
If only there was a way for multiple people to use a tool, push for it, enhance it and for it's adoption to grow and spread to large pieces of the community eventually gaining corporate support. But nah, things like that don't happen. After all if there is one thing I've learned a scripting/game/animation engine that is easy enough to use and is flexible is something no one really needs anyone, a product like that would probably disappear in a FLASH, after all.
Javascript is fast since it is such a simple language that is easy to optimize, more complex runtimes wont see nearly the same amount of gain from optimization efforts.
There's just been no demand to make Python crazy fast, not to the scale where even Google will throw their engineers at it. Python's use cases aren't in real-time applications so that level of performance concern is simply not needed for many. And those that do will use anything else on the backend, from C to Go, maybe even Javascript.
Also, have you heard of JavaOS? https://en.m.wikipedia.org/wiki/JavaOS
Sun had experimental support for Java drivers on Solaris, Android has support for writing drivers in Java, Android Things only allowed for Java written drivers.
It reminds me of the linux debate:
- A: I hate Windows telemetry
- B: Then switch to linux. It's as good
- A: But it doesn't have a good video editor.
- B: You should develop your own video editor and share it with the community
- A: Ughh... I just want to edit my videos...
I use linux and love it, but there are users who need Windows or Unity.
>I use linux and love it, but there are users who need Windows or Unity.
Need is a strong word, but I will never judge someone on the tools they use (well, not on a personal level. I will judge you if you choose to make a game in Microsoft Powerpoint, you madman). But if you're going to complain about big business and then wonder why you can't find a good alternative when your complaints fall on deaf ears... well, you see why they are still in business.
I've simply shifted my mindset over the years from trying to tear down the evil, and instead build up the good. It's a much more productive way to live much of life in general.
Seems like a fun weekend project
Otherwise sure, that misguided evangelicalism is hurting trust in open source software, when people claim it is ready, where it isn't.
The proof, as they say, is in the pudding.
But with so many eyes on Godot now, I can only see it getting better.
>I'm making a top down 2D game and Godot's too slow to handle my character controllers at 120fps without a lot of hacks. In Unity they run in 2ms. It's not just The Last of Us that this matters to.
>The controller gets used for NPCs too, so I can have quite a few of them on screen at once. It's got quite a complicated substepped movement and collision response system which does lots of ray and shape casts. A typical frame may end up around 500.
Even if its not efficient for their specific game, a few hundred raycasts should not be taking nearly a millisecond to perform. No wonder there's so much work to do to get Godot to be 3D ready.
I guess I'll see for myself next year as I work on a 3D title. But my current research doesn't make me optimistic. I am very much ready to help contribute to address these sorts of issues if/when I run into them. But I want to actually contribute, not just take my ball, fork, and redesign the engine. If I get this much friction introducing optimizations, and/or am unable to find out who/where is working on such things, I don't know what to say.
>Mixing fast and slow APIs as discussed above would leave us with headaches for decades
Meh. Unity has allocating and "NonAlloc" methods, even on the raycast API in question here. It's a really minor issue.
Sounds like Godot will need more time to bake before its perfect but we already knew that.