独創アプリ開発日記 358〜362目 CONWAYのLIFEGAME 微妙な高速化バージョン

微妙に高速化しました。

ConwayのLifegameで一番処理時間がかかる部分は各”セル”の生死を決定する箇所です。

死んでいる状態のセルの回りに、ちょうど3つの生きているセルがいれば、その死んでいる状態のセルは生き返ります。
生きている状態のセルの回りに、2つか3つの生きているセルがいれば、そのセルは生を維持します。2つか3つ以外ならば死んでしまいます。

次回はこの部分をGPU(シェーダー)に処理させて高速化したいと思います。

独創アプリ開発日記 357目 conwayのlifegame 低速バージョン

今日は、CPUやメモリの効率無視で、とりあえず動くバージョンのライフゲームを作成しました。

このページです。

タップ/クリックする毎に処理量(ドット数)が4倍になります。ある程度以上のFPSが出ていなかった場合はタップ/クリックしても処理量が増えないように制限をかけています。

処理量を増やしていくと、どんどん速度が低下するのが分かりますね。明日からはこれを高速化していく予定です。

独創アプリ開発日記 356日目 OpenGLで一番難しいこと

今日は”点”の表示を行いました。

このページです。

中心に赤い点が表示されますね。これだけです。

・・・さて、みなさん、OpenGLのプログラミングで一番難しいのは何かお分かりでしょうか?

・・・実は、そう、実は上記のように、たった1つだけの点だとしても、その点が画面に表示されるまでが一番難しいのです。

図形が表示されるまでに乗り越えるべき壁は山ほどあります。

GPUに渡す頂点データは正しいのか?
頂点データを渡すAPIの使い方は正しく、APIの全ての引数はちゃんと正しい値になっているのか?(OpenGL関係のAPIは実に引数の数が多く、かつ内容がややこしいです。)
図形を描画するための頂点シェーダやフラグメントシェーダは正しいのか?
渡した頂点データとの整合性は取れているのか?
シェーダーの記述は正しいのか?
描画した図形の座標はちゃんと描画画面内に入っているのか?
環境による利用可能なAPIのバージョンはあっているのか?

etc etc etc…まだまだたくさんあります。

上記のどれか1つ、そう、たった1つでも間違っていると画面に何も図形が表示されない可能性が高いです。図形が表示されないと、どこが間違っているのかわからず悩みまくることになります。本気で悩みまくって数年単位で解決できないこともあります。大げさではありません。

例えるならば、1万人の大縄跳びを成功させようとしているようなものなのです。たった1回飛ぶのがとてつもなく難しいのです。

ですから今日赤い点を表示できたことは素晴らしい成果なのです。

さあ、そういうことを分かった上でじっくりこの点を見てみましょう。感動しますよね?

・・・

・・

いや感動しないな。単なる赤い点だな。

ʕ•̫͡•ʕ*̫͡*ʕ•͓͡•ʔ-̫͡-ʕ•̫͡•ʔ*̫͡*ʔ-̫͡-ʔ

明日から引き続き実装を頑張ります。

独創アプリ開発日記 327〜355日目 マインクラフトのベース

今回はマインクラフトをパクるために、マインクラフトのブロックベースの世界を構築するための準備を行っていました。

今回は新しいアプリを作るための準備として、WebGLを利用した動作テストを行っていました。

こちらがWebGLで製作した画面です。

なるべく少ないメモリで、また高速動作するよう、考えに考え抜いて作成したつもりです。頭の良い人はもっと効率の良い洗練されたコード書くと思うけど、私はWebGL/OpenGL初心者なりに頑張りました。

左上のアイコンをクリック/タップすることでフルスクリーンになります。顧客を軽視するMSのIEやEDGEを除くシェアの高いFireFoxやChrome,Safariのブラウザにおいて、良い感じにフルスクリーン動作すると思います。iOSではフルスクリーンが制限されており実現できませんが、ブラウザの領域全体を使って出来る限り大きな画面を描画するようにしています。

で、WebGLをある程度使ってみて感じたのですが、GLSLにもっと詳しくなれば、より高速でより洗練されたアプリが作れるのではないかと思いました。

そこで、新アプリの前にConwayのLifegameをWebGLで構築することとしました。今決めました。

だらだら作業するのも嫌なので、スケジュールを決めます。以下の実装内容は大まかなものです。実装途中でより良いアイデアなどが浮かぶと内容が変わってくると思います。

356日目:ポイントスプライトでとりあえず画面にドットを表示
357日目:とりあえずライフゲームが動く。ドットの大きさやエフェクトなど、各種設定値は固定。
358〜360日目:シェーダー(GLSL)を利用し、GPUでライフゲームを高速で動作させる。エフェクトなどはなし。
361〜363日目:エフェクトなどを考慮した上で、シェーダー(GLSL)を利用してライフゲームを高速で動作させる。
364〜366日目:各種設定値を指定するためのGUIのライブラリを作成する。これは、PCでもスマホでもどちらからでも容易に操作が可能とする。
365日目:ドットの大きさを調整可能とする。
366日目:ドットの色を変更可能とする。
367日目:ドットにイメージを指定可能とする。
368日目:ライフの状態変化時にエフェクト適用。
369日目:縦横ドット数を細かく指定可能に。
370〜371日目:セーブ機能の実装
372〜373日目:ロード機能の実装
374〜380日目:課金処理の実装(と、それに見合うプレミアム機能/エフェクトの実装。課金に見合う内容が出来るのか?)

・・・最後に課金処理の実装となっていますが、ライフゲームで課金してくれる人はあまりいないと思います。将来的な課金処理の実装練習的な意味合いが大きいです。でも課金してくれるほどのブラウザベースのライフゲームが出来たらすごいよな。世界初だよな。がんばろっと。