グラフィックプログラミングが大好き

グラフィックプログラミングが大好きです！ 私たちは皆、コードの設計と作成の過程で間違いを犯します。 これらは、ロジックのエラー（アルゴリズムが不正確に、または最後まで考えられない場合）、不注意から生じるエラー、および多くのより多くのオプションである場合があります。 そして、通常のワークフローではどうなりますか？ -リストに必要なエントリがありません。一部の数値が正しくないと見なされ、エラーメッセージなどが落ちます。 グラフィックプログラミングでは、すべてがもう少し楽しくなります。多くの場合、期待どおりの結果が得られないからです。 私の小さなプロジェクトでは、開発プロセス全体を通してそのような「結果」を保持することにし、それらをあなたと共有したいと思います。



Android、ライブ壁紙、Minecraft、自転車、トピックにあまり結び付けられていない意識の流れなどすべてが好きでない人は、この投稿の内容がそれらを混乱させる可能性があることをすぐに警告したいので、自分の危険とリスクで読み続けてください。 また、モバイルまたは単に無制限のインターネットのユーザーに警告をここに残します： 多くの写真が続きます 。

こんにちは

私は長年の経験を持つソフトウェア開発者です。 これは私の仕事が単調で退屈だと言うことではありません。 さまざまなレベルの問題を解決し、時には解決策を考え出し、時には自分でそれらを実装し、時にはシステムの脆弱性を探し、時にはモニターがコンピューターではない理由を伝えます。 おそらく、私はワークフローに少しの多様性と創造性をもたらすコーディングに従事しているだけではありません。



また、さまざまな問題（予算または開発時間が限られているか、上位コックの一部が間違った方向に突っ込んでいる）のために、私は多くのことの既製の解決策を探す必要があり、それが私の仕事をサイコロのある子供のゲームに変えます、「キューブにキューブを置く」必要があり、マネージャーが手をたたく様子を見る。 おそらくこれが私の仕事をルーチンに変えるものでしょう（はい、「キューブで遊ぶ」瞬間でさえ、私は通常、モニターはコンピューターではないと言い続けます）。 何らかの形でルーチンをエスケープし、簡単なものを実装する方法を忘れないようにするために、自由時間に「すべてを一列に並べて」プログラムするのが好きです。 そして、私はグラフィックプログラミングが大好きだと気づきました...

何言ってるの？

私は最初から始めますが、私が誰であるか、そしてなぜかについては余り話をしません。 新しい携帯電話を購入したので（ここではハブに関する記事の傾向がすでに迫っています...）、「ライブ壁紙」を設定したかったのは、 理由はわかりませんが、画面上で何かが動くと気に入っています。 おそらくすべての理由は、4コアプロセッサを搭載した電話機を購入したと思うからです。 私は店を歩き回り、スクリーンで見たいと思って、Minecraftのスタイルの何かが欲しいと決めましたが、残念ながら適切に私を喜ばせるものは見つかりませんでした。 それから私はすべてを自分でやることを決心する不注意を持っていました...

これに関する最初の疑い...

メインストーリーから少し気をそらし、「でも書く-自分のために何かできるなら」という考えに疑問を抱いた理由を説明する必要があります。 学年には、ゲームがコンピューターにインストールされ（最近知ったように、ゲームはBK-0010の「トレジャー」と呼ばれていました）、白人（誰が誰のために遊ぶべきか）が何かを収集していました（私の記憶では、まさにキーでしたが後で判明したように、それは胸だったはずでした）、そして黒人は何かのために本当に白人を憎み、タッチで彼を殺しました。 理由はわかりませんが、このゲームについての思いが懐かしい気持ちを呼び起こしたので、「でも自分で書きます」と決めました。



開発プロセスやその他の詳細についての話で退屈しないように（私の話はそれについてではありません）、私は単に意味を説明します： 書いた、それは私が覚えていたとおりに機能し、一度プレイし、終了しました デバッグのプロセスですでに「十分にプレイ」されています 。



興味のある人にとっての結果は次のとおりです。





ここの内なる声は、私が私の仕事の結果を使用しないだろうと私に言った。 開発期間中に彼を見すぎたが、いつものように、 「今回は絶対に起こらない」 （自己説得力、ハァッ）と決めた。 先に進み、内なる声は正しかったと言います...

そして、グラフィックプログラミングはどこにありますか？！

本編に戻りましょう。 私はすぐに、OpenGLまたはタスクを実現するのに役立つ他のものを使用しないことを決定しました。 さらに、JavaコードとAndroidのネイティブコードとの相互作用に常に興味がありましたが、ここでもこの問題を解決するための良い機会を見つけました。

私はすぐに、ネイティブライブラリを常に呼び出して、十分なフレームレートでレンダリングを実装できるかどうかを確認することにしました。 検証のために、次のタスクを実装しました-任意の「シェーディング」係数を持つ画像で画面を塗りつぶします（元の画像が可能な限り明るいと見なされる場合、基本的に輝度パラメータのみで）。 JavaおよびC ++のバリアントを作成しました。 私は両方のオプションをタイミングの大まかなテストで実行し、Java自体が「画面上」に完成したイメージを表示したにもかかわらず、平均してC ++オプションが少し速く動作することを確認しました。 写真として、私はすぐに、Minecraftの素晴らしいテクスチャの1つを撮影しました。結果は次のようになりました。





最初からすべてを自分で実装し、文献を覗いたり、インターネットで助けを求めたりしないと決めたため、私のイメージの端は次のようになりました。





明らかに、画像は正しく処理されず、そこから一部のみを描画する必要があり、修正しています...

したがって、問題は解決されています。つまり、ビジネスに取り掛かり、ソリューションと最適な実装を探し始めることができます。



実装にJNIを使​​用するソリューションを選択したため、結果として、開発は混合モードで行われました。 Windowsで基本的なロジックを作成してテストし、すぐに10画面の画像を生成しました（これらは記事の後半で説明する幅広の画像です）。時々、電話でソリューションを確認しました。

「結果」

それで、地平線（これまでのところランダムブロックでは、なぜランダムにしたのかさえわかりません。記事を書いているのに驚いています）：



大きな画像はクリック可能ですが、habrastorageはサイズをわずかに縮小しました（オリジナルは7200 x 1280でした）



ランダムなゴミから、意味のあるコンテンツに移ります。 地平線は「意味のある」ものです。





次に、レリーフがそれほど原始的に見えないように、「空洞」（表面のくぼみ）を作成する必要がありました。 なぜなら その時までに実装はまだ未加工でしたが、洞窟を作成するためのアルゴリズムの検証は、異なるテクスチャを持つ「空洞」の描画でした。





次のステップでは、すべてを前景と背景に分割し、背景のテクスチャを暗くしました。



すでに何かのように見えますが、それでも結果とはとてもかけ離れています。



テクスチャを変更し、下に光源-溶岩を追加することにしましたが、テクスチャを間違えたため、下部が「トーチで満たされました」：





別の光源を修正して追加します-トーチ：





前景と背景のブロックの比率が自分に合わないことに気付き、係数を変更しました。



今後は、このような結果を得るために何度も変更した部分であり、落ち着いてもう触れないように注意する必要があります。



光源を追加する目的は、より適切な照明-光源からの照明でした。 光源は3つのグループに分けられました。

1. 空からの照明。 最も明るい光源ですが、時刻の変更はもともと考えられていたもので、空からの照明は時間に依存します。
2. 溶岩照明。 日中は空より明るい光源ではありませんが、明るさは時間とともに変化しません。
3. トーチからの照明。 最も明るい光源。 明るさも一定です。

その結果、2つのパラメーターがブロックの照明に影響を与え始めました。空までの距離と静的光源からの距離です。



左側は光源からの光の広がりで、右側は単に「背景が前景よりも暗い」です。



ここで透明度が懇願し始めました、なぜならあなたは白い背景でトーチを残すことができないからです。 「問題は何ですか？」という質問を避けるために、いくつかの数字（ピクセル）と他の数字（ピクセルも）の配列があり、すべての転送ルールと描画ルールを作成する必要があることを思い出します。 透明性が必要でした-ここに透明度があります（もう少し透明度が高く、携帯電話のカメラから画像を描画して、十分に「透明」にする必要があります）：



修正しています...



背景を修正して、彼は誤って地球の洞窟を「塗りつぶし」ました。



これの一部は意図的に行われたように見えるかもしれませんが、すべての結果が偶然に得られたことを保証します。 実のところ、私はそれをどうやってやったかを言うのも難しいと思っていますが、結果はそれです。 これも修正します...



トーチ後のブロックの照明が誤って計算されます（トーチ後のブロックは隣接するブロックよりも暗い）：



間違いはかなり愚かですが、すぐにトーチが明るい場所にあるとは思わず、ブロックの照明がトーチの明るさの最大値であると考えました。 少なくとも2つの解決策があります-照明を修正するか、照らされた場所からトーチを取り除くことです。 照明を修正することにしました。



ここで、一意の「カード」を定義する文字列（シード）を指定できるようにする必要があると判断しました。つまり、乱数を生成する独自の実装が必要です（実際、通常のrandで十分だったので、必要ありませんでしたが、自転車をリクエストした）：



そして





控えめに言っても、かなり「偶然」でした。



次のステップでは、レリーフの外観を多様化するために追加のブロックが追加されました（このステップを見逃しました、すみません、写真がたくさんあります）。



木については、いくつかの単語を別々に言いたいです...開発プロセスの途中で、すでにコードにコメントがあり、紙にいくつかのメモがあり、スクリーンショットに1つのメモがあります。「i h8 3s」のようなものです。 それには理由がありました。 木はすぐに何らかの形で困難になりました。 あらゆる些細なこと、コードのすべての編集が必然的にツリーに影響を与えました。 一般的に、それがどんなに馬鹿げているように聞こえても、それが最大の破片だったのは木でした。



だから、木を使った苦痛の最初の繰り返し：



そもそも、木の幹と幹の上に葉を作ることにしました（これまでのところ、側面に葉はありませんでした）が、ここでもブロックを混ぜて、逆の結果を得ました。



私はエラーを修正し、側面に葉を追加し、再び間違ったブロックを追加しました：





結果として、木の数を変更した後、これは結果です：





それから私は、水平線を生成するためのアルゴリズムが私を混乱させること、そしてそれを修正することは良いことだと決めました。 結果はかなり予測可能でした-良いものはありません：





その後、多くの開発者にとって、問題の本質をあまり理解せずに通常のクイックフィックスが行われました（結局、このコードを書いたばかりなので、ためらうことなく修正できることは明らかです！）、これは予想どおり、肯定的な結果です結果はありませんでした：



不思議なことに、地平線は完全に平坦ではありませんが、最初はわずかに歪んでいます。



その結果、さまざまなパラメーターを試し、多くの結果が落ち着いて、水平線の修正について考えるのをやめました。 スカイラインの結果の一部を次に示します。





実用的なプロトタイプを入手したら、それをデバッグし、コードをクリーンアップして最適化を行います。 マジックナンバーを取り除くことから始めました。マジックナンバーのうち、テストの時点で、ほとんどのパラメーターが画面とブロックのサイズにリンクされていた約10でした。



そして、木はすべてを混乱させ続けました-地面だけで生成されることを確認する必要がありました、ボリュームが葉のいくつかのブロックに陰影を追加したためです（ちなみに、それまでに私たちが望むように機能しませんでした）：





影付きブロックをレンダリングする機能をデバッグすると同時に、その中の何かを最適化する必要があることが明らかになりました。 再び「エラー」の迅速な修正、再びかなり面白い結果：





それから私はすぐに気付き、何が間違っていたのか、新しい修正はすぐに待ちました：





ここでは、通常、このスタイル（つまり、「最初に書く、それから考える」のスタイル）でコードを記述しないことをすぐに予約する必要があります。 しかし、このプロジェクトでは、非常に面白いことがわかりました。 結局、私のすべての間違い、すべての愚かさは必然的に結果に結びつき、非常にまれにこの結果を予測したり、すぐに「なぜ」を説明することができました。



この時点で、葉と草（草のある地面）のテクスチャは特定の緑色でした。 色を変更できる実装が要求されました。これにより、ほとんど血を流さずに時間を変更できます。 はい、これはJavaで簡単に行うことができ、何も思い付かないことをよく知っていますが、スポーツへの関心は強すぎました。 これを行うために、テクスチャが変更され、「テクスチャをペイントする」関数が作成されました。





関数自体は数回修正する必要がありました。 彼女は混合三毛鯨の効果を作成しました（中央の2つの画像）が、必要なことはしませんでした（右の画像）。 アルゴリズムの結果は次のとおりです。





時々、コードを整理するために特定の方法を決定し、時々さまざまな結果を受け取りました。 別の例：





時々、デバッグの世界から非常に面白い状況が表面化しました。 たとえば、グラデーションの描画エラー（マルチカラーストライプの別のジェネレーター）：





このエラーのデバッグ中に、アイデアがすでに私にとって使い果たされ始めたとき、デバッガーは次の色の値を生成しました。



その日、私はデバッグをやめて、デバッガが食べ物の質の悪さについて話すのをやめるように休むことにしました。



この時点で、電話で結果を同時にテストすることにしました。 電話では、色の順序が少し異なることが判明したため、赤と青のコンポーネントの色が場所を変えました。





ところで、私は木が嫌いだということをもう一度思い出すのを忘れました...木は夜に奇妙に振る舞いました：





現時点では、携帯電話は一般に、シフト（指でスクロール）した後に画像を描画する方法について独自の見解を持っていました。

そして



さて、左の写真の色は青と赤のコンポーネントの位置を忘れたためです。しかし、トレンディなモーションブラーエフェクトは、アルファを考えていなかったため、画像を正しく描画したという事実に既に「感謝」アンドロイドです。チャネル（その時点までのアルファチャネルには、何でもある可能性があります）。



ところで！ 長い間、私はあなたに私の木を見せませんでした！ ここに：



ここにはいくつかの問題があります-葉のいくつかのブロックの誤った照明と、「透明なピクセル」の誤ったレンダリングの両方。



並行して、ウェイポイントのシステム、または簡単に言えばパスを見つけるためのアルゴリズムの作業を開始しました。 ゾンビや他のキャラクターを追加できるようにするためにパスが必要でしたが、同時に、その行動を毎回数歩進めて計算する必要がありませんでした（そのため、彼らは馬鹿になりませんでした）。 私にとっては、アルゴリズムの品質を評価するために視覚的にパスをマークし始めました。





視覚化のより高度なバージョンは次のようになりました。





ちなみに、結果としてゾンビを追加しませんでした（手が届きませんでした）が、ウェイポイントシステムをデバッグしました。 これら2つの写真の樹木に注意してください。 木はまだきれいに見えました...



ある時点で、木の外観を修正しようとすると、別の「ポジティブ」な結果が得られました。





以下に、透明度に直接関連する電話からのさらに興味深いバグをいくつか示します（アルファチャネル）。

そして



次に、追加のテクスチャの追加（およびテクスチャインデックスの変更）によりエラーが発生しました。





次に、描画アルゴリズムで何かを「修正」し、かなり奇妙な効果を得ました（おそらくテクスチャのサイズと位置を台無しにした）。





レンダリングアルゴリズムの最新の最適化の結果、私は一度に2つのエラーを受け取りました（再びミンククジラ）。

そして



この奇跡を描くプロセスは次のようになります（明らかに、これが最適なオプションです）。





実装する必要がある最後のことは、ボリューム（ブロックの端）の影響であったため、画像はそれほど平坦で単純ではありませんでした。 顔については、画像のサイズを変更するアルゴリズムと画像を傾けるアルゴリズムの2つのアルゴリズムを記述する必要がありました。



画像のサイズを縮小するアルゴリズムから始めます。





上から下-アルゴリズムの結果。 一番下-望ましい結果（わかりやすくするために、テストは全体像で行われました）。



ローテーションアルゴリズムはより明確になりました。





左上には初期画像があり、右下には目的の結果があり、中央には結果への途中で得られたすべてのものがあります。



アルゴリズムの準備ができたとき、ボリュームの作成はすでに非常に簡単でした。 ブロックは3つの面で構成されていました（片側から見て、擬似3Dまたはいわゆる2.5d）。 美しさのために、線形グラデーションが境界に適用されました。これは、望ましい結果を得るためにデバッグする必要がありました。





ブロック面のサイズを判断できなかったため、このパラメーターを変更できるようにしました。





すべての変更の後、描画する必要のないものを描画しないように、描画プロセスを最適化する必要がありました。 この最適化の結果は、電話でのテスト中に浮上した透明度チャネルの問題でもありました。 結果がかなり奇妙に見えたことを認めなければなりません：

そして



このエラーの修正により、それほど興味深い効果は得られませんでした。

まとめ

最終的に、重大なエラーはすべてデバッグされ、エフェクトの形でテクスチャとパンが追加されました。 ストアの2つのバージョンが作成されました-無料（非常に単純化）と有料（すべての特典付き）。



私はこの記事で技術的な側面さえ上げないことにしました。 だから、誰かがそれを最後まで終わらせるかどうかはわかりません。 この記事をマスターした人がこのストーリーの技術的な側面について知りたい場合は、コメントまたはPMに書いてください。私が遭遇した困難、実装機能、およびその他の詳細について間違いなくお伝えします。



これにより、既成のフレームワークとライブラリを使用するだけでなく、他の誰かが自分の手で何かを作成するようにプッシュされることを願っています。



記事の最後まで読み通してくれた人々にも感謝します！