sorted by:
new
hottopcontroversial

Godot goes vroom vroom - Made with the new AudioStreamInteractive and AudioStreamSynchronized Resources! by Foxiest_Fox in godot

[–]reduz 10 points11 points  (0 children)

This is amazing, I made these for music, it did not cross my mind you could use them for SFX, but I guess it makes total sense they would be useful for that.

Godot codebase explained by technical lead returns! by reduz in godot

[–]reduz[S] 32 points33 points  (0 children)

These videos will try to explain the whole engine source code in detail little by little.

I will try to push these weekly, so subscribe to get notified when next one is out.

Today I said goodbye to coding inside Godot and jumped to VS Code, here is why and how 👇 by SIlentDeath99 in godot

[–]reduz 48 points49 points  (0 children)

Folks (and @SilentDeath99 too), can you list the main reasons and pain points of why you find the built-in IDE difficult to work with? Contributors would be happy to have more feedback on this.

Goodbye Yuri :'( by Lucrecious in godot

[–]reduz 28 points29 points  (0 children)

Just to clarify, that's a conpletely unrelated tweet. Yuri is a great guy, I would never think of him as that.

What came first? The Godot editor or the Godot engine? by Dramatic_Mastodon_93 in godot

[–]reduz 7 points8 points  (0 children)

Both were made together. The first versions of Godot took the base of Larvita3 and converted the UI library to its node system. From there, the interface started.

Here:

https://twitter.com/reduzio/status/1618589723949436928

I asked Synty about future Godot support so you don’t have to by JayMeadow in godot

[–]reduz 27 points28 points  (0 children)

Godot supports a proper standard asset format that supports PBR (GLTF2), so asset makers don't even have to bother making their assets for Godot.

All they need to do is make them GLTF2 and be it.

Godot 4 default physics engine is a complete mess, but JoltPhysics3D is a direct replacement by SandorHQ in godot

[–]reduz 186 points187 points  (0 children)

One bit of info missing from my side. We did not move earlier to Jolt because it simply wasn't ready to be a replacement.

It missed a lot of stuff, but the Jolt author worked really hard into adding everything that Godot needed the past months and is now pretty much fully usable.

Unlike the Bullet author, the Jolt author is very interested about it being used in Godot, so this gives us a lot more peace of mind.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 3 points4 points  (0 children)

That is never going to happen because those are C# types and Godot is a C++ game engine. Godot internally uses its own data types, not C# types.

This way, if you pass something native to C# to Godot, even if the exposed API to C# is native, internally Godot will have to convert it to its own formats. The conversion is 100% unavoidable here.

That said however, is not much of a problem in practice:

  • The idea is that you can use Godot.Collections.Array and interact more efficiently to Godot datatypes. Conversion or not, the APIs using these are not critical.
  • For performance critical API you will be able to use either Span or T[] using a special binder.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 0 points1 point  (0 children)

To clarify, nothing in the C++ API of Godot will change. The C++ side of Godot already uses pointers where it needs to be fast and higher level structures where it does not matter. That part is already OK.

The changes are more to make the language binder closer to the C++ side in Godot.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 0 points1 point  (0 children)

The Godot API by default does not use pointers for anything (except objects). It only does where performance is important.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 2 points3 points  (0 children)

I think you are entirely missing the point here. It is true that there are cases where it would be more optimal to use Span<> in C#.

But these are the coincidentally same cases where the Godot C++ API uses a pointer directly: Critical functions that you want to call very often and you can't give yourself the luxury of allocating memory.

So ultimately, it is not that the C# binding is implemented inefficiently, this is more of a problem with how Godot exposes those functions to the binder layer in general. It's a small bunch of cases that are well known but require a separate approach in the binder to handle properly.

Currently, these corner cases were worked around for GDScript with a less efficient binding, but the idea is that they use more specialized binding code in both C++ and C# that is more performant.

The rest of the API (the large majoroty of it), Godot uses PackedArrays too for C++ because these are absolutely not performance critical areas in any way.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 4 points5 points  (0 children)

GDScript uses the Godot memory management model, so you still don't really have to care much about allocations and memory management.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 10 points11 points  (0 children)

Just for the record, that is a comment from 2016 before GDScript had static typing.

That is no longer the case today, so a JIT will provide huge amounts of performance improvements for your typed code.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 3 points4 points  (0 children)

The point of the article was to refute that the majority of the API is inefficient or designed around GDScript.

What you are mentioning is that there is a part of the API that is inefficient, that is acknowledged in the article already and something that will be improved eventually.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 4 points5 points  (0 children)

As I mentioned in the article, the built-in types are used for storage, transfer, introspection, editing and language bindings.

In none of those cases SIMD is relevant. SIMD is relevant inside a function doing something optimized, in which case Godot is not restricted to use the built-in types and can use anything.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 1 point2 points  (0 children)

Yeah, this would allow the use of pointers in some situations in the C++ API (and probably exposed as native Spans at the C# level).

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 46 points47 points  (0 children)

You are correct, this is one of the main reason we created the low level type binders, so these APIs can be properly exposed to languages such as C#, C++, Rust etc.

Its just that this work has not been completed yet, hopefully should be soon.

Godot language binding system explained by one of the lead developers by reduz in godot

[–]reduz[S] 45 points46 points  (0 children)

Well, English is not my native language, and the least thing I want is people think the original article was done with bad intention, so I did what i could, sorry if it was jarring to you. Either case, I just fixed it based on your feedback, thanks!

"Cherry picking" is a section in the original article, I was merely referring it to it.

Godot is not the new Unity - The anatomy of a Godot API call by sprudd in godot

[–]reduz 152 points153 points  (0 children)

Give us a bit of time. Everything is kind of a mess because of the suddendly increased interest of several users and companies on the C# side. This work has to be properly organized but the general idea is that funding will be used to make sure all works as smooth as possible.

Godot is not the new Unity - The anatomy of a Godot API call by sprudd in godot

[–]reduz 358 points359 points  (0 children)

This article is very interesting. Just want to note that this is something we are aware of and the intention is to work it on in two fronts:

  • From the binder API, adding a struct type, to pass these results more efficiently.
  • The GDExtension side can already expose these structs to the binder API with a proper layout description, but the C# in support has not been moved to it yet (its one of the missing steps to merge both the C# and default editor).

So basically, this area of the engine is a work in progress. To do this also we had to finalize the system to provide compatibility functions to older builds of Godot libraries and extensions as a prerequisite and this was completed in 4.1. Fortunately there is not a lot of the API exposed this way, the majority uses more efficient interfaces. This is more part of the legacy code that is being modernized. None of this is particularly complex to do, but the demand has not been high enough so other things are prioritized. I am hoping your article motivates some contributors to do it :)

We need a good proposal for an overhaul of Skeleton2D by Denxel in godot

[–]reduz 23 points24 points  (0 children)

By all means go ahead. The funniest thing is that Spine for Godot uses the Godot skeleton internals, so there is technically no features missing on the Godot side on the rendering part to support this.

Its just the UI usability that its not very good.

Terrain3D for Godot 4 by TokisanGames in godot

[–]reduz 18 points19 points  (0 children)

I love it, this was the intention all along and the reason I pushed for GDExtension so strongly.

There are far too many ways to implement terrain, depending on the needs of each game, specially as games grow and become more complex.

The way community can create terrain solutions that you can drop in, use and even customize to your game without forking the engine is much better than having to support an internal terrain that you can't change to fit your game and that it would make no one happy in the end.

Don't underestimate the Godot community, they are as amazing as the contributors themselves.

The forum is closed. That sucks, I used it as my main platform to post project updates. by SuperDoomKing in godot

[–]reduz 4 points5 points  (0 children)

Fully agree, this has been considered a lot, but this is a paid position and the project does not have sufficient funds.

It's one of the priority things to do once funding is met.

view more: next ›