07th-mod / 07th-mod/higurashi-assembly
Sprites stuck to the screen
- 主要言語
- C#
- スター
- 12
- フォーク
- 12
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
This is a long-standing bug that we've been aware of ever since Tsumihoroboshi was released last year - however, I have had nearly no success replicating the bug but I have some ideas now and I figured it's good to document this as well.
**The bug**: Sprites will stick to the screen, even persisting through a quit to the main menu. Someone has to reload the game and - possibly, not sure - use chapter jump instead of reloading their save to get around the issue. According to one user's report too, when attempting to switch sprite sets after this, that gets broken too, like characters get swapped.
**Arcs affected**: At least Meakashi and onward
**conditions**: not well known, but people report clicking through the text fast, some even using CTRL to skip.
I was able to replicate this once. One characters stuck to the screen, but the game uses 2 different scenes to facilitate screen transitions; the sprite would get stuck to only one scene. Haven't been able to replicate since then. I disabled some checks in the lipsync code for whether the animation was still active and was able to reproduce this behavior much more easily.
There is a known possible race condition in the lipsync implementation where at the point when an animation is in progress but the user clicks forward in the text, the game state is updated to cancel that animation, but the code will still try to return that character's expression to their mouth closed if it's currently open. The lipsync code is running on a coroutine and the race condition is that the game can continue executing other code once the user clicks forward in the text. But if this is indeed a lipsync related problem, then it's surprising we have never had any reports about this issue in the question arcs. Further clouding the issue is that almost all our players use lipsync, which might be signaling us in the wrong direction, but the fact that disabling other lipsync-related guards allowed me to more freely reproduce the issue makes it pretty likely.
**Theory**: The scene transitions may be critical here. If a character has some spoken line, and the player cuts it off early, and the next line in the script is to transition the background, then it may cause the closed-mouth sprite to be drawn onto the other scene.
**Possible solution**: Whether that's correct or not, a great step would be to eliminate that race condition. However, the game engine seems to have only fixed-length-of-time wait objects with different labels. We can add a WaitForLipsync wait type, and set the wait time to be the same as the corresponding voice time, possibly with a safety buffer, but that still isn't very clean. We may be able to instead add a more general WaitForCoroutine wait type, which will only clear when that coroutine actually terminates.
Still unclear on why this only seems to happen in Kai, though there were plenty of changes going into Meakashi, so it's not entirely surprising.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
The bug involves sprite rendering and lipsync coroutines in a C# game engine. Examine the lipsync implementation and scene transition code, particularly around Wait objects and coroutine cancellation. Look for race conditions when a user clicks forward during an animation. Reproducing the bug may require simulating fast text advancement and scene changes as described.
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- csharp
- 領域
- game-dev
- issue の種類
- バグ
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 25/100