グラフィック関係のSSE2部分をNEON化する。
ソフトウェア描画が必須ではないので後での対応で問題なし。
libsimdpp などを利用して抽象化し、CPU依存を減らす方法も検討。
使用可能命令などの理解がないと速度があまり出ないかもしれないが、PCで開発してそのまま持って行けるメリットはある。
ある程度速くなれば良いと言うことであれば、実用的かもしれない。
自動ベクトル化が意外と強力で、適用される場合は自前で書いた場合に近い速度が出る。
自動ベクトル化されやすい書き方にすることで、汎用的に高速化されるので、そちらを目指す方が良いかもしれない。
吉里吉里と同程度の機能を有するのならOpenSLでの実装が必要になる。
Javaを使ってOpenGLのテクスチャに描く。H.264ならこの方法。
C++ならOpenMAXになるがMPEG2になる模様。
独自エンジンとするとTheora。
複数ウィンドウは対応できないので、単一ウィンドウで仮想的なWindowクラスを作る。
startup.tjsをどこから読むか。
assets内に入れたconfig.cf (以前はexe名+cfであったが、名前を変える必要はないので固定化) で指定。
指定がない場合、assets内のdata.xp3から読み込む。
Intentによって指定された場合は、そのディレクトリを優先的に読むが、リリースバージョンではIntent指定できないようにする。
NDK からは assets 内は直下のファイルしか読めない。
Java からだとサブディレクトリにもアクセスできるが、Java 経由で読むのはオーバーヘッドが懸念されるため行わない。
assets 内が圧縮される問題は独自リリーサーで回避する。
それでも読み込みが遅い場合は、SDやキャッシュにコピーしてから読み込むなどの検討が必要。
apk にすべて入れるのではなく、分割ダウンロードするのならダウンロード機能の追加が必要。
Google Play 配信を考慮するなら拡張ファイル対応が必要。
Android アプリの各種リソースは Java で読むことを想定されている。
アイコンと文字列、ライセンス情報辺りはリソースに入れるのが良い。
文字列などは、Java からリフレクションを利用してアクセスするか、起動時に Java で C 側へすべて登録してしまう必要がある。
アイコンは C 側からは触らないだろうから、何も対応しない。
ファイル類は Activity::getFilesDir() に保存する。
一時データは Activity::getCacheDir() に保存する。
外部ストレージのアプリデータフォルダは Environment::getExternalFilesDir() で取得した場所。
Environment::getExternalStorageDirectory() ではルートが取れる。
もしくは、getprop "EXTERNAL_STORAGE_MOUNT" でSDがマウントされた場所を取得する。
キーと値のペアであれば、 SharedPreference で保存るのが望ましい。オプション設定はここか？
レコード状のデータの場合は、ContentResolver を使い SQLite に保存するのが望ましい、またアプリ間共有も可能。
ユーザーオプションは SharedPreference へ、セーブデータは外部ストレージがデフォルトを予定。
V2Link、V2Unlink のみをサポート(関数やクラスの追加等)。
サウンドのデコーダー等特殊なインターフェイスを介してやり取りするものは未サポート。
Windows版でリソースにしている設定データなどはどうするか検討必要。
IStream は Windows 固有のものであるが、ないと困るのでインターフェイスを定義して使用可能にする。
- パーミッション確認ダイアログ(6.0以降からJavaで実装)
以前はインストール時にパーミッション確認があったが、6.0以降からアプリが任意タイミングで出来るようになった。そのため自前で確認要求する必要がある。
ゲームだと、ストレージ、ネットワーク、バイブレーション辺りか。 - onPause でのセーブ
非アクティブ化時に onPause が来るが、その後バックグラウンドに回った後に何の通知もなく殺されるケースがあるので、非アクティブ化時の onPause でオートセーブがあったほうがよい。 非アクティブ化は、電話がかかってきた時など注意したら防げるものでもない。 - ファイル名大文字小文字の扱い
Androidのファイルシステムはケースセンシティブなのでどうするか検討。開発時のみだと思うので、見付からない場合毎回検索してもいいかも。 ケースインセンティブを予定。
大文字小文字違いで見付からない場合は、上位パスからその都度検索する(つまりすべて小文字にしておくと検索が速い)。
ただし、xp3にしたら関係ないのでそれほど問題ではない。 - グローバル変数のクリア問題
Androidでアプリ再起動された時グローバル変数がクリアされない(再利用される)問題がある。NativeActivityを使う場合はsoを分離して、起動時に本体を毎回読み込むことで毎回クリアを確実にする。普通のActivity使うならJavaから毎回soを読み込むので気にすることは少ない。 - プッシュ通知(必要なら)
プッシュ通知は別途サーバーを準備する必要がある。配信には必ずしも必要ではないが、通知先のIDを登録するサーバーが必要。通知先IDはメールアドレスのようなもの。
Googleのプッシュ通知がアダルトOKかは不明。Amazonのサービス等必要かも。 - DRM
DRMはストアごとに異なるので、それぞれ準備する必要がある。Javaで実装する。
Amazonに登録する場合は不要でストアが勝手にやってくれる。 - 文字入力
ソフトウェアキーボードな上に直接入力は難しいのでダイアログでの入力になる - RSS等による更新取得
プッシュ通知が出来ない場合は、何らかのタイミングで定期的にRSSなどを読んで更新情報取得する。1日1回ロック解除時か、タイマーか。タイマーよりも何らかのイベントをトリガーとした方が確実。 - タッチ、回転操作
Windows版もZから実装済みなので、同等のものをAndroidでも実装する。
- マウス入力、ゲームパッド入力
あった方がいいが、スマフォ・タブレット主体ならなくてもいい。将来実装項目。 - 動画は機能制限
セグメントループやピリオドなど困難な可能性あり - Shift-JIS 廃止、UTF-8 に一本化
吉里吉里3から持ってきたSJISToUnicodeStringなどの変換関数を内部に持っているので、そちらに一本化すればShift-JIS対応は可能。
どうしても必要と言うことでなければ、UTF-8 に一本化する方が後々楽になる。 - wchar_tのバイトサイズ問題
Linux系ではwchar_tは4バイトとなるので、2バイト前提となっている箇所では問題が発生しうる。
文字列処理系の関数を自前で持ち、2バイト固定で処理すると安心ではあるが、少し手間がある。
いくつかの関数は自前実装となっている。
文字列処理系もSIMD化による恩恵があるので、その高速化も見越して自前化していくのもあり。
Androidの標準ライブラリとしてBionic libcがBSDライセンスで公開されているので、そちらに手を加えてwchar_tをtjs_char 2バイトとして書き換え使用する手もある。 char16_t を内部文字コードとして使用し、各種文字列処理メソッドはBionic libcから持ってくることを予定。 - pathデリミタ
Windowsでは\だが、Linux系は/となるので、その差を吸収するようにうまく作るようにする。
/を基本として、\は内部以外では使わないのが望ましい。 - bitmapの上限反転を正順化
Androidで使われるbitmapは正順。
OpenGL/DirectXでは描画時に反転など楽にできるのでどちらでも影響は少ない。
変更しても基本的には問題ないはずだが、組み込みDrawDeviceでは問題が出たため、プラグイン等でも影響あると思われる。 - Intent に読み込み
起動時や起動中に他アプリからIntentによって各種データの受け渡しをされることを考慮した機能。
Windows 版ではクリップボードなどで受け渡しだが、Android だと Intent。
初期は起動フォルダ指定のみ対応でもいいが、将来的にはあったほうが良い。 - コマンドライン引数は読み込まない
- -printdatapathは無効、ContentResolverやIntentで取得できるようにするのが望ましい。
- -aboutでのライセンス情報表示など無効、ゲーム中から呼び出して表示する方法が必須。
- Android用リリーサー
アイコン、タイトル、パッケージ名、アーカイブ、署名のみを差し替えるツール。
毎回ビルドせずにリリース可能にする。
通常のビルドツールではassets内はすべて圧縮されてしまう(apkファイルはzipファイル)が、data.xp3などを置いたとき圧縮率、無圧縮など指定したいことを考えてリリーサーは必要。
署名・パッケージ化ツールは以前C#で作ったものがあるので、それに手を加えればそんなに工数はかからない。
Javaでの開発も必要なためJava開発が行いやすいAndroid Studioが使いやすいが、C++に関してはまだまともに使えない。
C++はVisual Studio(+nVIDIA AndroidWorks)が使えるといい。
機能のON/OFFをデバッグオプション化して、コマンドラインでビルド出来ると効率的。
モバイル環境では不要な機能をOFFにしてバイナリサイズを抑えたいなどの要望もありうる。
プラグインも本体に組み込んでしまった方が取り回しやすい。
広告・インターステンシャルで任意タイミングで挟めると同人向けにはいいかも。
バナー広告だと画面狭くなるし下だと邪魔だしタップされなさそう。
インターステンシャルで挟めるとシーンの切り替わり時に挟むことで効果的に広告収入ありそう？