Open1
GodotEngineのGDScript上で、エンジンで確保しているデータを大量に整形する場合、時間がかかる。
MachiaWorksやりたいこと
- オーディオファイルをメモリ上に展開して、自前関数のオーディオストリーム上で再生させたい
- Godotに移行したいのは、インゲームのテキストエディタがほしいから。（割と需要が限られる）
結果
- まずオーディオファイルの展開がすごい重い。１個のサンプルで動作が１秒程度止まるレベル。
- 次やるとすれば、audio.Play()をスケジュールで指定する等かな、とおもった。
想定される理由
専用クラスへのメモリアクセスがやたら遅い
これはプロパティやメソッドへアクセスするときに顕著。
メモリ最適化がガシガシ行われていて、専用メソッド以外からのアクセスが困難
試しにオーディオのデータを見てみると、byte列でのアクセスのみが可能。
これを整形してデータを復号化してオーディオを作成するということになる。
例えばfloat配列にビット演算で整形し、これを配列に格納するというわけですな。
１番目の理由とあわせるとかなりの時間がかかる。
よって、NG。
（そもそもわざわざEngine側でメモリ確保しているのをユーザ側で展開するという設計思想ではない模様）
対応案
事前にデータを整形しておく
これを行ったのだが、サンプル１個で１秒かかるという状況であった。
ちなみに複数持っているので結構時間かかるんじゃないかな。
スケジュールで再生秒数を計算する
Unityだと再生キューの秒数を計測すらできなかったので導入を見送ったけど、
Godotであれば再生キューも更新関数から導入が可能なので、タイミングの制御も容易になるものと考える。
データ格納処理をNativeで行う
時間があればやりたいね！ただ時間がかかる。
結論
- GDScript上でエンジン埋め込みからユーザデータを確保する等は基本的には重い
- よって、エンジンでのロードを踏まえて動作を確認するのがいい
- 途中で利用エンジンを切り替えるべきではないorz