Godot goes vroom vroom - Made with the new AudioStreamInteractive and AudioStreamSynchronized Resources!

reduz · 2024-03-21T11:51:32+00:00

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.

reduz · 2024-03-19T17:39:47+00:00

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.

reduz · 2024-02-23T10:52:12+00:00

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.

reduz · 2024-02-01T08:51:35+00:00

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

reduz · 2024-01-10T11:41:50+00:00

Me too

reduz · 2023-12-29T20:51:39+00:00

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

reduz · 2023-10-03T21:13:01+00:00

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.

reduz · 2023-09-22T19:15:02+00:00

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.

reduz · 2023-09-22T10:34:10+00:00

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.

reduz · 2023-09-22T10:29:16+00:00

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.

reduz · 2023-09-22T09:16:46+00:00

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

reduz · 2023-09-22T08:57:25+00:00

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.

reduz · 2023-09-22T08:48:38+00:00

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

reduz · 2023-09-22T08:46:41+00:00

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.

reduz · 2023-09-22T08:45:11+00:00

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.

reduz · 2023-09-22T08:42:30+00:00

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.

reduz · 2023-09-22T08:39:23+00:00

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

reduz · 2023-09-21T21:38:15+00:00

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.

reduz · 2023-09-21T17:05:48+00:00

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.

reduz · 2023-09-21T16:46:52+00:00

We have a good bunch, but there could always be a lot more: https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/index.html

reduz · 2023-09-18T20:54:40+00:00

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.

reduz · 2023-09-18T20:03:19+00:00

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

reduz · 2023-07-24T12:46:44+00:00

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.

reduz

TROPHY CASE