- ゲーム開発
- ED用の素材を作成
文字の取り扱いが問題だったけど諦めました。
エフェクト扱いで作ります。今後もこうなる可能性が高いです。
- DLカード発注
テンプレートを用意してあるので底に当てはめる形で作成の上、発注済み。
これで最低限の頒布は可能になりました。
- OPの制御整理・画像作成
遷移周りが人間に理解できるか怪しくなってきたので、内容を整理しておきました。
これで再利用しやすくなる。
- ビルド試行
実行ファイルに固める準備を行いました。これやってないと後で困るので。
- 作曲（²）
2曲めを作成。これらをループすることになります。
- プログラミング
- MiniscriptのTACについて
Three-address code – Wikipedia
日本語のほうはこっち
3番地コード – Wikipedia
- どうもアセンブリ言語のことではなく、アセンブリより前に単純な計算に落とし込むって感じか。
- MiniscriptはOpCode含めたTACに変換して、そこに適合する一時的な変数（以降テンポラリ変数と記述）を用意して、MiniscriptのVMで計算する感じになってるみたい。
- なので、文字列としては依然として存在してて、コンパイルするとなるとコードの簡略化・最適化を行うとかになるのかと思う。
オペコードやテンポラリ変数をただの数値扱いにするとしても、パーサーは実行しているため「変数名」は残ってしまうわけで、C#での実装だとここでstringを使って保存している可能性はある。
- 更にいうとMiniscriptの仕様として文字列は利用可能なので、どちらにしてもstringでデータを持つのが早い。となるとテンポラリ変数もstring扱いにしてる可能性がすっごく高い。
- つまり以下の可能性がある
- Interpreter実行の時点で、最低限の計算に落とし込む（これがTAC）
- アドレスコードはその場で割り当てられる（MiniscriptのInterpreterの実装に依存するため、ずっと同じアドレス・テンポラリ変数にはならない）
- 実行時、割り当てられたテンポラリ変数を使って計算する
- 現状だと、事前コンパイルについては期待できない（互換性が維持できない）と考えるべきかなーと。
- 公式ディスコードでも「保守が大変になる」旨を制作者が語っている（そもそもTACは途中計算扱い）。
