EOeole666·Dec 28, 2025
Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125
In Unity's Mono problem: C# code runs slower than it shouldgodotengine
godot
C++2014–2026
godotengine / godot
godot
Godot Engine – Multi-platform 2D and 3D game engine
100Distinct people
116Mentions
1Explicit recommenders
120.1KGitHub stars
What to know before exploring
What it is
Godot Engine – Multi-platform 2D and 3D game engine
GitHub
Where it is used
- Material Maker — Material Maker uses Godot to build its open-source application for creating materials and textures. It is a shipped app showcased by the Godot project. Source
- Cassette Beasts — Cassette Beasts uses the Godot Engine as the game’s engine. The developers describe choosing and settling on Godot for the project. Source
What people are saying
I've been building a game part-time in Godot[0] and I contribute to the code on occasion. For the most part it has been a pleasant experience[1]. It currently does not have the…
cart_cart used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- atomicgameengine/atomicgameengine · linked in 2 of the same discussions
- gdzig/gdzig · linked in 2 of the same discussions
- godotengine/godot-proposals · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:01:32 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year116 dated mentions
Observed mentions: 2014-02-10 05:36:11 UTC to 2026-07-23 17:08:42 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 18 | 2 | 16 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 12 | 2 | 10 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 14 | 3 | 11 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 11 | 1 | 10 |
What Hacker News says
14 sources> extracted via reflection
I think you are talking about dispatch of virtual methods, which is still a thing, but the performance cost can be somewhat mitigated.
the names of the methods are interned strings (called `StringName`). a naive implementation will allocate the `StringName`, but you can avoid the allocation with a static lifetime string. we expose a helper for comptime strings in Zig[0].
then, extension classes need to provide callback(s)[1] on registration that lookup and call the virtual methods. as far as I know, the lookup happens once, and the engine stores the function pointer, but I haven't confirmed this yet. it would be unfortunate if not.
at least right now in GDZig, though this might change, we use Zig comptime to generate a unique function pointer for every virtual function on a class[2]. this implementation was by t
Read the rest
he original `godot-zig` author (we are a fork). in theory we could inline the underlying function here with `@call(.always_inline)` and avoid an extra layer indirection, among other optimizations. it is an area I am still figuring out the best approach for
virtual methods are only ever necessary when interfacing with the editor, GDScript, or other extensions. don't pay the cost of a virtual method when you can just use a plain method call without the overhead.
[0]: https://gdzig.github.io/gdzig/#gdzig.builtin.string_name.Str...
[1]: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d...
[2]: https://github.com/gdzig/gdzig/blob/5abe02aa046162d31ed5c52f...
My understanding may be out of date, but the C# support was created before GDExtension existed. The team has been working hard on porting it over to GDExtension. Once they are done, it should be much more performant, and they will finally be able to ship only one version of the editor. I believe the original C# bindings do a lot of unnecessary marshaling at the ABI.
With GDExtension, the core builtin types like `Vector3` are passed by value. Avoid unnecessarily wrapping them in Variant, a specialized tagged union, where you can. You can see the documentation here; you have direct access to the float fields: https://gdzig.github.io/gdzig/#gdzig.builtin.vector3.Vector3
Engine objects are passed around as opaque pointers into engine managed memory. The memory for your custom types is managed by you. You allocate the engine object and essenti
Read the rest
ally attach userdata to it, tagged with a unique token provided to your extension. You can see the header functions that manage this: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d...
But, this is how the lifetimes for the objects gets slightly hairy (for us, the people creating the language bindings). Our goal with the Zig bindings is to make the allocations and lifetimes extremely obvious, a la Zig's philosophy of "No hidden memory allocations". It is proving somewhat challenging, but I think we can get there.
There's still a lot of surprising or unintuitive allocations that can happen when calling into Godot, but we hope to expose those. My current idea is to accept a `GodotAllocator` on those functions (and do nothing with it; just use it to signal the allocation). You can read the code for the `GodotAllocator` implementation: https://github.com/gdzig/gdzig/blob/master/gdzig/heap.zig#L8...
If we succeed, I think Zig can become the best language to write highly performant Godot extensions in.
VisionOS Godot Engine support merged
I noticed that Godot Engine Apple Vision OS support is merged today. <3
https://github.com/godotengine/godot/pull/105628
1 points · Open discussionIf you are talking about this link [0], the person answering is from the Godot team and not Apple.
[0] https://github.com/godotengine/godot/pull/105628#issuecommen...
In Native visionOS platform supportJeez, some people are just insufferable
I'm glad some people like https://github.com/godotengine/godot/pull/105628#issuecommen... exists
"why this is not an extension" sounds like an awfully naive question. I'm not a Godot expert but I'd bet a very large amount of money that this is not in the realm of a simple extension, as flexible as Godot can be (and a check of the PR seems to confirm this)
In Native visionOS platform supportCorrect... But from my understanding... OpenXR isnt reliant on OpenGL? it supports Vulkan, DirectX and metal -- https://github.com/godotengine/godot/pull/98872
In Native visionOS platform supportMaintainers have to review the PR, answer Apple's "Open Questions", and support their users who want to build with the new functionality long term.
Laughably, it looks like the PR didn't even compile...[1]
> When you try and bundle, it will fail. The library paths are incorrect.
[1]: https://github.com/godotengine/godot/pull/105628#pullrequest...
In Native visionOS platform supportNative visionOS platform support
374 points · Open discussionNative VisionOS Platform Support
6 points · Open discussionI don’t think the support depends on distros much, I think the main variable is hardware. If you have a desktop PC bought in the last ~5 years the support should be OK, for the hardware older than that the support is not guaranteed. GeForce GT 730 (launched in 2014) doesn’t support Vulkan, Intel only supports Vulkan on Windows starting from Skylake launched in 2015.
Then there’re quality issues. If you search internets for “Windows Vulkan issue” you’ll find many end users with crashing games, game developers with crashing game engines https://github.com/godotengine/godot/issues/100807 recommendations to update drivers or disable some Vulkan layers in registry, etc.
On Windows, Vulkan is simply not as reliable as D3D. The reasons include market share, D3D being a requirement to render the desktop, D3D runtime being a part of the OS support
Read the rest
ed by Microsoft (Vulkan relies solely on GPU vendors), and D3D being older (first version of VK spec released in 2016, D3D11 is from 2009).
Another thing, on Linux, the situation with Vulkan support is less than ideal for mobile and embedded systems. Some embedded ARM SoCs only support GLES 3.1 (which BTW is not too far from D3D 11.0 feature-wise) but not Vulkan.
I personally find Go miles easier than Rust.
Is this the ultimate reason,Go is fast enough without being overally difficult. I'm humbly open to being wrong.
While I'm here, any reason Microsoft isn't sponsoring a solid open source game engine.
Even a bit of support for Godot's C#( help them get it working on web), would be great.
Even better would be a full C# engine with support for web assembly.
https://github.com/godotengine/godot/issues/70796
In A 10x Faster TypeScriptGreat updates! Specifically .NET 8 as well as Typed Dictionaries with GDScript.
Really hoping we see web export for C# soon. https://github.com/godotengine/godot/issues/70796
In Godot 4.4Oh, I was reminded of this chore we had to do years ago.
https://github.com/godotengine/godot/blob/master/LICENSE.txt
> Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md).
Godot Engine did `2014-present` and stopped updating the license years every year.
In Say Goodbye to Outdated Footer Years, Forever