†DirectX11対応などが行われてコツコツバージョンアップが行われている模様。†2016年の7月現在においてBox2Dの最新情報は2015年の7月となっているようなので実に1年近く音沙汰がない。codeからgitにその公開場所を変えたようなので、コツコツ更新されているかもしれないので調べてみると大きな更新はここ数ヶ月~年単位でなさそうな感じではあるが、細かい修正は色々あるので、以前使っていた演算結果と異なる結果になることはあるかもしれない。wake)たとえばSleep中のオブジェクトに強制的に角度を渡したりする時にAwakeしないといけなかったのが、関数呼び出しの時に指定できるようになっている。デフォルト引数の対応とかではないので、ソースコードを一部改変する必要があった。これにより以前と動作がかわり不自然な挙動のキャラクタが1件発見された。これは以前たまたまうまく動いていたのか、今回の仕様変更で動かなくなったのか原因は未調査。コードの扱い方は少なくとも2015年に携わっていた経験者は2016年でも、扱いには困らないっぽい。新しいMotorジョイントができたり、限定的に演算結果を最適化したりしてる感じ。†http://box2d.org/からgitを辿ってソースコードをまるごとダウンロードして、適当なディレクトリに配置。gxLib的には「src/Box2D」に配置してリコンパイルするとあっさりコンパイル完了。使い方を忘れてそうなので、おさらいがてら復習してみよう。includeファイルはこれだけでイイ。box2dのこういうシンプルなところがとても好き。物理演算を管理するWorldの設定を行う。いっても重力値を設定してb2Worldをnewするだけ。);これでめくるめくような物理の世界の準備が完了。この物理の世界のスケール感のコツとしては0.1~10くらいの範囲で数値を扱うのが適切らしい。画面の端から端まで移動しても0~10くらいの座標で扱い、キャラの大きさは小さくとも0.1くらいで使うこと。ピクセルに換算すると、16x16のマリオを0.1として扱うとステージの終端は1600ピクセルくらいになるということである。1600ピクセルというと当時のファミコンの解像度で言うと約6.5画面分となる。実際のスーパーマリオの1-1は横に3400ピクセル程度なので、だいたいスターが出てくるアタリで1600くらいである。アレくらいのキャラの大きさとステージの大きさの限界をイメージしておくといい。それ以上にステージが大きくなったりキャラが小さくなったりしてももちろん動かすことはできるが、値が極端になると計算精度がどんどん悪くなるので注意。基本的に汎用のマルチプラットフォーム対応の物理エンジンなのでプラットフォームに依存するようなコードはない。いうことはプラットフォームやプログラムごとに異なる仕組みを持つ画面に何かを表示したり、文字を表示したりする機能は「ない」ということである。サンプルには表示できる仕組みがあるが、基本的にそこはBox2Dとは関係がない。コンソール画面上で物体の動きをあくまで数学的に計算するライブラリであり、だからこそ自分のシステムに組み込みやすいのである。gxLibでは、物理演算された結果を元に画面表示を行って動作確認したり、ゲームに組み込んでいる。概要としてはこの物理ワールドに、任意の四角形と丸を好きな場所に好きな角度で配置できると考えてほしい。自分で時間を進めることで、その図形の数秒後の移動先の位置情報を取得することができる。プログラム的には「こういう四角をここに置いて、その上に四角を配置して時間をすすめて、図形から更新された位置情報と角度を取得する」というイメージ。その時の図形に重さや反射率などのプロパティ(fixtureと呼ばれる)を設定することで図形が衝突した時の反射場所が変わる。その時にプロパティで「static」に設定したオブジェクトは「動かないオブジェクト」として障害物や床に設定することができる。その他、便利なのは、各オブジェクトを「ジョイント」と呼ばれる要素でつなぐことができることで、チェーン的なつながりや滑車などを再現できる。あとよく使うのはグループを設定して、当たり判定を取るものと取らないものの仲間を設定できる。「自機のショットは自機とは判定を取らないけれども、敵とは判定を行う」といったカテゴリわけである。くせがあるのでなれるのに苦労するが考え方はシンプルである。†あと、凹型にならなければ、自分で多角形を設定できる。(デフォルトで)渡せる頂点の数は決まっているので、超複雑な多角形は描けない。ソースのMAX頂点数を変更すれば頂点数を増やすことはできる。基本的にはできるだけ単純な多角形を作って各キャラごとに適当な図形に当てはめて物理演算するのがシンプルでオススメ。四角形や三角形と言っても、キャラや、キャラの部位によってそれぞれ形はことなるので、各キャラの姿形にあわせた、それっぽい多角形をつくる、MAPは三角形と四角形、丸を駆使してマップのオブジェクトを再現。しても必要なところだけ多角形に頼る、といい。各オブジェクトは反時計回りの頂点設定、凹型にならない、というところに注意。文中には補足とか経験談も入ってるので注意してね。++で作られた機能が豊富な2D剛体物理エンジンです。ゲーム大賞のグランプリを含む多くのゲームで使用されています。BOX2Dはzlibライセンスを使用しており、無料で利用することができます。可能であればBOX2Dを使っていることをどこかに書いておいてBox2Dの信用を広めよう。++を使用してWindows上で開発されています。Pythonに移植されています。++バージョンを保守し、他の言語をサポートしません。他の言語は、各コミュニティによって、おそらくそれらの移植版の作者によってサポートされます。作者は、それらの移植版からのフィードバックを受け付けてBox2Dの原動力としていきます。†わからないことがあった時。FAQの残りとドキュメントを読んでね。それと、ソースに含まれるサンプルを確認しよう。それでもわからない場合にはフォーラムを参照することができるよ。プライベートメッセージやメールで作者にサポートを求めないこと。フォーラムでディスカッションすることでみんなが問題を共有して解決することの恩恵を受けられることが最善の質問方法だと思うよ。†マニュアルが最良の情報源だけれども、利用可能なドキュメントがたくさんあります。†FAQからもう一つ。Box2Dを使った計算においては、別のプラットフォーム、システム上で同じ計算結果が出るとは限らないことを頭に入れておこう。Box2Dでは計算の基礎にランダムが絡むような要素を入れているわけではないが、各システムにおいて浮動小数点演算の取り扱い方が異なるため、必ずしも同じ結果が出るとは限らない。これはつまりCocos2Dなどでマルチプラットフォーム対応を行った場合でも同様で、macとWindowsで同じ計算結果にならなかもしれない。いうことは、macで作ったリプレイ機能や通信対戦において別の計算結果が算出されることにより、同期できない(違った結果になる)ということである。簡単に言うと、アングリーバードをiOSでプレイした時と、全く同じプレイをWindowsで再現した時に、オブジェクトの崩れ方に違いが出てクリアできるステージもクリアができなくなってしまう可能性がある、ということである。†とはいえ、プラットフォームに依存しない結果にしたいのはヤマヤマではある。固定小数点演算は遅く、開発するのがより面倒なのでBOX2Dのために固定小数点を使用しないことを採択した、らしい。†あと、衝突による正確な反発値には期待しないでね。同時に衝突するものを増やすほど精度が悪化するよ。計算結果を都合良く丸めるにはb2Settingを利用してください。要はビリヤードのブレイクショットなどで先頭の球から連鎖して全ボールへ衝突が波及するような場合に精度がどんどんわるくなる、ということだと思われる。物理シミュレーションをゲームで手軽にあつかえる高速なライブラリなんです、というところを意識しておこう。†とりあえず、FAQにある初心者のありがちなミス。32mで設定してしまうような場合を指すと思われる。Box2DにおいてC++の知識は当然いるし、プロジェクトの設定やビルド方法、デバッグの知識も最低限必要とあるが、これほど簡単に物理が扱えるライブラリは他にないのであわせてFAQもぜひ読んでおこう。