« Dictionary.loadStructでテキスト形式でも読めるように対応 | メイン | Android Studio 2.2 + cmake で上位ディレクトリを C++ の基準とする »
2016年09月07日
吉里吉里Z 開発:: 8末までマルチプラットフォームクラウドファンディングを受けて
Tweet @jin1016をフォロー現在集まっている金額から考えて、Android 版互換性向上とブラウザ (WebAssembly) 版 を優先することにしようと思います。
ただ、WebAssembly に関しては現在の金額では厳しいため、引き続き支援を募集したいと思います。
Android 版互換性向上は、ソフトウェア描画を実装し KAG3 などの動作で最もネックとなる部分を解消します。
ソフトウェア描画の動作速度を見て、SIMD(neon) には非対応もしくは基本的なアルファブレンディングのみ対応を検討します。
マルチウィンドウは非サポートなので、Yes/No ダイアログ等モーダル Window で実現しているものは、Layer 等で描画するよう修正の必要がある形に。
残りは WebAssembly へ。
SIMD(neon) 対応せずにソフトウェア描画のみの対応であれば、大して工数かからないため、そこそこ WebAssembly に工数使えると思うが、今の金額だと完全対応はかなり厳しい。
WebAssembly に対応すれば、他のプラットフォームも対応できることになる。
Windows / Android / iOS / Mac OSX / Linux / Chrome OS で動く、もしくはもうすぐ動く。
PC(Windows/Linux/Mac OSX) であれば、htmlファイルと共に配布して起動してもらうこと、node-webkit 等に組み込んで配布することも可能なはず(組み込んで配布はまだ対応していないかもしれない)。
Android/iOS は、WebView で実行するアプリ化やサーバー経由での動作となると思われる ( WebAssembly 対応が次かその次くらいのOSバージョンとなると思われるので、Android はネイティブ対応したものを使う方がいい )。
WebAssembly 第1目標は、TJS2 WebAssembly コンパイラ (wasm 上で動作)を作ること。
ただ、現在集まってる金額ではきちんとコンパイルできるところまで作れるかどうか厳しいところ。
調査、環境整備、ドキュメント整備で終わってしまうかもしれない。
作るものは TJS2 スクリプトを wasm のテキストもしくはバイナリにコンパイルする。
wasm 上に TJS2 VM を実装するのではなく、サポートクラスを使い wasm でネイティブで動作するようにする。
コンパイラはネイティブプログラムではなく wasm として動作するものにする。
wasm として動作することで、eval などの呼び出し時に動的に wasm バイトコードへのコンパイルを行って実行することが可能になる(これがなければ TJS2 VM の実装が必要になってしまう)。
JavaScript が提供するブラウザAPI の呼び出しを TJS2 上から可能にする。
ここまでが最初の目標。
吉里吉里Z が提供する組み込み API は当初実装しない(現在集まっている金額では工数的に厳しい)。
吉里吉里Z 互換とするための API は TJS2 で記述することで、上位システムは他プラットフォームと共通とすることが可能(この方向を指向)。
VM を実装せず wasm バイナリ化するため JIT でネイティブ動作されると思わるため、吉里吉里Zなどよりも高速に動作する可能性が高いが、動的言語のため関数呼び出し等の検索のオーバーヘッドが大きく、ネイティブと比べて速度的にかなり不利になる。
これを解消するため、C# の sealed class のような動的に変更が出来ないクラス機能を追加し、型指定との組み合わせによってネイティブと遜色ない動作速度を実現し、下位層を TJS2 で実装しても問題ない速度で動くようにする(上位のシステム部分は互換性のためこの機能は使わないことを想定するが、吉里吉里Z では sealed などのキーワードが単純に無視される形で組み込まれることも検討)。
以下、別作業や将来的なこと
API リファレンスを疑似コードからマニュアル生成するツールに切り替えるべく、現在の xml 形式から疑似コードとヘッダーコメントの形式へ書き換える。
これをやっておけばメンテナンスしやすくなるし、疑似コードは一種のスタブでもあるので、吉里吉里Z 互換層を TJS2 で書く時の下地として使え、内部を埋めることでブラウザで吉里吉里Z 互換が可能となる。
ブラウザでは、描画は WebGL を使用することとなると思うが、これは実質 OpenGL ES2.0 なので、Android 版で導入されるハードウェア描画とほぼ等価な機能が実装可能であると考えられ、将来ハードウェア描画を主体としたシステム (KAG 等)に切り替えられれば、ブラウザ上でも遜色ない見た目を実現できると思われる。
投稿者 Takenori : 2016年09月07日 22:31
comments powered by Disqus