Closed S-H-GAMELINKS closed 7 years ago
原因は、以前のタグが記載されたテキストを使用していたため文字化けが発生していた模様。
しかしながら、前のルートで描画したテキストの内容が所々で再び描画されている模様。
以前のソースの場合、ルート分岐後に初期化していたので、その部分か?
develop branch によれば、
FORMAT関数で、スクリプト変数をFileRead_closeしていた模様。
と、いうことはスクリプト変数がきちんと閉じられていないのか?
下記のコードから、閉じられていることが判明。
if (0 < EndFlag && EndFlag <= countof(ScriptFileNames)) {
// スクリプトファイルを開く
const int ScriptFile = FileRead_open(ScriptFileNames[EndFlag - 1]);
SCRIPT_TO_ARRAY(ScriptFile);
FileRead_close(ScriptFile);
}
となると、別な要因か
うーん、グローバル変数 SP
, CP
の操作をミスっているんだと思うんですが、ちょっと辿れる気がしないなぁ・・・
ソースコード確認した限りでは、問題ないように思うんですが…
あと、参考になるか分かりませんが、以前似たような事がありました。
その時は ScriptFileがcloseされてなかったのが原因でした。
とりあえず、以前のソースを参考に下記のように変更してみました。
if (0 < EndFlag && EndFlag <= countof(ScriptFileNames)) {
// スクリプトファイルを開く
const int ScriptFile = FileRead_open(ScriptFileNames[EndFlag - 1]);
for (auto&& s : String) FileRead_gets(s, countof(String[script_line_string_len_lim]), ScriptFile);
FileRead_close(ScriptFile);
}
上記のソースで大体は問題なく表示されました。
しかし、G~Nルートでは結局文字化けや以前開いたスクリプトが描画されていました。
あ、正しくはこっちですね
if (0 < EndFlag && EndFlag <= countof(ScriptFileNames)) {
// スクリプトファイルを開く
const int ScriptFile = FileRead_open(ScriptFileNames[EndFlag - 1]);
for (auto&& s : String) FileRead_gets(s, countof(String[script_line_num_lim]), ScriptFile);
FileRead_close(ScriptFile);
}
ん、G-Nでだけあかん・・・? そう言うと 9427207ca8f9a36ef497d329b367ec5a98f88893 くらいしか浮かばないなぁ・・・
FileRead_gets
そうですよね、なんでこれscanfなのかなってずっと思っていました。ちなみに countof(String[script_line_num_lim])
は countof(s)
でいいです。
*ちなみに countof
マクロですが、C++17で標準入りした std::size()
が全く同じことしてくれて、VS2015から実装されているんですが、一応C++17の機能なので使ってません
FileRead_scanf
を使っていたのは製作途中にエラーがあったからそうしたのだと記憶してますが……
ちょっと、よく覚えていないですね……
とりあえず、マージ後のmaster branch にFileReaf_gets
でコミットしておきます
原因らしきものの特定ができました。
以下の部分の、 CP += 2
が問題だったようです。
CP++;
if(charactor.select(String[SP][CP], String[SP][CP + 1])) CP += 2;
//キャラクター描画
SCRIPT_OUTPUT_CHARACTER_DRAW();
break;
この部分を、CP++
に変更したところ、G~Nルートでの文字化け等は確認されませんでした。
また、この変更により、Releaseビルドでも各種素材が描画されていることが確認できました。
一応、あとでコミットしておきますね。
あ、Releaseビルドは勘違いでした。
このコードのassert外したら描画されてましたんで、Releaseビルドでも問題ないみたいです。
//キャラクター画像読込
assert(charactor.load("DATA/CHARACTER/CHAR{0:02d}.png"));
以下の部分の、 CP += 2 が問題だったようです。
ええっと、それで原因判明しました。
まずそのへんの処理をいじったのが
0fdbf402c619397fa0ba7a24aaf27cf71cdc30e2
です。この時SelectLoadedResource
という関数を作って、CHARACTER_DRAW
, BACKGROUND_DRAW
, BACKGROUNDMUSIC_START
, SOUNDEFFECT_START
関数とそこから呼ばれていた関数の大量のswitch文をごっそり書き換えました。この時点では++CP;
となっていました。
ところがその17分後、
ee29d2927d7629d49d8bf38a0535eebef2aebbd0
で元のコードを読み間違えて、CHARACTER_DRAW
, BACKGROUND_DRAW
, BACKGROUNDMUSIC_START
, SOUNDEFFECT_START
関数にあった CP++;
がそこから呼ばれていたCHARACTER_DRAW_N
, BACKGROUND_DRAW_N
, BACKGROUNDMUSIC_START_N
, SOUNDEFFECT_START_N
関数(Nは0~9)でも書かれていると誤認してCP += 2;
に書き換えてしまったようです。
これをリソース管理系をクラス化した
ce0d00e717c8e7a495f658a3274515e336467ff8
では気が付かず、そのままCP += 2;
がSCRIPT_OUTPUT
関数に持ち込まれたようです。
このコードのassert外したら描画されてましたんで、Releaseビルドでも問題ないみたいです。
あーしまった、assertの中の式ってNDEBUG
マクロが定義されているときは評価すらされないのか・・・。Google TestとかのASSERTマクロと挙動がごっちゃになっていました・・・。
これはちょっと他にもやらかしてそうなのでfix投げます。
fix 拝見しました。 毎度のことながら、ありがとうございます。
@S-H-GAMELINKS それで、このIssueに関連するバグは潰れたでしょうか・・・?
はい。今回の Pull Request でバグは無くなっています。
ありがとうございます。
では、 Issueをcloseしますね
選択肢で分岐した後のテキストが文字化けを起こしている。
以前のバージョンのソースコードと比較して、問題の部分を精査する予定。