07th-mod / 07th-mod/higurashi-assembly

Sprites stuck to the screen

オープン
#45 コメント 6 件 リアクション 0 件 担当者 4 名 @DoctorDiablo が担当を希望しています GitHub で見る
bug high-priority
主要言語
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

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。