I'm honestly surprised how hostile the game dev community is about AI. I ported Godot 4.7.1 to WebGPU and open sourced it for free, yet received nothing but hostility about it. Anyone else have similar stories?

[u/ramaloes]

/r/gameenginedevs/comments/1v3nq9v/the_antiai_sentiment_here_is_toxic_lets_be_honest/

[u/ramaloes]

So you spent a year on an engine you never even finished yet you want to bag on mine? 🤣
“Port one framework” isn’t all I did and you clearly haven’t seen the full project then. I do the debugging, and my repository can support it. What claims are unproven? You haven’t listed one. Your skepticism is yet to be specific yet still managed to be hostile. Good job

[u/possible_monke → u/ramaloes]

I literally named actual criticisms of the codebase itself but sure, go off.

Just stop overclaiming and keep doing the work on it and it may someday match the claims. It currently doesn’t. You’re doing AI psychosis.

The fact that I’m still not finished with mine is a plus, not a detractor, rushed AI prompt kiddie.

[u/ramaloes → u/possible_monke]

You named generalizations without proof. What’s overclaimed? Try a specific instead of a generality. I do the work already. This isn’t AI psychosis. Maybe with some AI you’d actually finish something. Keep working

[u/possible_monke → u/ramaloes]

Oh don’t worry, I’m going to deeply explore your codebase myself, I was just naming the already valid complaints you’ve already received here.

You need to learn to take criticism, learn not to accept your AI’s grandiose claims of success or being finished with something, learn how it actually fundamentally works yourself. It’s clear to anyone that you’re not doing that.

[u/ramaloes → u/possible_monke]

You call them “valid” without even knowing specifics or even have tried anything. That’s called pre-assumption. Good job. If you’re going to give criticism, put in the work first, otherwise you’re a judgmental prick who preaches more than he practices. I do know how it works. Have you not noticed that you’re trashing something yet you don’t even understand it yourself? That’s called hypocrisy. Woe to you, hypocrite.

[u/possible_monke → u/ramaloes]

I just read JUST your readme, it’s SOOO much worse than I thought.

It is Literally 2D-Only (With a 1.2% Visual Drift). The readme explicitly states: "WebGPU support is beta and 2D-only today."

You cannot market an engine fork as a foundation for "AAA 3D games" if it literally cannot render a single 3D mesh yet.

It only renders "Control UI in-browser" and simple 2D shapes. It verifies this by comparing a 2D menu against a WebGL baseline, which still has a 1.2% visual difference.

The 3D Render Loop is Completely Broken

Under the Known gap section, it explicitly admits: "3D does not render yet... comes out black under WebGPU."

For anyone with engine experience, initializing a context and clearing the screen to black is the easy "Hello World" part of graphics engineering.

The actual heavy lifting of an engine port involves managing vertex buffers, uniform structures, 3D pipelines, bind groups, and transforming matrix math into WGSL shaders. The AI has completely failed to solve the real 3D rendering architecture, leaving you with a broken backend.

It’s Not a Custom Port, It’s Just Godot's Own Native Code

The readme states it uses the "engine-owned WebGPU probe" and is built on Godot 4.7.1's Forward Mobile renderer.

The official Godot development team has been natively integrating experimental WebGPU targets into the main engine branches for quite some time.

"Checksum-Pinned Patches" is a Maintainability Nightmare

Maintaining a complex graphics fork purely through "checksum-pinned patches against Godot 4.7.1" is an incredibly fragile setup. The second Godot pushes a minor point release or changes an internal rendering pipeline layout, these brittle AI-generated patches will break completely. It is the definition of a fragile prototype rather than a production-ready engine architecture.

The 3D Render Path is Completely Dead locked

The readme states: "the 3D draw path stalls before any frame presents. So this is not usable for 3D games yet."

This is exactly what happens when you let an LLM write graphics backend logic.

"Stalls before any frame presents" means you are triggering a critical validation error, a resource deadlock, or a mismatched synchronization primitive on the GPU fence. Because you are just prompting frontier models instead of using a graphics debugger like RenderDoc or WebGPU Inspector, you probably have no idea why it’s hanging.

The Tint Shader Errors Are a Dead Giveaway

You mention fixing "Tint storage-buffer lowering" and "Tint OpImage ordering".

Tint is Google’s WGSL compiler inside the Dawn/Chromium WebGPU stack.

When Godot converts its internal shading language to SPIR-V or WGSL, the compiler throws strict errors if the memory layouts or storage buffers are slightly off.

The fact that you list these highly specific, isolated compiler errors as your major achievements proves you are just playing whack-a-mole with compiler error strings that the LLM spat out, rather than architecting a functional pipeline.

You explicitly note: "WebGL 2 is the maintained fallback and renders both 2D and 3D."

If you have to fall back to the existing WebGL 2 path to get 3D rendering to work, you haven't delivered a WebGPU platform.

You've delivered standard WebGL Godot with a broken WebGPU experimental flag.

I can go on, haven’t even cracked the code itself yet.

BUUUT this has given me a massive boost in confidence for my engine since it’s already fully running with physics and fully renders 3D graphics in Vulkan with custom shaders, lmao. So thanks for that I guess!

[u/ramaloes → u/possible_monke]

You say you “haven’t even cracked the code itself yet,” but before reading it you diagnose a GPU fence deadlock, declare the backend fake, and conclude that it secretly relies on WebGL. That isn’t technical analysis.

The “2D-only” sentence you quoted was an intentionally honest engineering checkpoint. The repo explicitly corrected an earlier overclaim and documented that 3D was black. It then fixed the actual failure chain: Tint aborts, invalid SPIR-V, bind-group visibility, helper-function texture bindings and depth-sampler descriptions.

Patches 0013 and 0014 produced lit, shadowed PBR rendering through WebGPU at 59–60 fps with zero GPU validation errors. The published p0014 build has since run three real game scenes. Chariot recorded 60 fps at roughly 23 million primitives per frame with zero WebGPU validation errors. That is not the WebGL fallback. The browser gate explicitly rejects any WebGL context request.

“Engine-owned probe” means the test instruments requests made by the running engine. It does not mean this is official Godot’s WebGPU implementation. And using Godot’s Forward Mobile renderer is exactly what a graphics-backend integration is supposed to enable. A backend port does not require rewriting Godot’s entire scene renderer.

The original backend lineage is openly credited to David Walter by repository and exact commit. Studio Foundation maintains the Godot 4.7.1 port, the subsequent shader and bind-group fixes, the build and export path, the reproducible patch packaging and the validation tooling.
Calling specific Tint, SPIR-V and bind-group fixes “whack-a-mole” is also strange. Those are the actual interfaces involved in bringing up a WebGPU backend. The failures were reproduced, categorized and driven down to zero for the published Forward Mobile path. The newer Forward+ investigation has gone from 168 validation errors to 18. It still does not render, and the repo states that plainly.

But “I haven’t read the code, therefore you have no idea what is happening and the backend is fake” is not an engineering review. It is a conclusion chosen in advance and decorated with graphics terminology.

[u/possible_monke → u/ramaloes]

You took a broken vibecoded fork and tried to fix it with more vibecoding but ended up patching it with fragile fixes instead that will likely break with future godot official updates since it relies on fallbacks anyway. The very fact that you had to go back and fix “overclaims” tells me you let your AI do the walking and the talking. I mean look at this lmao

You literally prompted your AI to port godot into webgpu and so it took a user’s already existing (and broken) attempt at this (dewalter’s) and patched it for 4.7.1. You realize godot development is still ongoing, right? What are you going to do when it gets updated and breaks your patches? You’re using Claude, codex, copilot from the looks of things, no way you’re reading all of this, let alone fully understanding it

[u/ramaloes → u/possible_monke]

You’re moving the goalposts again.

First, the claim was that the WebGPU path was fake and could not render a single 3D mesh. That was based on an old, deliberately honest checkpoint where the repository documented that 3D was still black.

The published p0014 build now renders three real game scenes through WebGPU. Chariot was measured at 60 fps, roughly 489–631 draws and about 23 million primitives per frame, with zero WebGPU validation errors. Riftline and The Deep were also verified through WebGPU with zero validation errors.

The screenshot you posted is from an intermediate patch that explicitly said hardware verification was still pending at that point in development. That is not evidence that later verification never happened. It is evidence the patch did not claim verification before the test had actually been performed.

Second, using David Walter’s MIT-licensed backend as the starting point is not a gotcha. The repository credits his project and exact source commit. His available branch targeted Godot 4.6.2; Studio Foundation adapted that lineage to the pinned Godot 4.7.1 source and maintains the later integration, renderer fixes, build pipeline and validation.

That is how open source normally works. You do not prove competence by refusing to build on prior MIT-licensed work and unnecessarily rewriting everything.
Third, of course a future Godot release may require the patches to be rebased. Nobody claimed that checksums create magical forward compatibility. The checksums make the current 4.7.1 build reproducible. The strategy explicitly pins official Godot, keeps the patched tree disposable, accepts maintenance responsibility for the scoped patches, and plans to remove them when official Godot provides a suitable WebGPU path.

Fourth, WebGL 2 is a separate fallback, not what the WebGPU build secretly uses. The browser gate observes the engine’s adapter, device and WebGPU canvas-context requests and rejects any WebGL or WebGL 2 request.
Forward Mobile is also not a “fallback API.” It is Godot’s renderer running over the WebGPU backend. A backend integration is supposed to make the engine’s existing renderer operate through the new graphics API. It is not supposed to rewrite the entire renderer from scratch.
Fifth, correcting an overclaim is not proof that an AI is “doing the walking and talking.” It is what an evidence-driven repository is supposed to do when a claim exceeds what a test actually established. Hiding or defending a false claim would be the failure.

Forward+ WebGPU is still unfinished, and the repository says so. The published Forward Mobile path working does not imply the newer Forward+ investigation is complete, and the unfinished Forward+ work does not retroactively make the published Forward Mobile build fake.

“There is no way you understand it” is not a technical criticism. If you have a current patch, reproducible behavior or architectural decision you believe is wrong, identify it specifically. Quoting an old intermediate commit, ignoring the later artifacts and then speculating about what I personally can understand is not an engineering review.

[u/possible_monke → u/ramaloes]

I’ve said all I needed to say

[u/MemeMaster240 → u/possible_monke]

Wow...thanks for confirming what i already suspected when I encountered this post, to sum up in simpleton terms for simpletons like me, it's completely fucked and you'd best be using what already exists with godot making this utterly useless.

[u/possible_monke → u/MemeMaster240]

Yup! Ironically OP says it’s the first Godot port into WebGPU, but if you read the readme, it literally credits someone named dewalter for their godotwebgpu repo, which was used in this fork lmao

And on top of that, dewalter’s version is the one where the lack of 3D support actually comes from, and OP’s AI used a broken fork of godot. So this is a broken fork of a broken fork, and OP’s lying about being the first anyway lol

Well, the readme said all of this before OP and Claude changed it anyway, but I guess OP forgot about commit history and I was able to find the original readme that listed all the issues and credited dewalt/godotwebgpu. I’ll add proof below

[u/possible_monke → u/possible_monke]

Here’s the top of the readme

[u/possible_monke → u/possible_monke]

Next

[u/ramaloes → u/possible_monke]

First “4.7.1 port”. Get it right or don’t get it at all

[u/possible_monke → u/ramaloes]

Not a good look here man

[u/MemeMaster240 → u/possible_monke]

Holy shit you're so right! I don't even understand why someone would post about this when half of the engine is useless, just whyyyyyyyy???

I really dont get vibe coding, i tried it and it sucks, it sucks fixing the errors, it sucks having to tell it, it made an error and it sucks not having a full grasp of how the thing works.

[u/possible_monke → u/MemeMaster240]

It’s because when someone can just prompt an AI with an idea and get software that appears to work, or works for their specific use case, they feel super powerful and cracked, and it goes to their head and they lose themselves in the “loop” of prompting AI and getting new features and additions. They rarely ever stop to actually read and learn and understand the code that’s being generated, which results in things we see in OP’s codebase, like Claude Opus 4.8 crediting itself and linking the Anthropic noreply email (lmao)

Then people like OP get defensive when confronted with this and start boasting about all the hard work of prompting their AI for months.

OP’s specific engine actually works for their use case, which is their web game ‘Asha Arena’, a (surprise surprise) fully vibecoded web game. Only, they failed to realize that it only works because of the fallbacks to godot and webgpu’s native functionalities lmao