2014年09月18日
吉里吉里Z Android/iOS 対応 クラウドファンディング
以下、達成できず終了しました。
細々と開発しているので、支援いただける場合はこちらの保守開発を見てください。
吉里吉里Z を Android と iOS に対応するためのクラウドファンディングを行いたいと思います。
本プロジェクトは開発費をみんなに出してもらって、早期完成を目指すものです。
集まった金額に応じて以下の優先順位で開発を行いたいと思います。
集まった金額に応じて開発項目が増えるので、それによって開発期間は変動しますが、2015年中旬頃完成目標です。
1次募集期間 2014年9月末日まで。
ここで最初に開発するものをいったん確定します。
それ以降も出資(開発依頼)は可能です。
追加機能について順次開発していきます。
1万円単位で○万円出してもいいと言う人がいれば、メールを下さい。
人数分契約書を作って、開発するという方式を考えています。
1万円単位と書いたのは、事務手続きの関係からです。
契約書を作る関係で、住所と名前が必要なのでそれを私に明かしても良いという人限定です。
また、ドキュメント等のコントリビューター項に載せる名前は別の方が良い方は、その名前。
コントリビューター項に載せないで欲しい場合は、その旨記載してください。
紙面での契約書は法人で必要な方のみとし、個人の場合は電子データでの契約書の受け渡しとなります。
メールには以下の内容を書いてください。
・住所と名前
・金額
・コントリビューター項に載せる名前
・支払い時期
・契約書ひな型で問題ないか否か
・紙の契約書が必要かどうか(法人のみ)
メールアドレスはここに書いています。
前回は、誰がいくら出したかなど公表していましたが、特に必要ない情報なので今回は合計額のみ公表します。
支払いは前払いが好ましいですが、後払いでも可能です。
後払いの場合、完了月の翌月末までにお願いします。
名前と住所についてですが、公開されるのは私個人のみにです。
公に公開されるのは、「コントリビューター項に載せる名前」で、なしでも問題ありません。
テストは規模的に一人で全て網羅は難しいので、実装完了後公開しみんなに叩いてもらうことを想定しています。
もちろんテストは順次進めますが、安定性向上のためには多くの方の協力が必要になります。
形式的に受託開発となります(寄付(贈与)ではありません)。
内容が関連する方は確定申告にて経費として申告可能と思われます。
目標金額
Android 対応 200万円 (Android 4.0以降)
iOS 対応 150万円(同時開発時) (iOS8以降)
Windows版調整 50万円
新KAG 開発 150万円
追加対応項目
もし上述の金額を超えた場合に以下の優先順位に従って開発します。
金額によって多少前後します。
特定項目指定で全額支払いで開発も可能です。
Android版リリーサー 20万円
Windows版リリーサー 10万円(Android版と同時の場合)
Win版64bit対応(サウンド除く) 50万円
+ サウンド(PhaseVocoder+float) 30万円
ハードウェア2D描画 50万円
ベクトル描画 50万円
アニメーションツール開発 100万円
TJS2ドキュメントツール 10万円
画像フォーマットコンバーター刷新 20万円
TJS2 エディタ/デバッガ 50万円
新KAG 開発支援ツール 50万円
ループチューナー刷新 30万円
TJS2 型指定本格対応 20万円
Layer.operateAffine 未実装機能対応 30万円
WinRT(ストア x86)対応 100万円
制限事項
Android/iOS 版は Windows版とは完全互換ではありません。
吉里吉里2/Z は、Windows を基準として開発されており、機能の少ないスマフォ/タブレット環境では無駄な機能や再現が困難な機能があります。
Android/iOS 対応では、PC で必要とするがスマフォ/タブレットでは必要とされない機能を削除します(そもそも実装できない機能もあります)。
Windows 版がフルセット、Android/iOS 版はサブセットと言うような関係性になります。
例えば、全画面で使うこと前提のスマフォでは、Window機能などは不要ですし、あっても手間が増えることになります(操作性も悪化します)。
全画面前提の環境に適したような仕様に変更されます。
新KAG は、KAG3 とは完全に別物です。
その他詳細については Android/iOS対応検討中仕様 を参照してください。
投稿者 Takenori : 18:49
Android/iOS対応検討中仕様
以下、検討中の仕様です。
実装過程で判明した制限などによって変更される可能性があります。
描画周り仕様
PC : Window - DrawDevice - Surface - Layer
Mobile : Surface - Layer
PC 版では、現在の仕様にSurfaceクラスを加えて、SurfaceをサポートするDrawDeviceを追加、Mobile 環境と同じような構造にして開発を行いやすくします(TJS2である程度共通化可能なようにする)。
Mobile 版は、Window/DrawDevice はなく、ある程度Windowクラスの機能を備えたSurfaceクラスが基準になります。
SurfaceはLayerTreeOwnerインターフェイスを備えたものになります。
Surface は、重ねて表示可能なものになります。
Mobile 版は、マウス入力、Click/DoubleClick をなくし、タッチのみになります。
Android ではマウス入力も可能ですが、マウス入力はタッチとして扱うことになります(ゼロではないが全体的にかなり少ないため)。
KAGParser はより一般化された仕様/実装になります。
Mobile 版では、Menuクラスは廃止されます(プラグインとしても実装されません)。
Mobile 版は、プラグイン機能は初期段階では実装されません。
Extension 機構によって拡張する形になります。
(iOSではプラグイン(SharedLibrary)自体使えない)
Mobile 版は、ファイルはケースセンシティブになります。
Windows 版はどちらにするかオプション化されます。
Mobile 版の動画再生機能は PC版と比べてかなり制限されたものになります。
(オーバーレイでのシンプルな再生程度の機能)
クラス名称が変更される可能性があります。
MovieSurfaceと言う固有のSurfaceクラスを用いて再生される形になるかもしれません。
Mobile 版の音声再生機能は、PC版と比べて制限されたものになります。
ラベル機能等はサポートされません。
Mobile 版では、画面位置を指定した直接的な文字入力は実装されません。
文字入力自体実装されないか、入力ダイアログによる文字入力となります。
Mobile 版では、float 形式の音声はサポートされません。
現在MMXで実装されている描画機能は、初期は実装されないか、使用頻度の高い物のみ実装になります。
工数的にすべて対応可能であれば、すべて対応します。
Mobile 版では、起動時に任意フォルダやxp3ファイルを選択して起動する機能は実装されません。
(デバッグ版として実装される可能性はあります)
Mobile 版では、オプション設定(吉里吉里設定)画面は起動しません。
Mobile 版では、コマンドライン引数は使えません(設定埋め込みは可)。
Mobile 版では、マルチスレッド描画について制限が発生する可能性があります。
(Android では、スレッドに特定コアを固定できない)
PhaseVocoder は実装されません。
Clipboard クラスは実装されません。
TJS2 デバッガサポートはありません。
システムにインストールされたフォントはサポートせず、Assetに入れたフォントのみ使用可能で、指定名称のフォントファイルがデフォルトとなります。
フォントのレンダリングはFreeTypeのみとなります。
投稿者 Takenori : 18:52
吉里吉里Z Android/iOS 対応 契約書ひな形
(捺印) は紙面の場合のみ
開発内容については、集まった金額に依存します。
最終期限は2015年12月31日としています。
ソフトウェア開発業務委託契約書
貴方の名前(以下「甲」という)と私の名前(以下「乙」という)は、次の通り業務の委託をするにあたり、次の通り合意し、契約(以下「本契約」という)を締結する。
第1条（本件ソフトウェア）
本件により乙が開発するソフトウェアは以下のとおりとする。
「吉里吉里Z Android/iOS 対応」
第２条（業務の範囲）
本件業務の内容は、以下の通りとする。
1.業務概要
吉里吉里Z を Android と iOS で動作可能にする。
2.業務詳細
・吉里吉里Z を Android と iOS で動作可能にする。
・その他詳細仕様及び設計詳細は乙に一任する。
3.スケジュール及び納品
・作業スケジュール
自 2014年10月01日 至 2015年12月31日
・納品
吉里吉里Zと同一ライセンスでソースコードをGitHubにて一般に公開し4カ月間のテスト期間経過後納品完了とする。
納品は上記スケジュールより前倒しでも可能とする。
第３条（対価及び支払条件）
1. 甲は乙に対して本業務の対価として金\○○円也（消費税込）を以下の通りに支払う。
2. 甲は、本業務の対価を、10月末日までに乙の指定する銀行口座に振り込むことにより乙に支払う。
( 2. 甲は、本業務の対価を、納品完了後末締めで翌月末日までに乙の指定する銀行口座に振り込むことにより乙に支払う。)
第４条（瑕疵担保責任について）
本契約に基づき作成されたプログラム等に瑕疵があった場合、乙は、公開後4カ月間のテスト期間のみ修正を受け付け、その後の修正は任意の対応とする。
第５条（著作権並びに著作人格権について）
本契約に基づき乙が作成し提供するプログラム等の権利（著作権法第２１条から第２８条に定めるすべての権利を含みます）はそのまま乙に属するものとします。ただし、乙は、その成果物を最終的に「修正BSDライセンス」で、甲および「吉里吉里プロジェクト」及びそれを利用する第三者に対して提供するものとします。
第６条（協議）
本契約締結後に記載内容に変更が生じた場合は、甲、乙協議の上、書面により別に定めるものとします。
本契約に定めのない事項又は本契約の内容等に疑義が生じた場合には、その都度、甲、乙双方が民法をはじめとする法令等を踏まえ、誠意をもって協議します。
本契約の成立を証するため、本契約書二通を作成し、甲乙記名(捺印)の上、各自一通を所持する
平成○○年○○月○○日
甲: 貴方の住所と名前
乙: 私の住所と名前
投稿者 Takenori : 18:52
2014年09月19日
Android/iOS対応 現在までの合計金額
吉里吉里Z Android/iOS 対応 クラウドファンディング
2014/10/01 00:00時現在
合計金額
0万円
合計人数
0人
投稿者 Takenori : 15:40
2014年10月06日
スマフォ版は作らないことに
クラウドファンディングの結果、必要としている人は誰もいないと言うことに。
と言うことなので、作らないことにしました。
開発費が何とかなれば作るかもしれないけど、今のところ難しい。
投稿者 Takenori : 16:25
2015年05月11日
タイマー
Androidでの実現性をざっくり確認するため、起動部分と共通部分をビルドして見ていたので、その続きで固有部分をコンパイル通るようにしていっていたけど、固有部分だけを別に作りこんだ方が早い気がした。
ソースコードが多いとビルド時間かかるようになるし、動作の確認もしづらくなる。
と言うことで、固有(環境依存)部分をちまちま作る。
メインのメッセージ(イベント)ループ部分とそのメインスレッドで動作させる仕組み、スレッド、タイマー(内部)、ウィンドウ、グラフィック、サウンド、ムービー辺りが環境に依存する部分か。
Windows が特異で、その他は Linux 系で似てて、共通になる部分も多そうだけど。
吉里吉里2/Z は、内部に2種類のタイマーがある。
1つは TJS2 から利用できる Timer クラスを駆動するためのタイマー。
これは独立したスレッドで独自実装されている。
もう一つは Windows のタイマーを使っているタイマー。
吉里吉里2だと、VCL ので実装されていたんだったかな。
吉里吉里Zは、Windows のタイマーを使って直に実装している。
で、このタイマーから起動される関数はメインスレッドで動く。
メインスレッドで動くと言う部分が他でやろうとしたら少し面倒。
1. タイマー用のスレッド作って、時間が来たらイベント投げて処理する。
2. メインのメッセージループで、イベント待ちタイムアウトを利用してタイマー処理する。
最初1の方法でやろうかと思ったけど、よく考えたら2の方が余計なスレッドなど増えずにいいかなと思った。
TJS2 の Timer クラスを実装しているスレッドでついでにやってしまうことも考えたが、TJS2 に依存しているので独立して実装するのには不向き。
メッセージループで実装始めたが、タイマーとは別に 16msec ごとのタイムアウトを同居させて、タイマーが更新された時にタイムアウト時間再計算時イベント発行して～とやっていると、これは素直に別スレッドに実装した方がシンプルになるかと1に戻る。
実装してみるとやっぱりシンプルになった。
ウィンドウ周りどうするかって問題。
以前は、Android は Window がないんだから無くしてしまった方が良いと考えていたけど、常に全画面で積み重なる形で Window を実装してしまえばいいんじゃないかと思った。
動作的には Activity みたいなもの。
モーダルでウィンドウ開いたら、全画面で上に重なって入力を全部受け、閉じられたら消える。
KAG3 の確認ダイアログのような形なら、この方法で期待通り動作するはず。
モードレスの場合は、異なる動作になってしまうと言うか、Window が1つしか同時に出ないようなものなので、どうにもならない。
表示非表示で交互に入れ替えて使うなどは出来るかもしれないが、結局は同時に表示できないからあまり意味のないものになってしまう。
この辺りはスマフォのような小さい画面では諦めるしかない気もする。
Window 周りを自前実装するのなら、タブレットなど大きい画面用に同時に複数ウィンドウ表示も可能なように考えてもいいが、最初はその辺り考慮しなくても問題ないと思っている。
投稿者 Takenori : 01:08
2015年06月10日
EGLImageKHR を使うテクスチャの高速書き換えはハードル高い
glTexSubImage2D でのテクスチャ書き換えは遅いから、EGLImageKHR を使って書き換えると速いと言うのを見るが、ややハードルが高い。
Using direct textures on Android が良く引用されている。
GraphicBuffer クラスは公開されていないので、libui.so を dlopen して、dlsym で各種メンバ関数を取得して、それを使う必要がある。
メンバ関数はマングリングされているので、_ZN7android13GraphicBufferC1Ejjij などの名前を使う必要がある。
コンストラクタを呼び出す前にオブジェクトのメモリを確保しないといけないが、これはある程度大きめのサイズで確保して渡すと言う方法がとられている。
この辺りトリッキーだけど、まあ GraphicBuffer が巨大化せずメンバ関数が取得できればそれほど問題なく動くので何とかなる。
eglCreateImageKHR、eglDestroyImageKHR、glEGLImageTargetTexture2DOES は、eglGetProcAddress を使って関数ポインタを取得できる。
これは OpenGL ES の拡張機能と同じだからそれほど問題ではない。
EGL_EXTENSIONS に EGL_KHR_image_base と EGL_KHR_gl_texture_2D_image が、GL_EXTENSIONS に GL_OES_EGL_image があれば行けるっぽい。
問題は、画像の stride がわからないこと。
eglQuerySurface(eglDisplayHandle, eglImageHandle, EGL_BITMAP_PITCH_KHR, &BitmapPitch); で取得できるのかと思いきや、渡した EGLImageKHR が BAD SURFACE とエラーが出て取得できない。
stride は、画像幅×ピクセルフォーマットからわかる画素サイズで計算して、特にパディングなどされていないものとして処理してうまく行く環境もあるようなので、そのようにする。
基本的には、上記のような問題点があるが動く。
xperia acro HD だと特に問題なかった。
Nexus 5 だと、stride がおかしいのか画像が壊れる。
少し古い機種だとうまく行くのかもしれない。
機種によっては、テクスチャにバインド済みだとロックが失敗するようなので、ダブルバッファリングして切り替える必要があるようだ。
また、GraphicBuffer で生成できる数が少ない環境もあるようなので、画面と対応するテクスチャ1枚だけにするなどした方が良いようだ。
Firefox では、ホワイトリストを使用して期待通り動作する機種を限定しているよう。
以上のことを考えると、使うのは厳しそう。
様々な機種でテスト出来て、ホワイトリストが充実させられるのなら何とかなりそうではあるけど。
後、4.3 以降で OpenGL ES3.0 に対応しているのなら PBO を使えるので、それ以前の端末と言うことになるので、少しは限定される。
とは言っても、現実的には ANativeWindow_setBuffersGeometry / ANativeWindow_lock を使う方がいいかな？
速度的な部分はまだ計っていないけれども。
投稿者 Takenori : 15:45
2015年12月21日
Android Studio 1.5 で NDK を使ったビルドを試す
Android Studio で、NDK を使いまともに開発できるかどうか調べてみた。
AndroidStudio 1.5 でNDK を認識させるメモ を参考にして、Gradle について調べつつ設定をあれこれ触っていたらビルドが走るところまでは動いた。
対象は昔 Android.mk を書いてコマンドラインでビルドしていた吉里吉里Z。
ただ、どうもデバッガがうまく動かない。
ブレークポイントで止まってくれない。
動きそうなんだけど動かないので、あれこれ試していたがやはり動かない。
ビルド周りなどまだまだ中途半端なので、C++ はやはり NVIDIA CodeWorks for Android(またAndroidWorksから名前変わった？ ) 使って、Visual Studio でデバッグする方がいいか。
Java だと Android Studio が便利なので、そちらは Android Studio でやりたいところ。
NDK のサポート早くまともになってくれないものか……
投稿者 Takenori : 20:35