FPSを作ってみる@wiki
03)
最終更新:
slice
-
view
(2015/03/27)
また期間が空いた。
プログラム
履歴をみるに、当たり判定とそのテストコードをひたっすら書いてたみたいだ。
当初は効率優先でtemplateを駆使していたのに結局インタフェースを導入して
判定時に物体の形状(円や線分など)をIdで識別、
対応する関数を呼び出し(専用のルーチンが用意してあればそれを、無ければGJK)、
階層構造を持っていれば順次展開して〜とかやってると
設計がどっちつかずでビミョーな気がしないでもないが…
判定時に物体の形状(円や線分など)をIdで識別、
対応する関数を呼び出し(専用のルーチンが用意してあればそれを、無ければGJK)、
階層構造を持っていれば順次展開して〜とかやってると
設計がどっちつかずでビミョーな気がしないでもないが…
一応形状が予めわかっている場合のルーチンも用意はしてある。
が、これでどのくらい速くなるかといえばオブジェクトが1000個以上やモバイルCPUでもない限り誤差で終わりそうな。
が、これでどのくらい速くなるかといえばオブジェクトが1000個以上やモバイルCPUでもない限り誤差で終わりそうな。
そもそも何でこんなに当たり判定を詰めてるかといえば確か
- 2D剛体物理をやる際に個々の姿勢や形状を含めて管理する機構が必要だよね
- っていうか当たり判定にテストコード無いのは不味いよね
- テストコード書いてみたらバグが出る出る…
ついでにこんな(古いコードの)クラスじゃ階層構造とか無理だろという。
当たり判定ライブラリの半分くらいは作り直したかもしれない。
当たり判定ライブラリの半分くらいは作り直したかもしれない。
現在、総当たり形式でオブジェクトの衝突フレーム数をカウントするマネージャクラスのテストコードを記述中。
絵
時事ネタをやろうとして、今やってる絵を差し置いて描こうとするまではいいんだけど
手抜きが下手くそ過ぎて背景までキチッと書き込んでしまい
結果時期を逃すわモチベもだだ下がりだわで死ぬパターンが多い。
描きかけが増え過ぎた(10以上?)ので進行度の低い物を幾つかリストラして
メインを含め4つ程度に絞った。
3月中に1枚完成すればいいねといったところ。
手抜きが下手くそ過ぎて背景までキチッと書き込んでしまい
結果時期を逃すわモチベもだだ下がりだわで死ぬパターンが多い。
描きかけが増え過ぎた(10以上?)ので進行度の低い物を幾つかリストラして
メインを含め4つ程度に絞った。
3月中に1枚完成すればいいねといったところ。
(2015/03/03)
バッテリーウィジェットのアップデート公開
物自体は昨年の11月(!)に出来てて、一応この日誌で配布していた
Androidの自作バッテリー残量ウィジェット(のアップデート)。
バナーとアイコン描いてから新しくGoogle Playで公開しようと思っていたら見事にずるずると来てしまったので
昨夜スクリーンショットほぼ全部と説明文コピペという荒業を駆使し、半ば無理やり公開。
Androidの自作バッテリー残量ウィジェット(のアップデート)。
バナーとアイコン描いてから新しくGoogle Playで公開しようと思っていたら見事にずるずると来てしまったので
昨夜スクリーンショットほぼ全部と説明文コピペという荒業を駆使し、半ば無理やり公開。
DigitalCube Battery Widget(Google Playサイト)
新しく追加された要素はバッテリーの温度と電圧の表示、充電時の演出くらいな物だが。
いや…そういえば今度はAndroid2.3.3でも表示がバグらない筈だ。直したので。
今2.3.3系を使ってる人は全体で1割居るかも怪しくて、まぁどうでもいいっちゃあいい。
新しく追加された要素はバッテリーの温度と電圧の表示、充電時の演出くらいな物だが。
いや…そういえば今度はAndroid2.3.3でも表示がバグらない筈だ。直したので。
今2.3.3系を使ってる人は全体で1割居るかも怪しくて、まぁどうでもいいっちゃあいい。