[HN Gopher] The anatomy of a Godot API call
___________________________________________________________________
The anatomy of a Godot API call
Author : amitmathew
Score : 151 points
Date : 2023-09-18 20:43 UTC (2 hours ago)
(HTM) web link (sampruden.github.io)
(TXT) w3m dump (sampruden.github.io)
| gustavus wrote:
| The thesis of the article appears to be
|
| > 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.
| kevingadd wrote:
| Solving some of those performance problems can also require a
| massive amount of engineering resources and investment, though.
| For example the way browsers (generally) overcame interop
| overhead was by _self-hosting almost everything in JavaScript
| or making things into JIT intrinsics_. That 's a tall order for
| something like Godot with two languages.
| guideamigo_com wrote:
| Javascript still remains slow. Java is fast enough that it
| doesn't matter. However, no one will use Java to build Linux
| kernel.
| foderking wrote:
| JavaScript isn't slow
| viraptor wrote:
| JavaScript is very fast if you want/need it to be.
| Emscripten/asm.js approach is in the same category as native
| for example. Your simple code won't be too fast, but not all
| code needs to be.
|
| Also, have you heard of JavaOS?
| https://en.m.wikipedia.org/wiki/JavaOS
| wiseowise wrote:
| Define slow. JS is plenty fast for a dynamic language.
| [deleted]
| AndriyKunitsyn wrote:
| JavaScript is fast because it is used by every person every
| day, so lots of smart people from big companies put lots of
| thought how to make it fast, and I still get a feeling of
| overwhelming anger when browsing the new web Reddit on a
| 4-years old phone. Godot is a game engine supported by a
| community (not big companies).
|
| They are not really comparable. And sometimes, there are still
| performance ceilings imposed by a nature of the tool.
| gustavus wrote:
| > JavaScript is fast because it is used by every person every
| day, so lots of smart people from big companies put lots of
| thought how to make it fast, and I still get a feeling of
| overwhelming anger when browsing the new web Reddit on a
| 4-years old phone. Godot is a game engine supported by a
| community (not big companies).
|
| 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.
| mschuster91 wrote:
| > so lots of smart people from big companies put lots of
| thought how to make it fast, and I still get a feeling of
| overwhelming anger when browsing the new web Reddit on a
| 4-years old phone.
|
| 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.
| mdbauman wrote:
| It's for this reason that I appreciate this article, even
| though it has a (playful, well-intentioned) negative tone
| toward Godot which is a project I donate to.
|
| 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.
| lainga wrote:
| It feels like a breath of fresh air to me. Yes, random
| people, come in and start using Godot, the more eyes are on
| this project the better. They're articulating gripes I have
| had but couldn't express. It would be great if, like JS, all
| the attention became an impetus to make Godot really fast.
| Jensson wrote:
| Python is still slow today. I've worked with performance
| sensitive python at Google, there is no way to make it fast no
| matter what tool you use except to rewrite it in a lower level
| language.
|
| 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.
| karaterobot wrote:
| This matches up with what I've heard from people with experience
| in both Unity and Godot. As convenient as it would be if Godot
| was ready to swap in for Unity, it's got some significant issues
| that would make that difficult to unfeasible for many people.
| [deleted]
| CodeCompost wrote:
| Nobody suggested that Godot was on par with Unity. The hope is
| that resources get diverted away from Unity towards Godot so
| that it can develop into a top-notch game engine. It's time to
| stop waiting and start working on Godot.
| karaterobot wrote:
| I've seen comments here on HN that make me believe some
| people think Godot is on par with Unity, or that it will be
| soon. The title of the linked article also acknowledges that
| some people in the world at least have a misapprehension to
| that effect.
| rhtgrg wrote:
| All you have to do is look at games made with Unity and
| compare with games made with Godot.
|
| The proof, as they say, is in the pudding.
| fluxem wrote:
| You clearly weren't on reddit. Everyone there will urge you
| to switch to Godot even though your game is almost finished
| and Godot doesn't have feature parity.
|
| 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.
| hutzlibu wrote:
| It is probably not on par with the professional video
| editors and it is not very intuitive to get started, but
| blender has a build in video editor, that should cover most
| basic needs.
|
| Otherwise sure, that misguided evangelicalism is hurting
| trust in open source software, when people claim it is
| ready, where it isn't.
| sockaddr wrote:
| > You should develop your own video editor and share it
| with the community
|
| Seems like a fun weekend project
| riwsky wrote:
| We think that a significant advance can be made in one or
| more of these problems if a carefully selected group of
| scientists work on it together for a summer
| Scalene2 wrote:
| So, what I'm gathering is if you're bothered by the Unity (either
| a developer, publisher, gamer) developments, and wish Godot was a
| better alternative than it is, contributing to the project (by
| donating either time or money) is probably necessary to get
| there.
| Waterluvian wrote:
| I tried using Godot for Web game toy projects and unfortunately
| the base file size is like 12MB and closer to 40MB if you use C#.
|
| 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?
| Hamcha wrote:
| Dunno if it was your case but yes, Unity has had AOT
| compilation since forever with both ILCPP and (more recently)
| Burst.
| amitmathew wrote:
| There's a good post on Reddit of a dev creating small web
| exports using custom builds: https://old.reddit.com/r/godot/com
| ments/16lti15/godot_is_not....
| [deleted]
| Waterluvian wrote:
| Thanks. I first misread the C++ part but it sounds like they
| have some way of paring down the runtime when using GDScript.
| I'll have to seek that out.
| fidotron wrote:
| When I first encountered Unity it was because there were
| performance problems on a Japanese only version of Bejeweled
| built with it and they needed someone to fix it. It was a
| classic: creating huge numbers of new objects for particle
| effects hammering the gc, and the fill rate of the then cutting
| edge device GPUs not being a match for their screen resolutions.
|
| 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.
| Fraterkes wrote:
| What advantage do you think defold has over godot for 2d (apart
| from currently seemingly being more polished)? Theres lots of
| people complaining in this thread that GDscript is not serious
| enough as an engine language, but Godot at least has a decent
| c++ api. Defold only seems to support Lua (although you can
| extend the engine with other languages afaik).
| jayd16 wrote:
| Funny that they have to use a custom dictionary setup when C#
| supports dynamic types.
|
| >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.
| [deleted]
| rybosworld wrote:
| One thing that stands out as odd to me is the small selection of
| really "good" game engines.
|
| 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.
| jay_kyburz wrote:
| I'm thinking about going back to 2d. If Factorio and Slay The
| Spire can be smash hits in 2d, perhaps I can as well :)
|
| 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.
| Madmallard wrote:
| [flagged]
| neonsunset wrote:
| So the decision for slow interop is caused by choosing to have
| parity between GDScript and C# because the former forces the
| types to be heap-allocated...and community might dislike a
| performance-friendly change which will break the parity in favour
| of C#.
|
| 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.
| Rapzid wrote:
| Here is a discussion from the proposal repo I found with the
| topic of improving C# support:
| https://github.com/godotengine/godot-proposals/discussions/4...
| .
|
| 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..".
| Dudester230602 wrote:
| The history is cyclical here it seems:
| https://blog.unity.com/community/unityscripts-long-ride-off-...
| badsectoracula wrote:
| > community might dislike a performance-friendly change which
| will break the parity in favour of C#.
|
| 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.
| __loam wrote:
| It is pretty shitty how people seem to be coming into Godot
| and immediately shitting on GDScript without trying to
| understand why it was built that way, and I say that as
| someone who shit on GDSCRIPT initially.
| TazeTSchnitzel wrote:
| GDScript is in a much better place than most scripting
| languages because the compiler actually has quite a lot of
| static type information. If they invest in unboxing
| optimisations and a JIT, it can definitely become competitive
| with C#.
| shmerl wrote:
| What about other bindings, like with Rust?
| meepmorp wrote:
| Apparently (per the article) the C++ bindings use the same
| API as c# and GDScript. Presumably rust would have the same
| limitations, unless you wrote a whole new API just for it.
| shmerl wrote:
| Sounds like something they can improve then.
| xmonkee wrote:
| I've only briefly played around with Godot, but how does one
| get type-assisted autocomplete on variables and methods? Is
| there a type-hinting for the IDE? Kind of broke it for me.
| Maybe I should've tried C#.
| rsstack wrote:
| You have to make sure you opt into the type-safe GDScript.
| It's not easy. There's an IDE feature that highlights lines
| that are not type-safe but the default color is a hard-to-see
| grey. I changed it to be red ("Line Number Color" is the one
| for untyped lines), and then fixed all typing issues. Then,
| autocomplete works as does cmd+click to go to definition.
| janosdebugs wrote:
| In GDScript you kind of get code completion. Kind of. 50% of
| the time it doesn't give anything useful.
| TazeTSchnitzel wrote:
| There is optional static typing. If you write type
| declarations, the editor will not only give better code
| completion, but it will use type inference to find errors
| statically where possible, and the runtime will check for the
| remaining type errors. In this way it's more sophisticated
| than almost all other dynamically typed languages!
| jackmott42 wrote:
| If you use C# then you can use Visual Studio or Rider or
| VSCode and get that
| [deleted]
| dandellion wrote:
| I went into Godot thinking I'd hate GDScript and switch to C#
| pretty fast because I already knew it. Now I love GDScript, if
| I ever need performance I'll probably just go straight for C++.
| talloaktrees wrote:
| I think this is correct... you can even go with Rust instead
| of C++
| MrLeap wrote:
| I didn't read anything that indicated a hard block to creating
| new methods that bypass the binding layer? All the layers are
| open source.
|
| 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.
| timmytokyo wrote:
| >Unity has spent the last five years working on speeding up their
| scripting with crazy projects such as building two custom
| compilers, SIMD maths libraries, custom collections and
| allocators, and of course the giant (and very much unfinished)
| ECS project. It's been their CTO's primary focus since 2018.
|
| 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.
| pests wrote:
| > the entire leadership of the ECS/DOTS team has resigned
|
| Recently because of the drama or unrelated? That's sad to hear
| as I was very excited on that effort.
| timmytokyo wrote:
| I don't think it was due to the recent drama. (Although who
| knows, maybe they knew what was coming.) Mike Acton and
| Andreas Fredriksson left back in March 2023 I think. They
| posted to twitter.
|
| EDIT: It was in May.
| zamalek wrote:
| This dictionary stuff is truly bizarre. I have been playing
| around with GDExtension and Rust - specifically the meshing
| interface. This dictionary stuff shows up there. Not only
| couldn't I figure out why (the GDScript angle makes sense in
| hindsight), but it also makes the API virtually impossible to
| discover: you have to resort to reading things up in the
| documentation.
|
| As much as I love Godot, the GDExtension interface really has no
| redeeming qualities and needs to go back to the drawing board.
| generichuman wrote:
| Response to the article from godot dev:
| https://reddit.com/r/godot/comments/16lti15/godot_is_not_the...
|
| TL;DR is that they know this & working on it
| lainga wrote:
| I might throw in a bit of gossip here - many who were following
| the development of GD 4 last year (myself included as I was
| using it :) ) thought it was kind of rushed out in time for GDC
| 2023 in March. And immediately after GDC, Godot 4.1 followed
| (and now rc's for 4.2), with lots of fixes.
|
| 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
| droptablemain wrote:
| I know Godot team is very committed to GDScript, but I find it
| hard to see it as anything but a toy scripting language. Seems
| like it would be a real mess with a big, complicated project.
|
| Godot w/ C# however is very nice and gives you a lot of
| flexibility with your architecture and code.
| dandellion wrote:
| They're commited to GDScript because it's a great scripting
| language. I started with Godot expecting to switch to C# pretty
| fast because I'm already familiar with C#, but I was pleasantly
| surprised with GDSCript. And I'm a programmer with more than 10
| years of experience. For people who are still learning it must
| feel like the difference between trying to learn to ride a
| bycicle vs learning to fly a boeing 777.
| mardifoufs wrote:
| Not being rhetorical or snarky, but what do you like about
| gdscript?
| krapp wrote:
| GDScript not a great scripting language. It's an adequate
| scripting language whose only benefit is native integration
| with the client, and guaranteed support in perpetuity. But
| there is nothing about it that's _better_ than any other
| scripting language. No one would choose to use GDScript as a
| general purpose programming language.
|
| 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#.
| dandellion wrote:
| I'd argue it's better than Boo and better than Blueprints.
| Maybe even JavaScript, because JS has made itself very
| useful as time has passed but as a small scripting language
| embedded in browsers it sucked.
|
| 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?
| gustavus wrote:
| > but I find it hard to see it as anything but a toy scripting
| language. Seems like it would be a real mess with a big,
|
| 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.
| eddythompson80 wrote:
| As others have mentioned, JavaScript also has had over 20
| years of serious investment from the best minds in the
| industry to improve it. We now have V8, TypeScript and
| plethora of tools that make writing serious applications
| possible or even preferable. I seriously would take
| TypeScript over most languages any day.
|
| How likely would you say the same effort is gonna go into
| GDScript?
| gustavus wrote:
| Well that's a point a lot of other people have raised and
| is the one I am trying to make, Godot and the associated
| ecosystem could become like the next generations
| Javascript. Companies didn't start investing an enormous
| amount of time and effort into improving JS because they
| wanted to, they did it because they adopted it and then ran
| into cases where they needed the performance.
|
| 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.
| krapp wrote:
| Javascript only got the investment it did because it was
| the only language that would run in a web browser, when
| the web suddenly became a billion dollar business and
| javascript developers were a dime a dozen. Godot is able
| to support multiple languages. The goal should be
| improving and expanding language support, not repeating
| the necessary evil of making Javascript the One True
| Programming Language.
| headcanon wrote:
| I too found it a bit cumbersome past a certain code size. A lot
| of games don't necessarily need a lot of raw or complex code to
| run though, so the 1st class benefits of GDScript start to
| shine, like the native debugger, autocomplete, Godot-specific
| accessor syntactic sugar.
|
| 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.
| dandellion wrote:
| It's probably not ideal for large projects, but it adds huge
| value for small ones, and for people who are learning, and
| I'd expect probably even in larger projects if combined with
| C++, C# or Rust. It's miles better than the joke Unity had
| that was called Boo. I also like it a lot better than
| Blueprints in Unreal while still remaining extremely simple,
| although I can see how Blueprints can be better for more
| visual people.
| Lucasoato wrote:
| They should remember that even Unity had to deprecate the Boo
| language to go forward :)
| mattigames wrote:
| Both Boo language and UnityScript were deprecated (the later
| was oftenly mislabeled as JavaScript, creating quite a
| confusion between newbies)
| dandellion wrote:
| Not sure Unity is a good role model...
|
| 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.
| eddythompson80 wrote:
| What's wrong with Unity from a technical prospective not
| marketing/business prospective?
| zerr wrote:
| How usable is Godot's native/C++ API for actual game programming,
| akin to Unreal? (never mind the hot reloading).
| badsectoracula wrote:
| TBH if i was making a game using Godot i'd just be modifying
| the engine itself to add any "heavy" functionality (the nodes
| system would most likely help here) and expose custom high
| level APIs to GDScript. IMO scripting languages should be used
| to script the behavior of a game: i.e. tell the engine what to
| do, not how to do it (which should be written in native code).
|
| 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.
| janosdebugs wrote:
| It's a lot clunkier than Unreal. You'll have to build a
| .so/.dll using scons or cmake (good luck finding a
| CMakeLists.txt that actually works) and you have to register
| all types manually. You will also not be able to work around
| the issues with the APIs mentioned in the article around
| dictionaries AFAIK. There is no header tool and no
| autogenerated code for your classes. Oh, and reloading the DLL
| on Windows requires an editor restart. Plus I haven't found a
| good way to debug load failures either apart from starting the
| editor from a console window.
|
| 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.
| rsstack wrote:
| Are you using call_deferred from your signal handlers?
| lainga wrote:
| I used GDExtension extensively on a previous project, and I
| ended up just installing the .so, launching Godot headless,
| and immediately exiting, as part of my build script. To catch
| anything that might break extension loading.
| Dudester230602 wrote:
| If Godot has a first-class C# support then why
| `Godot.Collections.Dictionary` exists when there is already
| `System.Collections.Generic.Dictionary`?
|
| https://learn.unity.com/tutorial/lists-and-dictionaries
| TazeTSchnitzel wrote:
| Bridging collection types between languages is never easy.
| Apple only manage it because they control the compiler and
| runtime on both sides, and that still comes with performance
| pitfalls. Allowing both to exist and telling people when to use
| one or the other is not only easier to implement, it has more
| predictable performance and gives the user more control.
| worble wrote:
| https://docs.godotengine.org/en/stable/tutorials/scripting/c...
|
| > 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.
| gabereiser wrote:
| Never underestimate the power of open source game developers. If
| we could do it with XNA, we'll do it with Unity. If we have to
| tear the place down and rebuild it on a rust il-compliant vm
| instead of mono, we damn sure will [0]
|
| [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.
| bakugo wrote:
| > That's right, our raycast is returning an untyped dictionary.
|
| 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?
| jay_kyburz wrote:
| There are red flags everywhere.
|
| 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.
| syntheweave wrote:
| Godot has always made a point of prioritizing features and
| simplicity of modification over speed. In a lot of instances
| it does just ignore low-hanging opportunities for performance
| because the simple thing works and needs less code, which
| isn't always useful, but means it's _easier to replace_.
|
| 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.
| Narishma wrote:
| Presumably because GDScript doesn't support structs.
| TazeTSchnitzel wrote:
| It does support classes with strongly typed fields, though,
| which are the next best thing. It's just a poorly designed
| API, it's not a reflection of language limitations.
| nextaccountic wrote:
| In this sense it's like Lua right? And people don't complain
| (much) about using Lua in gamedev
| TheMagicHorsey wrote:
| Curious if anyone here has tried Bevy (Rust game engine).
|
| 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.
| [deleted]
| MegaDeKay wrote:
| Bevy came up on /r/rust_gamedev a little while back. The
| general sentiment seemed fairly negative, with comments that
| you either do things Bevy's way or the highway.
|
| https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_be...
| Narishma wrote:
| Bevy is even more immature than Godot. It doesn't even have an
| editor.
| Daegalus wrote:
| I looked into this, but it seems most gamedev communities I
| asked, say Bevy isnt great, and everyone seems to be
| recommending Fyrox instead. No clue if it actually is, just
| parroting what I have been told.
|
| Either way, I don't think either is ready for prime time as its
| still early development.
| anothernewdude wrote:
| Sounds a lot like Unity to me.
| spookie wrote:
| I'm also concerned with the approach the dev is taking on their
| game. That's a lot of raycasts.
| hiccuphippo wrote:
| Yes, I was under the impression that Unity was also slow and
| people who use it don't particularly care because it's still
| fast enough for their purposes.
|
| But with so many eyes on Godot now, I can only see it getting
| better.
| debacle wrote:
| Unity just released first class support for ECS which will
| greatly speed up the engine for most users.
| bowsamic wrote:
| Not really. Unity has great performance
| [deleted]
| robertlagrant wrote:
| I'm not sure I understood everything here, but I think the tl;dr
| is that Godot has a powerful new rendering technique called
| "foreshadowing".
| xg15 wrote:
| _cue theatrical thunder and lightning_
| [deleted]
| CobrastanJorji wrote:
| It's new in Godot 4.1.1. When enabled, if two opaque polygons
| are between the user and a light source, the shading can
| reflect their relationship.
| panzagl wrote:
| That why it seems slow- if you want the gun to fire in act 2,
| you have to show it in act 1.
___________________________________________________________________
(page generated 2023-09-18 23:01 UTC)