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

The anatomy of a Godot API call

sampruden.github.io

Post reply on HN
Print view View original

141–150 of 195 posts

Re: The anatomy of a Godot API call

#141

Post by tacotacotaco »

trinovantes wrote: post #111
Rapzid wrote: post #101

Earlier quoted context omitted.

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…

That poll seems highly biased How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey

How many users that are happy with gdscript are taking time to read vote in a GitHub polling posted about c# issues?

Re: The anatomy of a Godot API call

#142

Post by tacotacotaco »

I am so glad that Juan et al are leading Godot and not me because frankly I would be offended by all of this. It hasn’t been a week since the Unity fiasco and all I see is post after post from people complaining that Godot isn’t c# enough. This is like showing up for dinner and insulting cooking before you’ve even tasted the meal. There are definitely opportunities to improve Godot but there are more constructive ways to contribute than drawing a new floor plan for the house on the table cloth while the first course is being served.

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#.

Re: The anatomy of a Godot API call

#143

Post by mnk47 »

jay_kyburz wrote: post #95
rybosworld wrote: post #57

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 fe…

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.

If you like or don't mind using Go, check out Ebiten as well. I think it's similar to Raylib in spirit, but it also supports Nintendo Switch, iOS and Xbox. IIRC it uses native graphics APIs (Metal for MacOS, DirectX for Windows) while Raylib just uses OpenGL.

Re: The anatomy of a Godot API call

#144

Post by fayten »

fidotron wrote: post #28

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 investmen…

I started evaluating Defold this past weekend and I have been very impressed.

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.

Re: The anatomy of a Godot API call

#145

Post by janosdebugs »

rsstack wrote: post #37
janosdebugs wrote: post #21

Earlier quoted context omitted.

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…

Are you using call_deferred from your signal handlers?

No. Should I?

Re: The anatomy of a Godot API call

#146

Post by janosdebugs »

headcanon wrote: post #87
droptablemain wrote: post #44

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.

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 pursu…

I concur. I believe GDScript should be split from Godot itself and support should be added for third party IDEs. It has a lot of hard-coded things specific to Godot in it and it suffers from it. The built-in code editor has a very confusing layout and its built-in code editing functions will never be as powerful as providing a language server to a dedicated IDE.

Re: The anatomy of a Godot API call

#147

Post by jms55 »

Narishma wrote: post #139
jms55 wrote: post #119

Earlier quoted context omitted.

As a Bevy dev - what platforms? We support Vulkan, DirectX12, Metal, WebGPU (with a bit more limited features), and WebGL2 and GLES 3 (with a decent amount more limited features and performance).

Older devices. GLES 2 and DX9 to 11 mainly.

I double checked, and our rendering library _does_ partially supports DX11, as well as Angle, which lets you run the GLES3 backend on top of Angle on top of GLES2/DX11. They tend to be fairly buggy and incomplete, though. Arguably only usable for simple 2D games.

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.

Re: The anatomy of a Godot API call

#148

Post by janosdebugs »

mardifoufs wrote: post #104
dandellion wrote: post #78

Earlier quoted context omitted.

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.

Not being rhetorical or snarky, but what do you like about gdscript?

Also not the parent, but: It's a very simple language. It looks like Python and behaves like TypeScript. It makes it easy for beginners to get into game development without having the visual overhead of a C++ or C#.

Re: The anatomy of a Godot API call

#149

Post by johnnyanmac »

dandellion wrote: post #69
neonsunset wrote: post #14

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 G…

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++.

>if I ever need performance I'll probably just go straight for C++.

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.

Re: The anatomy of a Godot API call

#150

Post by johnnyanmac »

Rapzid wrote: post #126
Nition wrote: post #123

Earlier quoted context omitted.

There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most of the asset store. As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.

Easily room for both though. 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.

From what I'm reading here and elsewhere, we'd need to do some fundamental mucking into the c++ layer as well, given some data oriented hostile practices.

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!)

Post reply on HN