今日もテクスチャを貼る前提で頂点バッファとインデックスバッファを最小に抑える方法を検討していました。
結果、インデックスバッファは当初の予定通り15(区切り込み)ですが、頂点バッファは14になりそうです。立方体を2次元に展開すると、頂点数14になりますよね・・・
各面にテクスチャ貼る場合はどうしても頂点数8では済みませんでした。
★☆★ 次回の作業 ★☆★
最初の立方体『土ブロック』を完成させる。
uka.apple のすべての投稿
パクリアプリ開発日記 29日目 立方体へのテクスチャ貼り
三連休終わっちゃった・・・
三日前に戻りたいです。
立方体の描画ですが、GL_TRIANGLE_STRIPの場合、頂点バッファオブジェクトやインデックスバッファの数は減らせますが、立方体へのテクスチャがうまく貼れない気がしてきました。
今日は上手くテクスチャ貼ろうと色々頑張りましたがダメでした。
★☆★ 次回の作業 ★☆★
なるべくメモリ量を減らした上で立方体にテクスチャを上手く貼れないか考える。
パクリアプリ開発日記 28日目 objective-cからc++への変換4
バリバリ変換してました！
そして遂に必要最低限を除いて、iOSに依存しないコードが完成しました。
これでNintendo Switchにもアプリ移植できます。たぶん。
★☆★ 次回の作業 ★☆★
なにしよ。
パクリアプリ開発日記 27日目 objective-cからc++への変換3
まあまあ変換してました。
以下の処理がiOSに依存してしまっているので、C++だけで書けるように頑張っているところです。
GLKMatrix4MakePerspective
GLKMatrix4MakeTranslation
GLKMatrix4Rotate
GLKMatrix4Multiply
行列とかC++でライブラリ化するの楽しいです。
ここがクリアできればOpenGLの処理はほぼiOSに依存しなくなるので、簡単に他の環境に移植できる・・・はずです。たぶん。
★☆★ 次回の作業 ★☆★
まあまあではなくバリバリ変換する。
パクリアプリ開発日記 26日目 objective-cからc++への変換2
そこそこ変換してました。
★☆★ 次回の作業 ★☆★
そこそこではなくバリバリ変換する。
パクリアプリ開発日記 25日目 objective-cからc++への変換
objective-cからc++への変換コード量が思ったより多かったですが、今日もちまちま変換してました。
ほとんどOpenGLのコードなので、変換はそれほど難しくはないです。
どうでも良いけど最近Wordpress(このサイト)が重いです。どーでも良い日記を毎日つけて記事数多くなってるからかな・・・
それともさくらのVPSが重いのかな・・・
★☆★ 次回の作業 ★☆★
ちまちまではなくバリバリ変換する。
パクリアプリ開発日記 24日目 設計方針の決定
設計に関して、将来的にAndroidに移植したくなる可能性を考えて、そこだけ考慮するようにしました。
具体的にはメインとなる部分はC++で書いて、iOSに異存する箇所とそうでない箇所を明確に分離するようにしました。
こうしとけばiOSに依存しないC++のコードは再利用できます。
それ以外は作業効率を考慮して、ゆるい感じで作ろうと思います。
ぶっちゃけ作るのがメインで売るのは二の次的なとことがあるので横展開はあまり考えていません・・・
ダウンロード数も1000万位しか行かないだろうし。
★☆★ 次回の作業 ★☆★
バリバリコーディングする。
パクリアプリ開発日記 23日目
今日はホワイトデーですね。お菓子メーカーの商売根性に思いを馳せていたら一日が終わっていました・・・
★☆★ 次回の作業 ★☆★
設計作業で時間を使わないで素早く作業を終える覚悟を決める。
パクリアプリ開発日記 22日目
覚悟が決まりませんでした。
★☆★ 次回の作業 ★☆★
設計作業で時間を使わないで素早く作業を終える覚悟を決める。
パクリアプリ開発日記 21日目 プログラムの汎用性考慮
今日は、このアプリを将来にわたってどの程度使い続けるか、またどの範囲において使えるようにするかを考え、それに基づいて、タップやUIを扱うアプリーケーション層、OpenGLによるレンダリング処理、頂点データの生成ロジックなど各種処理について、その構成や相互作用などを検討し、どのようにすべきか悩んでいました。
例えばAndroidとiOSの双方に対応しようとした場合、Objective-Cで書くべきではなく、C++で書くべきです。Objective-CはC++と混在して記述できるし、C++にしておけばJavaからも呼べるようになります。
また、将来的にOpenGLがバージョンアップした場合、レンダリングエンジンをインターフェースでうまく疎結合にしておけば、最小限の範囲の手直しで新バージョンに対応出来るようになります。
・・・なんてことを考えていたんですが、多分将来はまた新しい言語とか予期できない仕様変更とか出てくるかもしれないから、あらかじめ準備しても全て無駄で、その度に１からやり直したほうがはるかに柔軟に対応できるし手っ取り早い気がしてきました。個人開発のアプリだし。
過去に自分が作成したプログラムも内容忘れてるからコピペレベルで書き直したほうが早いと思います。
iPhone初代が出たのは2007年6月で、まだ10年経ってません。10年前はスマホが存在しなかったんですよねえ・・・
あんまり先のこと考えてもしょうがないですよね。
★☆★ 次回の作業 ★☆★
設計作業で時間を使わないで素早く作業を終える覚悟を決める。