godotengine

🎮 Godot｜做出你的第一款游戏 ① 2D/3D一体化编辑器 ② 场景＋节点，复用角色与关卡 ③ 跨平台导出；MIT许可 学习：下载编辑器→跟做“首个2D游戏”→改敌人速度与计分。 需编程基础；先2D再3D。 godotengine/godot 图：Godot社区文档演示截帧，CC BY 3.0 docs.godotengine.org t.co

Godot doesn't use interaural time differences for its 3D audio, and I think it should! The TLDR is: Godot 3D audio sounds like this, but I think it should sound like this &nbsp; --- Recently I made a really simple horror game as a little October challenge for myself, and I was struggling with getting the 3D audio to sound right. I tried out 2 different community-made raytraced-audio plugins before realizing that neither the default AudioStreamPlayer3D node, or either of the plugins I tried, added any kind of interaural time differences to the spacial audio, which really surprised me. I already opened a discussion on the godot-proposals repo about this, but I also wanted to post about it here, since my experience with the spacial audio plugins makes me think this may be an under-appreciated topic. My full discussion post: &nbsp; --- From Wikipedia: _The interaural time difference (or ITD) when concerning humans or animals, is the difference in arrival time of a sound between two ears. It is important in the localization of sounds, as it provides a cue to the direction or angle of the sound source from the head. If a signal arrives at the head from one side, the signal has further to travel to reach the far ear than the near ear. This pathlength difference results in a time difference between the sound's arrivals at the ears, which is detected and aids the process of identifying the direction of sound source._ &nbsp; Currently, Godot's AudioStreamPlayer3D and AudioListener3D use only panning to clue you in to what direction a sound is coming from, which creates a very weak illusion of spacial direction for 3D audio. However, interaural time differences are much more important for creating the illusion of 3d audio, and Godot doesn't provide a built-in way to create that effect. &nbsp; I whipped up 3 demo samples in Audacity to showcase this: - Water droplet panned 40% to the left. - Water droplet panned 40% to the left AND the left channel plays slightly sooner than the right. - Water droplet panned 40% to the left AND the right channel plays slightly sooner than the left. The first example mimics what Godot already does if an AudioStreamPlayer3D if far to your left. To my ears, it sounds like the drop is coming from the center of my head, just slightly to the left. The second example is what I'm asking to be added. To my ears, it sounds like the drop is coming from the far left, providing a much stronger spatial effect than the first. The third example is just here to showcase the difference in "feel" between the panning effect and the interaural effect (the sound is panned to the left, but the right plays first). To my ears, it sounds like the sound is coming slightly from my right, but with something obstructing the sound. _(This is also what it sounds like currently when you use a stereo audio sample with an AudioStreamPlayer3D node, and the directionality of the sample conflicts with the direction of the audio in-game)_ &nbsp; This issue can be overcome through the use of custom scripts, plus separate audio buses and AudioEffectDelays for each AudioStreamPlayer3D. Here's a small partial snippet from a recent project of mine that added this effect in a simplified way: var interaural_delay_effect: AudioEffectDelay # ... ## Update the interaural_delay_effect with the current delays for each ear. ## Note that this implementation always pins the closer ear to 0.0 milliseconds of delay, ## but a physically accurate effect should actually just apply the full delay to each ear. func _update_interaural(listener: AudioListener3D) -> void: const SPEED_OF_SOUND: float = 340.29 const SOUND_SECONDS_PER_METER: float = 1.0 / SPEED_OF_SOUND const SOUND_MS_PER_METER: float = SOUND_SECONDS_PER_METER * 1000 var relative_sound_pos: Vector3 = listener.to_local(global_position) var left_ear_travel_time: float = Vector3(-0.1075, 0, 0).distance_to(relative_sound_pos) * SOUND_MS_PER_METER var right_ear_travel_time: float = Vector3(0.1075, 0, 0).distance_to(relative_sound_pos) * SOUND_MS_PER_METER if left_ear_travel_time < right_ear_travel_time: # Right ear delay is longer, remove left delay, add delay to right. interaural_delay_effect.tap1_delay_ms = 0.0 interaural_delay_effect.tap2_delay_ms = right_ear_travel_time - left_ear_travel_time else: # Left ear delay is longer, remove right delay, add delay to left. interaural_delay_effect.tap2_delay_ms = 0.0 interaural_delay_effect.tap1_delay_ms = left_ear_travel_time - right_ear_travel_time &nbsp; However, I personally think this should be added directly into Godot's built-in 3D audio nodes, because this is the minimum requirement for audio to actually sound 3D, and I think that most users of the AudioStreamPlayer3D and AudioListener3D nodes would be hoping to achieve this kind of directional effect. I'm suggesting this being added as an option just for compatibility reasons, but I don't think the average user would actually want this option disabled. EDIT: Just a quick note because I realized a potential issue with understanding my examples; if you have "spacial sound for headphones" (or whatever it's called on your device) turned on, you'll have to turn it off to properly hear the difference between the examples, because that filter essentially operates by trying to guess at the effect I'm describing :)

Wow! I never thought I'd make my own game, let alone find a bug in the @godotengine 🤯 On Android, after ~600 mouse clicks the game stopped responding to input. Diagnosed, worked around and reported 👇 #GodotEngine #gamedev godot#124965

Godotのクォータニオンの正規化にIEEE-754を見出した話 正規化メソッドを見てみる ベクトルの計算でもおなじみの正規化ですがクォータニオンはコンストラクタを実行するときは大体やっております。 ここは前回取り上げました。 zenn.dev 今回はこちらのクォータニオンの正規化メソッドについてみていきたいと思います。 なお、私は数学がわからないため、あまりそこは深堀せずに見ていきます。 Godot Engineのバージョンは4.8.0 devです。 core\math\quaternion.cpp void Quaternion::normalize() { #ifdef MATH_CHECKS // 有限数であるかをデバッグ時に推測する。 if (!is_finite()) { WARN_PRINT("Quaternion cannot be normalized, the elements should be finite."); } #endif // MATH_CHECKS *this /= length(); } 内積とそれを元にした長さを図るメソッドも実装されております。 計算式の実装 正規化がやっていることは普通に計算なので当然、計算式をチェックしておく必要があります。以下は先に出てきた割り算です。 core/math/quaternion.h constexpr Quaternion Quaternion::operator/(real_t p_s) const { return *this * (1 / p_s); } その実態は掛け算となっており掛け算はこのようになっております。 core/math/quaternion.h constexpr Quaternion Quaternion::operator*(real_t p_s) const { return Quaternion(x * p_s, y * p_s, z * p_s, w * p_s); // 普通に掛け算、合成につながるけど } このように一回の除算で求めた (1 / p_s) の値のことを逆数といい、これを掛ける方式で求めれば単純に高速化が期待できます。 コンパイラのオプションを使って最適化しようとしないの？という疑問が湧きますが以下はマイクロソフトのドキュメントです。 learn.microsoft.com 以下のように書かれております。 注目点はこちらの引用 作成する浮動小数点コードが、浮動小数点ステートメントでの演算や式の順序に依存していない場合 (たとえば、a * b + a * c が (b + c) * a として、または 2 * a が a + a として計算されるかどうかを気にしない場合) は、より高速で効率的なコードを生成できる /fp:fast オプションを検討します。 作成するコードが、演算と式の順序に依存し、かつ、浮動小数点環境にアクセスしたりそれを変更したりする (たとえば、丸めモードを変更したり、浮動小数点例外をトラップしたりする) 場合は、/fp:strict を使用します。 どうも読んでみるとコンパイラは基本的にIEEE-754にのっとった浮動小数点の仕様にのっとって動作しますがコンパイルする際に最適化をしようとすると計算結果が微妙に変わってしまうようです。 それを見ると ゲームエンジン側で予期せぬバグが発生してしまう可能性をつぶすため 逆数を求めてそれを掛けるやり方にすればコンパイラのオプションに左右されることなく計算効率の良さを維持できる これらを踏まえてこのような実装に至ったのかな？と私は推測しております。 次の計算、長さを図る やってることはベクターでもおなじみ、内積で求めた値の平方根を求めるだけ core/math/quaternion.cpp // 内積、ベクトルと変わらない real_t Quaternion::dot(const Quaternion &p_q) const { return x * p_q.x + y * p_q.y + z * p_q.z + w * p_q.w; } // 長さを図るために自分自身の値を内積に適用 real_t Quaternion::length_squared() const { return dot(*this); } real_t Quaternion::length() const { return Math::sqrt(length_squared()); } 正規化自体はベクトルのそれと大差ありません。 有限値であることをチェックするメソッド 一方でこのようなコミットが見つかりました。 github.com/godotengine/godot/commit/db90de4dbdbe2… ここからはこれが実装された背景について考察していきます。 有限値とは桁に限りがあるごく普通の数値全般のことです。 1とか2とか1000万とかあの辺は有限値、お金も有限値ということになります。対になるのは無限です。このメソッドではNaNとInf（無限値）であるかどうかをチェックしております。 core/math/quaternion.cpp bool Quaternion::is_finite() const { // 計算できないNaNであるか無限になっちゃってるかをチェックしている return Math::is_finite(x) && Math::is_finite(y) && Math::is_finite(z) && Math::is_finite(w); } これを突破できなかった場合、このクォータニオンは計算できない代物であると判定されます。MATH_CHECKマクロが有効な時に実行されているのでデバッグのために用意されたメソッドですね。 クォータニオン以外にも有限数をチェックするメソッドが実装され、実際にチェックされています。例えば Vector3 にも実装がされております。 core/math/vector3.h void Vector3::normalize() { // ここにも有限値チェックメソッドが if (!is_finite()) { #ifdef MATH_CHECKS WARN_PRINT("Vector3 cannot be normalized, the elements must be finite. Making (0, 0, 0) as a fallback."); #endif // MATH_CHECKS zero(); // 正規化できないであれば全部ゼロの値にした方がよいという判断 return; } real_t l = length_squared(); if (l == 0) { zero(); } else { l = Math::sqrt(l); x /= l; y /= l; z /= l; } } これはIEEEにて策定された計算式がうまくいかなかったときに返ってくるNaN、Infを回避するために設計されたと私は考えます。 learn.microsoft.com learn.microsoft.com learn.microsoft.com learn.microsoft.com 具体的な仕様としてNaNという計算ができないものが発生した状態でそれを計算するとNaNになるという仕様があります、Infだと多少過程が変わりますが最終的にNaNになるのは変わりません。これで何が起きるのかというとゲームのキャラクターのサイズが勝手にゼロになって突然消滅したり逆に必要以上に巨大化したりしてグラフィックからしてゲームが成り立たなくなる可能性があるのです。 正規化されているかをチェックするメソッド もちろん自分自身が正規化されているかをチェックするメソッドも用意してありました。 core/math/quaternion.cpp bool Quaternion::is_normalized() const { return Math::is_equal_approx(length_squared(), 1, (real_t)UNIT_EPSILON); //use less epsilon } 謎 何故か次のメソッドには件の有限値チェックメソッド is_finite が通ってません。 core/math/quaternion.cpp Quaternion Quaternion::normalized() const { return *this / length(); } あくまであれはチェックなのですが万が一無限数とか計算不能な値が出たらバグが発生してしまいます。自身の内部の数値が変わる際には有限数チェックが入るのですがこちらは呼び出した側で処理を行う際に異常を検知する前提で動くのでしょうか？ 私には判断ができませんでした。 最後に 私は毎週月曜日にGodotのソースコードを読む配信をしております。 以下の再生リストは今回のソースコードを読んだ配信が入っているものです。 youtube.com 良かったら見ていってください。 次回は逆クォータニオンを求めるinverse()のソースコードから入っていきたいと思っております。

[RELEASE] GODOT ENGINE 4.x for Vita (v0.1) Hey everyone! A few days ago, I sharedan update on my PS Vita homebrew projects and mentioned that I'd been working on bringing Godot 4 to the PS Vita. Well... here we are! I'm happy to finally share the first public release of Godot 4 for PS Vita! hehehe The goal is pretty simple: give the homebrew community another way to create new games or port existing Godot projects to the Vita, whether they're open-source or closed-source (as long as you have the necessary rights to use the game files). I've spent quite a bit of time working on the engine itself, especially optimizing the native GXM rendering backend for both 2D and 3D. There's still plenty of work ahead, but I've already managed to get several games running on actual hardware! What's included in this first release? - Godot 4.8-dev7 adapted for PS Vita. - Native GXM 2D renderer, with experimental 3D rendering support. - A portable Windows editor with built-in PS Vita export support. - Export compatible projects directly to VPK, without needing to install VitaSDK, WSL, or additional tools. - Support for Vita controls, analog sticks, touchscreen, audio, and more. - Customizable LiveArea templates and game icons. - Optional separate game data folders, making updates easier. - Experimental trophy integration (still a WIP). - A native animated loading screen. Games I've been working on... These are some of the projects I've worked on while developing and testing the engine, listed from oldest to newest: 1. Dodge the Creeps – My first test project. Basically where it all started. 2. Ambidextro – A more complex 2D project that helped me identify and fix several rendering and performance issues. 3. Tenebrarium – Another 2D port that pushed the rendering backend further. 4. OVERBURDEN – One of my first major experiments with native GXM 3D rendering. 5. Deltarune: Lightners Live Plus – Another project I've been testing with the engine. >I've also been experimenting with other games, including Buckshot Roulette, although that one's still in a very early experimental stage. Some of these projects are already playable, while others still need more work. I'm planning to release more of them publicly as I continue improving the engine. A bit of background This whole thing started because I wanted to build on the work done by SonicMastr, whose Godot Vita port was itself based on contributions from Stary2001 and EIREXE, using PVR_PSP2. Their work was a huge inspiration. I wanted to take things further by bringing Godot 4 to the Vita, improving compatibility, and exploring what could be achieved with native GXM rendering. It's been a pretty challenging project, especially considering the Vita's hardware limitations, but seeing modern Godot projects running on this little handheld has been incredibly rewarding. A few things to keep in mind... This is v0.1, so please don't expect everything to work perfectly just yet. 2D support is already functional for several projects, but some shaders and visual effects are still missing. 3D is even more experimental, and performance will vary depending on the game. Not every Godot 4 project will work out of the box. Some games will require modifications, optimizations, or workarounds. For closed-source Godot games, you might find these tools useful when exploring how a project works: - Decompiling with Godot RE Tools - GDRETools / gdsdecomp Ofc, make sure you respect the original developers' rights and any applicable licenses. Download and Source Code GitHub: WolffsRoom/godot4-psvita Wolff´s Room Discord (for the news): discord.com You can grab the first release, check out the source code, and find instructions in the README. The project is open-source, and contributions, bug reports, testing, and feedback are very welcome! I'd especially love to see what other devs in the Vita community can do with it. If you've got a Godot project you'd like to try porting, give it a shot! Huge thanks to everyone who has contributed to the Vita homebrew scene over the years. This wouldn't have been possible without the work of the people who came before. Anyway, that's it for now! Hope you guys enjoy it, and let me know what you think! :) I'll keep working on compatibility, performance, and the rendering backend. Vita Means Life :) Edit 1: added Wolff's Room discord Servers link

Twine: From Branching Stories to a Browser Game and Godot Twine — turn linked passages into a playable story. In our lighthouse story, bringing tea raises trust. Later, that choice decides whether the keeper shares a secret. ① Publish to File → one HTML file you can play in a browser or host on itch.io. ② Export as Twee → plain text that a game engine can read with a suitable parser. We ran our story in Twine 2.12.1 and Godot 4.3. The Godot parser was written for this episode: it supports only the passages, links and Harlowe macros used here. It is not an official integration or a general Harlowe runtime. What earlier choice would you let a character remember? Twine — 연결한 단락을 플레이할 수 있는 이야기로 만듭니다. 직접 만든 등대지기 이야기에서 차를 건네면 신뢰가 올라가요. 나중에 등대지기가 비밀을 알려 줄지는 그 선택에 달려 있습니다. ① Publish to File → 브라우저에서 열거나 itch.io에 올릴 수 있는 HTML 파일 한 장. ② Export as Twee → 알맞은 파서를 통해 게임 엔진에서 읽을 수 있는 텍스트. 같은 이야기를 Twine 2.12.1과 Godot 4.3에서 실행했습니다. Godot 파서는 이 편을 위해 작성했으며 여기 쓰인 단락·링크·Harlowe 매크로만 처리해요. 공식 연동이나 범용 Harlowe 실행기는 아닙니다. 캐릭터가 어떤 이전 선택을 기억하게 만들고 싶으신가요? Twine · Chris Klimas & contributors · GPL-3.0 github.com/klembot/twinejs/tree/4ebcce6a69c62b1c4… github.com/klembot/twinejs/blob/4ebcce6a69c62b1c4… Harlowe 3.3.9 · Leon Arnott · Zlib Godot 4.3 · contributors · MIT github.com/godotengine/godot/blob/4.3-stable/LICE… Bandersnatch screenshot / 캡처: Wikipedia contributors · CC BY-SA 4.0; emphasis added / 밑줄·굵기 추가 en.wikipedia.org creativecommons.org Site/game-list screenshots have separate rights. 사이트·게임 목록 캡처의 권리는 각각 다릅니다. Story & Godot example / 이야기·Godot 예제: our own / 직접 제작 Curated by instagram.com Publishing / HTML 내보내기: twinery.org

Another #Godot #Multiplayer PR! godot#124801 This one is a whole new Feature I think improves usability. I like Godot's multiplayer a lot, but for Data like "Peer 100 is named Colin", using RPCs, Synchronizers, or Spawners through the Node Tree is pretty unwieldy. #GameDev

High-quality character shadows without increasing shadow atlas resolution (Godot feature proposal) While making a space game I struggled to keep directional shadow quality high for my player while increasing max shadow distance so fairly distant objects dont lose shadows. Tweaking cascades helped but required me to keep increasing directional atlas until 8192x8192 until I got results I could tolerate. But since one of my targets was Quest 3 I had to look for another solution. So I learned about per object shadows where projection fits tightly to the shadow casting object instead of capturing large distances as cascades. Cascades can waste a lot of shadow map space when only a few objects actually need detailed shadows. One of the closest related proposals on Github made by another dev is here: godot-proposals#5841 After some time tweaking the Godot internals, I created a node type ShadowGroup3D. It is an editor node that acts like a container that tracks all meshes inside, excludes them from standard cascades and renders their shadows using a separate projection fitted tightly around those meshes. So if you'd want to get crisp shadows, you'd just create ShadowGroup3D and put your character inside. Where I think it may be useful: - If you're building a mobile or a VR game and want high quality shadows for your characters without being forced to increase your global directional atlas size (doubling the atlas resolution increases its pixel count by 4x). With ShadowGroup3D you'd even be able to actually reduce your current atlas size if the only reason you increased it in the first place was to just make your character shadow look less blurry/shimmery. - Especially in VR where you'd want your character's hands and weapons to cast a really good looking shadow, given that the player can see things up close. - For worlds that want to have shadows at large distances while keeping high quality shadows focused on things that matter: characters, weapons, important objects, npc. - For games aiming for high end graphics standards where you'd want your main character to have the best possible shadow resolution above everything else. - Fighting games where you have 2 characters and want to maximize their shadow quality I haven't done thorough benchmarking yet and my implementation only supports Mobile renderer, however I'm planning to add support for Forward+ renderer as well and make a PR to the Godot repo after some more testing, polishing and refactoring. Video recorded with Godot 4.8 beta (custom build, dev branch). Params shared by all 3 video clips: - Mobile renderer - Sun shadows: 2 cascade splits (PSSM), 80 m max distance, blend splits off - Soft shadow filter quality: Soft Very Low - Shadow blur 1.0, bias 0.1, normal bias 2.0 - 16-bit shadow depth - 4× MSAA Would you like to have ShadowGroup3D as a feature in Godot? Let me know.

DDS Mip Sizes: Keep the Smallest Compression Block Disclosure: This article was generated with AI for the FrameSprite team, which has a commercial interest in FrameSprite. It received a separate AI editorial review against the cited sources. Executed synthetic fixtures are identified with their runtime and limits; no other editor, engine, production or performance test is implied. Calculate each BC-compressed DDS mip level from whole compression blocks. Do not keep dividing byte counts by four after the dimensions become smaller than a block. The smallest mip still occupies a block, even if it contains only a few logical pixels. > Key takeaway: Mip dimensions shrink, but compressed storage has a minimum block size. Validate the emitted mip count rather than assuming every file contains a complete chain. Start with a non-square texture The authored example uses a 7 by 3 BC3-style texture with 16-byte blocks and a legacy 128-byte DDS header. Its full dimension chain is 7×3, 3×1 and 1×1. This is a byte-layout exercise, not a claim that every engine accepts those source dimensions. The Microsoft DDS layout documentation gives block-based level sizing. For this selected format: blocks_x = max(1, (width + 3) // 4) blocks_y = max(1, (height + 3) // 4) level_bytes = blocks_x * blocks_y * 16 | Level dimensions | Payload bytes | Offset in the authored file layout | |---|---:|---:| | 7×3 | 32 | 128 | | 3×1 | 16 | 160 | | 1×1 | 16 | 176 | The payload totals 64 bytes and the authored file layout totals 192. Repeated quartering would incorrectly predict 32, 8 and 2 bytes. Read the header before choosing the formula Identify the compression format and its block byte size. An eight-byte BC1 block and a sixteen-byte BC3 block do not have the same payload calculation. Also account for any extended header, array layers, faces or additional surfaces in the actual file. The DirectXTex DDS I/O notes document compatibility handling for older files and partial blocks. A validator should report its accepted profile instead of silently guessing which historical convention a damaged file intended. Do not equate a partial chain with corrupted pixels Some files intentionally contain fewer mip levels than a full chain. Validate the declared count, byte ranges and the target importer's capabilities separately. A Godot DDS import report illustrates a real partial-mip compatibility problem. It concerns the reported versions and files; it does not prove a current engine-wide failure. When a target rejects a file, preserve the original header and level-size report. Re-export a compatible file from the source rather than adding zero bytes until a size check happens to pass. Recorded arithmetic and failure control Python 3.12.10 ran three assertions in the checker. The result records all level offsets, sizes and the 192-byte total. The input fixes the dimensions, block bytes and legacy header assumption. No DDS file was decoded, no BC encoder was run and no GPU texture was created. Check the rest of the delivery contract Use the GPU-compression fallback guide for target capability, the texture-memory budget guide for runtime allocation planning, and the asset-version manifest guide to keep the validated file paired with its release metadata. The final acceptance test is still the target build loading the exact exported file with the intended mip count. Correct byte arithmetic is a useful preflight step, not a substitute for that import test. Editorial ownership Prepared by the workflow team, which has a commercial relationship with this site. This guide was drafted with AI assistance; independent editorial review is recorded separately. Report a technical correction with the relevant input, tool version and observed result. Original guide and downloadable materials

If you want to check for actual participation, open the Commits page and filter by author, e.g. github.com/godotengine/godot/commits Check different branches too, if you must.