約 600,599 件
https://w.atwiki.jp/slice/pages/142.html
(2015/12/26) Deferred Lighting だいぶ遅れてしまったけど予定通りDeferred Lightingによる影付きライトを実装。 一応前にやってはいたのだけどあの時は内部実装がこんがらがってて影無しだった。 しかし実装してから言うのもアレだけど、 メジャーな問題点としてよく挙げられる半透明のポリゴンは依然としてソートの上で奥から描画しなきゃならないし、 その時は勿論Forwardなのでエフェクトを多用するゲームには出番が無いかもしれないね… まあいいか、次は水面でもやろうかね。 他所の子 本格的に他所の子を描いたのは初かな？ ナギシュータ（TwitterID @LIxE_lie）さんとこの歪獣という種族（？）なのだけど、 まさかの3枚組。 思いつきでやってたらどんどん規模が大きくなって死ぬかと思った。 つるぷにの、ヌメヌメですね。 (2015/12/14) 進捗だけ報告。 バンプマップをサクッとやるつもりが接空間を求めるのに四苦八苦してた。 確認用の描画とかやったり。 更にそれのバグとか。 まあ最終的には出来たんだけども。 何に詰まってたかといえば、UVマップがミラーリングしてる場合に接空間も反転するよね - 面ごとに計算した接空間を頂点で合成するわけだけど、 反転してる座標系を足しあわせたらどちらの座標系も表さない変な方向指しちゃうよねって事。 これって結構メジャーな問題のようで、古くはDoom3やFarCry初代の時代から言及されてるようだ。 まぁつまり解決法はあると。 http //www.crytek.com/download/Triangle_mesh_tangent_space_calculation.pdf という訳でこれを淡々と実装しただけ。 早い話がUVが急激に変化してたり判定してるとこは素直に頂点を分割（複製）しましょうねと。 えっちょっと待った。前にバンプマッピングした時は？ と思ったら、たまたまそういうメッシュを作ってなかったかいきなりテクスチャ貼り付けたから 気付かなかったんだろうね。当時適当だったからね。 すこしソースを整理したら次は予定通りDeferred Renderingに入りたい。 (2015/12/09) バイラテラルフィルタ。 一言で言えばエッジをぼかさないガウスフィルタである。 水彩画っぽい感じにはなるがこれ単体でというよりは 例えばSSAO(Screen space ambient occlusion)をやる時にノイズが載った演算結果を平滑化するとかの中間処理で活躍しそう。 暫くこんな調子でシェーダーの復習が続く予定。 次はバンプマップかなー、でも今ForwardRenderingだけど近いうちDefferedRenderingに移行したいから Forwardも程々にしときたい。 (2015/12/07) 何の変哲もない、普通のキューブマップシャドウと 前に一度やってた、これまた論文通りの分散シャドウマップ つまり今回も特出した結果は出せていないという事だが、まあ中身は色々変わっているので自分的には良し。 この調子でバンプマップ、視差マップ、水面、ライトブルームといった感じで復習を進めていきたい。
https://w.atwiki.jp/slice/pages/31.html
エリア別の判定(2008/07/02) 的のエリア別の判定ってどうすんだろう？って疑問というか課題が以前からありまして。 真ん中撃ったら高得点でその周りはそれなりでという感じの。 的が円形だったら中心点と着弾点との距離を求めれば出来そうだけど、人の形の的だったらどうすんの？と。 まさかその形のポリゴンを配置するわけにはねえ。面倒だし。 じゃあ何だ、エリア判定用のテクスチャを用意しておいて着弾したら着弾したポリゴンの情報を持ってきてUV座標を自前で求めてエリアテクスチャ（ビットマップ）をこれまた自前で読み込んでさっきのUV座標でサンプリングするってのはどうだ？と。 結果を申し上げますとうまくできました。あでも、計算効率の云々はナシで。 その苦労の様子をスクショのページに幾つかあげておく。 小中学校でやるような直線と直線の交点計算で一苦労、UV座標を特定するのに二苦労と。 プログラム組むくせに数学がダメってのもなんだかなあ・・・ 近いうちに数Cと数3をマスターしてリベンジしてやるぞ。 逆に言えば数学殆どわからなくてもベクトルの内積外積と行列と補間がわかれば結構イケてしまう物ですよ。 内部処理(2008/07/05) ちょっとギミック追加。 スイッチを押すと確認のために射撃の的が近くまで移動するやつ。あれです。 やっとスクリプトが使えるようになったか、ならないかって感じ。 それだけなんだけどいつもの様に苦戦。 スクショ撮っても静止画じゃわからんし。もういいさどうせ見た目変化ないですよーだ 動画の事(2008/07/06) 前のから2ヶ月以上経ってるし えーかげんに動画あげたい！ が、見た目で変わった事といえば的を撃ててスイッチ押したら的が手前に動くようになっただけだ！ あとは銃と手の同期もしたな。 デバッグ支援機能として変数エディタ＆モニタも実装したな。 結構加わってんじゃん。 じゃあ作れよって感じなのだが、これがなかなか。 自分的には一つの動画に全力を注ぐスタンスでやってます。 当然作り終わったらバタンです。 それはたとえば動画を見ていて飽きないようにテンポ崩れてないかチェックしたり 印象に残る場面を設定したりネタを仕込んだりといった事。 動画の流れも何回か練り直したり。あんなのでも修正に修正を繰り返した結果なんですよ。 あ、3番目の動画でストーリー付いたかな？という雰囲気だけどあれ全部動画作る際の思いつきです。 この機能が実装されたからあんなことが出来るな、じゃあそういう話にしようみたいな。 そしてこれからもストーリーはすべて思いつきでやっていこうかと。 話が矛盾していても展開が強引でも知らん。 ちなみに動画の尺も一つ3分前後にしようと決めています。 自分の直感でこの長さになりました。このくらいがダレずに見られるかと。 ドアドア(2008/07/08) ってことで自動ドアを作ろうかと模索中。当分は開けたドアがキャラクタに衝突することのない スライド式の自動ドアで。処理が簡単そうだし。 単純に考えるとキャラクタが近づいた時点で開ければ良いだけだけど。 やっぱりやるからにはロックされてたら開かないとか、片方開いたらもう片方は閉まるといった ギミック的な物をやりたいわけですよ。 そんな処理を自作スクリプトでやるつもりなんですが。 ちょっと凝った仕掛けをランダムマップでも取り入れたいので。 まだ仕様を考えてる最中なんでなんとも。 考え事だけ(2008/07/09) 今日は自動ドアの衝突判定の管理とかを思案してただけなんで、プログラムやモデルは一切弄ってませんでした。 したがって進んでないっていうか。 あとはgame programming gemsっていう有名と言えば有名な本をパラ見。 この本は今は6くらいまであったハズですが1と2の2冊しか持ってません。 だって結構するんですよ。一冊12000円也。その分内容も濃いわけですが。 役に立つとはいえなかなかポンって買う気にならんよな。 英語版だと半額くらいなのだが。日本語でも理解に必死なのに英語だとどうなるんだと。 試しにGPU Gemsの英語版買ってみたら辞書があれば割と読める感じだったから前者のほうも大丈夫なんだろうか・・ 自動ドア続き(2008/07/11) はい、自動ドアの続きでございます。 実装中。。 主人公はじめその他のキャラが一定範囲内＆キャラとドアをつないだ線分が壁に衝突してない時に開く、と。 衝突判定の管理がずさんなせいで軽くコードがスパゲッティしてるなあ。 まあ今日も夜中まで頑張りますよ。 私のゲームに対する諦めの悪さは一級品だ。 無題(2008/07/12) 自動・・・ドア・・・・（バタッ） まだだぁーまだ終わってなぁあぁああっぁぁぁあい ごめん今日はあんましやる気出ないっす。って誰に言ってんだか。 やる気ない日でも少しは作業してるけど高が知れてますね。まあいいか。 自動ドアがもう終わりそうなので次はスイッチかな。 ボタン押したらボタンが凹むとかどうしようかと。 Frieve Editor(2008/07/14) なかなか仕様が定まらないときは大抵何が問題点なのかがハッキリしてない場合が多いので 自分の思考をまとめるのにFrieve Editorというツールで、マインドマップの様な手法を使ってます。 どんな見た目のツールかはスクショのページに無断リンクもあります。 フリーソフトなんで興味を持った人はどうぞ。 このツールの前はFreeMindっていうこれまたフリーソフトを使っていたけど 一度間違ってノードを全消ししてしまい、更にそのまま終了したら勝手に上書きセーブされてて 上書きするなら確認メッセージぐらいだせよとかキレた事があるので変えました。 射撃練習用の的(2008/07/18) 要するに射撃の的が左右とか色々動くようにしたい。 的の種類も何種類か用意したい。 今回はマップは固定で、的が出る場所とか順序は今後のランダムマップの布石にとランダムでやってみたい。 まぁそういうことです。 的のグラフィックは、へたくそながら描きました。白黒の線で書かれたベクターグラフィックスみたいの。 ここ2日の作業はそれです。 一種類でいいじゃんという意見もあるかとは思いますが。 問題はどうやって的の出現パターンをランダムにするか。 今考え中・・ 射撃場マップ(2008/07/19) 予定している射撃場っぽいマップですが・・ 今回はマップ自体は固定で行こうかと。で的の出てくる場所とか的のタイプをランダムにしようと。 後々ランダムな割合を増やしていく予定。いきなり全部という訳にはなかなか。 動画だけなら面倒なことせずに完全固定のスクリプトで良い気がしますが リリースの時にチュートリアルモードとして搭載する野望もあったりするんで。 でもプログラムを配れる日はいつになるやら。 射撃場イベント(2008/07/20) 自作スクリプトの仕様追加とか。 どうも射撃場の的がランダムに出てくるイベントを作るのに必要っぽいので 変数形式にリスト（配列みたいの）を追加してみるつもり。 FrieveEditor上で作業してただけなんでこれから実装ですよ。 色々追加してると思う事。 スクリプトの拡張をしすぎて「んじゃあC言語で書けよ！」という事態だけは避けたいな・。 SCWebCam(2008/07/21) たまに作業中のデスクトップの画像が半リアルタイム更新で置いてあるホームページを見かけることがあります。 面白そうだから自分もやってみようか。作業中のさぼり癖が防げるに違いない。 とはいえうっかり個人情報とか表示しようものなら・・とか思うと怖い物があるのは事実ですが。 ネットでそれっぽいソフト探したらSCWebCamっていうフリーソフトがあるようだ。 動作は単純で、設定した時間ごとに自動でデスクトップをキャプチャしてその画像をFTPサーバにアップするだけ。 後はアップした画像をホームページなり何なりにタグ記述。 大学の研究室や会社とかで部屋全員のデスクトップが一覧で見れるページ用意してこれやったら面白いだろうな。 強制されたら嫌ですけどね！あくまで自主的に参加の形で。 で、自分がやるとしたら土日だけにしようか。 そのうちページにさりげなく張って飽きたら削除しそうだけど。 自作Cam(2008/07/26) というわけで、自作してみました。 一定間隔でスクショ撮ってサイズ縮小してJPEGに変換後にFTPサーバに送信するプログラム。 一番苦労したのは縮小処理ですね。 lanczosアルゴリズムを使用したのは良いけれど結論を先に言うと係数設定が不適切で 最初はニアレストネイバーみたいになってしまって全然綺麗じゃ無かったんですが、 試行錯誤の末になんとか手持ちのPhotoImpactのバイキュービックに近い結果が出せました。 lanczosの補完関数にsin()を使っているので速度が微妙っぽいですが、 当分は自分で使うだけなので最適化云々はそのうちでいいかと。 先が見えない(2008/07/29) 今日も今日とてチマチマと作業を続けるわけですが。 なんか全然ゲームできてる感じがしない。作業自体はこなしているのだけれど。 作業を階段に例えると理想としては階段が均等な段差で ある程度作業したら結果が出てという感じで一歩一歩上っていけるといいんだが、 な～んか今の状態だと10cmの段差があったと思ったら次は背丈ほどの高さがドカンみたいな。 非常にムラがある。 うまく作業を割り振ってコンスタントに目に見えて結果が出せるようにする能力(なんだそりゃ)が欲しい。 良いぞ(2008/07/31) ここんとこ連続熱帯夜だったから今日は久々に涼しくて良いぞ。作業が進む。 作業は進むけどスクショは出ないぞ。見た目かわらんからなぁ。 的を事前に設定した何種類かのランダムな座標にこれまたランダムな的の移動パスを割り当て 的が移動した後にパタンと倒れて消えるってトコまで出来ました。 相変わらずメモリリークありますがね！的を作るごとに微妙にメモリのゴミが。。 直そうとちょっと頑張ったけど今頑張るとムダにコードがスパゲッティになるからやめた。
https://w.atwiki.jp/slice/pages/9.html
関連ブログ @wikiのwikiモードでは #bf(興味のある単語) と入力することで、あるキーワードに関連するブログ一覧を表示することができます 詳しくはこちらをご覧ください。 ＝＞http //atwiki.jp/guide/17_161_ja.html たとえば、#bf(ゲーム)と入力すると以下のように表示されます。 #bf
https://w.atwiki.jp/slice/pages/128.html
(2015/02/27) 当たり判定 当たり判定マネージャのコード読んでコメント加えたりした。 んー、とりあえず変にメモリ節約を意識しちゃってるせいで読みにくいわ、メソッド名が紛らわしいor意味が通ってないわで微妙な印象。 その割にはあんまり速度的な貢献が無さそうなとこが、ねぇ あと常識的に考えてビックリだけど当たり判定ルーチンにテストコードがついてない。 いや、2年前だから当たり判定に限らずテストコードを書く習慣自体なかったんだけど。 今これは不味いよなぁ… すぐどうにかしなければ駄目というものではないけどGoogleTestで使う部分、2DのGJKのテスト位は書いておきたい。 ま、そんなとこです imageプラグインエラー ご指定のURLはサポートしていません。png, jpg, gif などの画像URLを指定してください。 (2015/02/26) 2年前 絵のほうばかりやっていて、と思われてそう（いや、半分くらいその通り）だが ちゃんとプログラムの方も進めている。伸び伸びになってる剛体物理に向けて… で、今はコリジョンを管理するコリジョンマネージャの整備をしている。 コリジョン関連のコードは履歴を見るとまともに機能追加したのが実に2年前（！）で、 当然内部動作など覚えてなかったのでざっくり読んだ所、同じようなインタフェースを複数定義していたりまどろっこしい書き方になっていたりと設計の無駄が多いと感じた。 まずはコードを読みながら使える部分の取捨選択とコメントの付加。 大量の物体を出す予定はなく、物体を円で衝突判定した上で個々の詳細判定ができれば十分なので今はそこまで出来ればOKとしたい。 imageプラグインエラー ご指定のURLはサポートしていません。png, jpg, gif などの画像URLを指定してください。 (2015/02/12) 以前「漫画は手間かかるから、やるとしたら線画の4コマかな」と言った通り、4コマを描いた。 前々からやろうと思ってたネタが丁度twitterでお題だったので、丁度いいなと。 絵自体は白黒だし特に書くこともないが吹き出しと活字を使ったのは始めてで、 魅せ方を考えるのも結構難しかった。 あと前回の反省を踏まえ、如何に絵を使いまわすか？という事も視野に入れた。 4コマといえど全部描いているとそれなりに時間かかってしまうからねぇ‥ 今回はまんまだったが次は人物だけとか、素材に拡大縮小回転を加えたりとかで部分的に使いまわすのにも挑戦したい。 (2015/02/08) 背景にドラゴンいるやつとは別にまた新しく絵を描き始めてしまうという。 なんか、その日の気分で進める気になったりならなかったりするんよね。 ひたすら絵を描いていると特に自分の場合 色々付け足して無駄に分量が増える＝一枚の時間が長くなる 傾向があるようで （絵に限ったことではないのだけど） そういった時にずっと同じ絵で作業してると飽きてしまう。 飽きたらどうするかと言えばプログラミングを進めるか、描く対象の資料集めや練習と称して適当な写真の模写を始めたりする。 で、模写をしている内にふと 「写すだけもなんだし、ちょっと角度変えてやってみるか」 「背景も足してみようか」 等と思いつき、色々やってると最終的に 「折角だからシチュも考えて一枚の絵にしてみようか」 となる訳である。というか、今までのデジタル絵は殆どこのパターンだったりする。 例えば一番最初のエレビッツ、あれも最初は一匹だけのつもりだったし wheatleyも、虎さんもそう。 ヌマクローに至っては漫画しかも2ページになった。 まぁ、漫画形式はあの件で懲りたので当分無しとしても 描いてる本人にさえ予測できないとこがなんとなく面白いので 今後も思いつき方式でやっていきたい。 大体「あ、やばいこれ描いたこと無い」 - （資料集め）- 「むずい」- 「練習しないと」- （別の構図が浮かぶ）- （そっちを描き始める） とかなって 時間かかるけど… 現状： 気力的に完成まで漕ぎ着けそうな物がモブドラゴンの奴と、今やってる奴の2枚。 その他怪しい物が4、5枚。 ゲーム ちょこちょこ一応進めてはいるがお察しください状態。 imageプラグインエラー ご指定のURLはサポートしていません。png, jpg, gif などの画像URLを指定してください。 (2015/02/01) 前にも書いたけど、ここ最近絵の方が楽しくて困る。 純粋に描く楽しさと言いますか。 描くという行為自体も、元となるシチュエーションを妄想するのも楽しい。 プログラミングもね、最初は絵と同じように自分の書いたプログラムが動くだけで楽しかった。 でも、何年かやってれば腕前はともかく自己評価が「できて嬉しい」から 「まぁ、この位は当然だよな」みたいになる事が多くって、 モチベーションが中々上がらないのも事実。 たまにC++のリファレンス見て勉強したりもするけど若干の義務感も混じってたり。 プログラム ま、それはそれとしてプログラミング関係で現在取り組んでる課題としては 自作ライブラリで「とりあえずゲームループを動かす」だけ等の、 簡単な事をするのが簡単に出来ないという事。 自分で言うのもなんだがリソースのパス登録から始まりゲームスレッド用のアップデート関数に描画スレッド用の関数、 ゲームシーンクラスの定義と、とにかくお膳立てが多い。 これらは全くの無駄な記述という訳ではないんだが、初めてWin32APIを勉強した時のような 「ウィンドウを開いて単色で塗りつぶしたいだけなのに何で100行近く書かなきゃならんのだ」というアレに近い。 動作のカスタマイズに対応する為に色々設定できるようになっているものの 実際問題そんなに使われないので結果、シンプルさを阻害する役にしか立ってないという。 カスタマイズ用の関数なんて普段は存在すら意識させず、カスタマイズしたいと思った時に調べられれば良いのだ。 そんな訳で実は以前にヘルパークラスを用意してはいた。（prochelper.hppが一応それ） しかし自分で試しに使ってみた結果、ヘルパークラスのヘルパークラスが必要なようだ… 絵 多分みんな同じような感じだろうと思われるが、下書きばかり溜まってく現象が発生中。 絵の工程が大まかに 下書き、墨入れ、塗り という流れだとすると やっぱり無から有を作り上げていく下書きの段階が一番テンション上がる作業な訳で、そこで満足してしまう部分はある。 まぁ最後までキチッと完成させるのも大事で、仕上げたら仕上げたでやってよかったとなる物だけどそれなりの時間はかかるし。 現時点で下書きは5枚ほど。 このうち完成に漕ぎつけられるのはどれくらいかわからんが、折角だしちゃんと体裁を整えてから公開したい。 imageプラグインエラー ご指定のURLはサポートしていません。png, jpg, gif などの画像URLを指定してください。
https://w.atwiki.jp/slice/pages/115.html
(2014/03/30) で、でた〜、色々手を出して進捗してない奴〜 Blenderを触る 自分が持ってる3ds maxもなんだかんだ言って古いバージョンだし 前々から気になっていたBlenderというソフトはどうなんだろう・・という事で、ちょっと触ってみたり。 まだ初日だから何も言えない。無料のソフトとしてはかなり高機能（元々売ってたのを有志で買い取ったとか、なんとか・・） 中でもスカルプト機能がお気に入りで適当に土を盛ってるだけでも楽しいが、ちゃんと作ろうとすればムズイだろうな。 本当に触っているだけなので本格的に使うかは不明 非同期ファイル読み込み ファイルの拡張子でリソースを判別して読み込むだけのはずが、シーンごとのリソース管理を考え始めていつの間にか別スレッドで非同期読み込みをしていた。な、なにを言ってるか（略 いつの間にか前のプログラムが動かなくなってた 多分環境を構築しなおしたせいだろうけど、 OpenALでサウンドデバイスが開けないとか（OpenALのビルド時にALSAやpulseaudioのヘッダなどがインストールされて無くて無効になってた） ビデオドライバがOpenGLに対応していない（SDLを最新のリビジョン取ってきてビルドし直したら動いた。よくわからん） PNGやJPEGが開けない（SDL_imageのビルド時にバージョン決め打ちでlibjpeg8がリンクされていて、こっちのブログラムではlibjpeg9がリンクされエラーになってた。pngも同じ） あと、エフェクトファイル（HLSLにおけるFxファイルみたいなの）の文法変えてないしファイルもそのままの筈だけど 実行時に文法エラー出る。直さないと。 なんか、土台ばかりやってて全ッ然ゲーム制作してないね。 始めてもないじゃん、という・・ (2014/03/20) Android対応も一段落し、スクリプト制御のオブジェクト生成やらシーン管理やらは動いてるので ここらでサウンドでも鳴らしてみるかーと、思ったらそのような物が無かった。 そもそもリソース周りをどういう設計方針で行くか忘れかけていたのでもう一度確認してみる。 リソース自体はスクリプトからアクセスできず、あくまでハンドルを扱うのみ モデル描画したりサウンド鳴らしたりなんてのは専用クラスに任せる シューティングならシューティング用に設計したサウンドクラス等 リソースをファイルパス指定で1つ1つ読んでいたのでは管理が大変なので別途ファイルにリソースブロックとして記載し、これをインポートして一括読み込みする 「別途ファイル」もLua形式であり、単なるテーブル(配列)にURLを文字列で並べるだけ 2ブロックの差分とって必要なリソースだけ追加読み込み対応の予定 -- Resource.lua -- リソースブロック定義 Block = { modelA = "path/to/modelA.mdl", modelB = "path/to/modelB.mdl", seffect = "sound0.wav", music = "music0.ogg", -- あと色々 } -- Main.lua -- リソースブロック読み込み local block = ResourceManager loadBlock(require("Resource.lua").Block) -- 敵モデルをセット enemy.setModel(block.modelA) -- block.modelAには"path/to/modelA.mdl"のリソースが入ってる -- サウンド再生 soundmgr.play(block.seffect) -- block.seffectには"sound0.wav"のリソースが入ってる で、リソースハンドルが格納されたblockテーブルは通常、Sceneクラスが持っていて場面によって必要なリソースを読み込むと。 別にリソースのリストだけ別ファイルにせんでもSceneクラス定義に一緒に書いてしまっていいかもしれない。 そんな感じかねぇ。あとはやってみないと分からん。 (2014/03/17) clangとAndroid 先週辺りから自作プログラムをAndroid用にコンパイルする試みを、ずっとしている。 Boostに始まり各種libogg, libfreetype2, libSDL2...なんかのライブラリをビルドし うっかりOpenGL ES2には無いAPIを使ってエラーが出ている箇所を修正など。 OpenSLのシリアライズ処理を書いてないのにコンパイルが通って「あれ？」っと思ったが よく見たらOpenALやOpenSL依存のルーチンをそれぞれ別クラスに隔離していて、 シリアライズは共通クラスだった。後はちゃんと動いてくれればいいが・・ コンパイラもgccではなくclangを使う様に変更。 今までそうしてなかったのは正直言ってclangでどのようにクロスコンパイルするか設定などがわからなかったから。 別にgccでもプログラムの動作は変わらないのだが多分boost spiritの影響で 1プロセスで1.8Gも行くと4つ並列に動かしたらビルド用にメモリが7.2Gは必要な計算。 gvim(clang_complete)やリファレンスを見るためのブラウザに現在1.6G程度使っているので、全然足りない。 ま、プロセスを2,3程度に制限すれば良いとも言えるがそれだとクアッドコアのCPUが遊んでしまう。 だったらこの際メモリ消費が半分以下で済むclangを試してみようかという事で。 結論から行くと Arm5Teの場合 "clang++ -target arm5te-none-linux-androideabi --sysroot=(NDKのplatformヘッダのパス) --gcc-toolchain=(NDKのgccツールチェインのパス)"とオプションを与えればクロスコンパイル出来た。 自分のケースではNDKを/opt/adt-bundle-linux-x86_64/ndkにインストールしているのでArmアーキテクチャ向け,Android API Level 9以降を対象とすると clang++ -target arm5te-none-linux-androideabi --sysroot=/opt/adt-bundle-linux-x86_64/ndk/platforms/android-9/arch-arm --gcc-toolchain=/opt/adt-bundle-linux-x86_64/ndk/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64 のようになる。 なんでnone-linuxなのかはよく分からんっていうか普段PC用にコンパイルするときの i686-pc-linux-gnu なんかの指定も内部動作をほとんど知らないまま使ってるので、これについてはなんとも。 ちなみに Androidに付属している (NDK-Path)/docs/STANDALONE-TOOLCHAIN.html を読むとスタンドアロンで動くツールチェインセットを生成することができるが、 見た感じ手間はNDK内のパスを指定して動かす場合と比べてあまり変わらないっぽいし 同じファイルをディスクに2つ3つ置きたくないので自分は上記の設定で直に使ってる。 (2014/03/10) LUbuntu13.10のアレコレ サスペンド失敗する問題 カーネルの自前コンパイルしたらサスペンド（電源OFF)するまでは行くが、相変わらず復帰に失敗。 なにやらfglrxがどうのとかエラーメッセージが出るのでドライバを最新版やBeta版に変えてみるも改善せず。 LUbuntuのログアウトウィンドウでサスペンド・・ではなくコマンドラインで sudo pm-suspend --quick-s3-mode とやるとちゃんとサスペンド＆復帰ができるので 少し手間だが当分これで行く。 pm-suspendの代わりにpm-hibernateを使うとハイバネーションで pm-suspend-hybridはHDDにRAMの内容を書き込んでサスペンド状態へ、復帰時にRAMの内容が残ってたらそれを使い 消えてたらハイバネーションと同じ動作って事だろうか？ ibusのmozcが全角カナ入力になってしまう問題 どうも、Alt + Shiftを押すとなってしまうっぽい。 これはキーバインドにも載ってないので解決方法が分からんけど、とりあえずもう一度Alt+Shiftを押せば戻る。 ibusのmozcでキーバインドを変えても反映されない問題 IMを使うアプリケーションを再起動かと思いきや、 ibus自体を再起動しなければ反映されなかった。コマンドラインで ibus-daemon -drx 等として手動で再起動 (2014/03/10) Boost 1.55.0のAndroid向けビルド BoostはそのままではAndroidコンパイラでビルドできず修正が必要なようで、パッチを作ってみた。 といっても http //yutopp.hateblo.jp/entry/2011/12/26/233059 ここの記事の通りやっただけ。バージョンが1.48.0と少々古かったので最新版で使えるよう微修正。 ページの一番下にリンクがあるのでもし良かったらどうぞ。 適用するには単純にboost_1_55_0を展開したディレクトリで patch -p1 boost_arm.patch とする。 後はb2で普通にビルドする。一応自分がビルドした時のオプション等をbuild_arm.shに書いてある。 1つ注意が必要なのは、ファイルの名前通りboost_arm.patchはarm用でboost_x86.patchがx86用なのだが x86の方はarm版の後に追加で適用する形となっている事。 あとNDKは64bit版を /opt/adt-bundle-linux-x86_64/ndk にインストールした前提で書いてあって、 これは各自tools/build/v2/user-config.jamを修正してほしい。 32bit版NDKなら androidPlatform = linux-x86_64 なってるところを androidPlatform = linux-x86 に変えるとかね。 実のところ gitでpatchを作るにはどうするか？適用は・・・とか、そういう自分の勉強が主だった。 つまりパッチはオマケ。 (2014/03/07) 進捗としては前回書いた項目の半分くらいだけどキリが悪いから次回ということで。 今回は単なる日記。 とりあえず「期間空いたけど残念ながらあまり進んでない・・・云々」と始めようとしたら mozcの日本語入力がうまく動かず記事を書く気力が激しく減退したものの、 僅差で「2週間も音沙汰なし」の後ろめたさが勝利。 自分でも何を言ってるのかよくわからんが。 色々あって環境(LUbuntuとWin8)の再構築をしている。XPはもういいかなという事で入れなかった。 このご時世だけどメモリを新調し合計8GになったのでMinGWでboost spiritとか使って 1プロセスのメモリ使用量が1G超のコードでも4,5個並列コンパイルでき、 ついでにLUbuntuも64bit版にしてみたのでもし2Gを超えてもエラーでgccが落ちることはないと思われる。 コンパイルにそんなメモリ食うコードは良くないと言われればそれまでではあるが・・ ライブラリ一式も64bitバージョンが導入され、32bitで動くプログラムを配布したい時の手間が気にかかる。 windowsの方は元々ゲームとモデリングが主な用途だったのでパッチのインストールとソフト突っ込んで終わり。 マザボとメモリ交換したのもあって認証関係でちょい躓いたがまぁいい。 問題はOSそれ自体より今まで書いたソースコードの断片だのメモ書きだのの整理が面倒で先送りにしていたツケが回ってきた事。 どうでもいいファイルばかりだからフォルダごと消そうか・・・と思いきや大事なメモが〜とか、 逆に大事なプロジェクトフォルダの周りにゴミが散乱してたり。 そもそも、用済みのメモ等を消すのが忍びなくて放置してるのが元凶かねぇ 大事なファイルだったらgitで管理すればいいんだろうけど自分の場合、 最初は一時的なメモとして書いていたけどそのうち文章が増えてって気づいたら・・というパターンも結構あるから悩ましい。 何でもかんでもgitするとそれはそれで邪魔。う〜む、これといった解決策が思いつかん。 #追記 LUbuntu 13.10 64bit版にして良かった点 64bitなプログラムを書ける（本当は使えるレジスタ本数が増えて速くなってるはずだが、測ってないのでよくわからん） 起動時間が前の半分か2/3くらいになった （LUbuntu 12.04 32bit版と比べて）悪い点 コンパイルする際にライブラリの準備、管理が少し面倒 マザボ依存っぽいが、サスペンドからの復帰に失敗する。画面が崩れ再起動を余儀なくされる 英語版を入れたせいか、日本語入力が不便（12.04でも英語版だったがこちらは問題なし） 一番困るのは不意にmozcが全角カタカナモードになってなんのキーを押しても戻らない事。 この時何故かScrollLockランプが点灯し、キーを押しても解除はできない。 戻すには一旦ログアウトしなければならず、大変不便である。ググッてもそれらしき症状の人が居なくて手詰まり。 mozcのキーコンフィグも効かない。GUIで設定を変更しても反映されてないという・・ 他にはキーボードのリピート間隔設定も相変わらず反映されない。調べたところバージョン8くらいからずっとで、もう何年目だろうか。
https://w.atwiki.jp/f_tps/pages/52.html
スパイク 洋ゲーのローカライズを積極的に行っている会社。 最近ではオブリビオンのローカライズを行ったことが記憶に新しい。 マイナーな洋ゲーの日本語版が遊べるのはこの会社によるところも大きい。 スパイクがローカライズした代表的なソフト PREY Call of Duty3 BIOSHOCK Haze? 参考リンク 公式サイト
https://w.atwiki.jp/f_tps/pages/51.html
サンドロット 地球防衛軍シリーズの開発元。 代表作 地球防衛軍 地球防衛軍2 地球防衛軍3 参考リンク 公式サイト
https://w.atwiki.jp/f_tps/pages/109.html
レッドスティール キャンペーンモード あり マルチプレイモード あり オフラインマルチプレイ最大人数 画面分割で4人 オンラインマルチプレイ なし マルチでない、最初からＷiiリモコンでの操作を前提に開発されたＦＰＳは現時点で国内ではこの１本のみ(エレビッツを含むと２本)。 主な舞台は日本だが、洋ゲーにありがちな勘違い文化と怪しい日本語で溢れており親近感は全く無い。馴染みのある街並みでの銃撃戦は期待しない方がいい。 リモコンの向きが視点と連動しており、右スティック操作が苦手なプレイヤーでもスラスラとプレイ可能。ガンシューとＦＰＳのいいとこ取りである。 その一方で、不用意に手首を動かすと、視点も思わぬ方向へ動いてしまうという欠点があり、プレイ中は常に手首の姿勢にきをつけなければいけない。 リモコンの傾きは画面内の主人公の手首にも反映されるため、映画やアニメなどのようにハンドガンを横向きにして馬賊撃ちごっこも可能。 中ボスとの戦闘時は一対一のチャンバラになる。チャンバラ時はリモコンとヌンチャクを二刀流に見立て攻撃やガード、回避を行う。 なりきり度が高く、熱中しやすいが腕の疲労が激しいので長時間プレイは注意が必要。 本作独自の要素として、ゲージを消費して少しだけ時間を止めるフリーズショットと前述のチャンバラ戦がある。 フリーズショットはゲージの量に比例して時間の停止も長くなるというもので、発動はいつでも可能。 また、敵の武器を撃ち落としたり刀を折ることで耐久力に関係なく敵を降伏させることができ、フリーズショットとの併用は非常に強力。 使用可能な銃器はハンドガン、マグナム、スナイパーライフルなどスタンダードなものばかりで、重火器は無い。 武器のアンロックと持ち込みはステージの合間に行ける射的場で行う。射撃場のオヤジが仕入れてきた武器で射撃の腕前を披露してみせることでアンロックされる。 ステージの構造がガンシュー的で、遮蔽物が少なく一度に現れる敵の数が多い。攻撃も積極的である。 一部のステージには非常に理不尽な仕掛けやフリーズ、音が消えるバグなどがあるので注意が必要。 関連リンク 公式サイト
https://w.atwiki.jp/f_tps/pages/37.html
Gears of War（ギアーズオブウォー） キャンペーンモード あり マルチプレイモード あり オフラインマルチプレイ最大人数 通常2人。システムリンクで最大8人。 マルチプレイ時のBOTの有無 なし マルチプレイステージ数 DLCを含めて16種類 マルチプレイルール数 Coop あり Coop最大人数 2人 オンラインマルチプレイ あり オンラインマルチプレイ最大人数 8人 オンラインCoop あり オンラインCoop最大人数 2人 コントローラ設定 遮蔽物に隠れるカバーポジションなど多彩なアクションが特徴の三人称シューター。 斬新なゲーム性やアンリアルエンジンによる美麗なグラフィックなど数々の賞賛を浴びた。 瓦礫や岩などの障害物がいたるところに設置されており、カバーアクションでそれらに隠れつつ、敵を撃っていくのが基本的なスタイル。 通常では照準が表示されておらず、狙いをつける行動を取る事で初めて照準が出る。 言葉だけで見るとタイムスプリッター～時空の侵略者～に近いシステムだが、もともとのゲーム性が異なるため実際のプレイ感覚はかなり異なる。 また、狙いをつけていないまま撃っても、弾道が大きくばらけてしまう。 アクティブリロードというシステムを採用しており、リロードをすると、移動するオブジェクトが表示され、音楽ゲームのようにタイミング良くボタンを押すと、リロードの隙を軽減できる。 絶妙なタイミングで押す事が出来れば、次に撃つ数発分の弾の威力も上がる。 よくある自動回復システムを採用しており、一定時間内に被弾しすぎなければ死なない。 回復アイテムといった類の概念はない。 武器は、衛星砲のドーンハンマーを除いて全て実弾系の武器のみ。 キャンペーンは5ステージ。 1つのステージは比較的長めであり、難易度も高めであるため、シングル全体のプレイ時間はそれなりの長さになる。 しかし、ステージ数そのものが少ないためボリューム不足という印象を受ける人も普通に居る。 その代わりではないが、細部までCoopを意識した秀逸なレベルデザインになっており、オンラインCoopは非常にアツイ。 難易度はCasual、Hardcore、Insaneの三段階があるが、Casualでもなかなかの手ごたえになっており、初心者のソロプレイは若干厳しいものがあるかもしれない。 マップ上にCOGタグと呼ばれるものが隠されており、それらを集める簡単なやりこみ要素もある。 COGタグに関連する実績もある。 国内版は残虐表現が規制されており、死体の断面の内蔵描写などがカットされている。 操作方法 ボタン 対応する行動 備考 十字キー上下左右 対応する武器に変更 左スティック上下左右 移動 右スティック上下左右 視点移動 左スティック押し込み しゃがみ 右スティック押し込み ズーム 白ボタン/Lボタン（LB） 指示 Lトリガー（LT） 狙いを定める 黒ボタン/Rボタン（RB） リロード Rトリガー（RT） 射撃 A カバー/長押しでダッシュ B 近接戦闘（通常は殴り。例外はチェーンソーなど） X 武器を拾う/スイッチなどのアクション Y 味方に注目 START ポーズ BACK 関連リンク 公式サイト PCゲームレビュー「Gears of War for Windows」
https://w.atwiki.jp/slice/pages/73.html
(2011/04/30)#2 その２ チマチマと． (2011/04/30) リハビリング はいはい．モデリングのリハビリ． 野暮ったく見えるけど実際には下のようになるんじゃないですか？多分． (2011/04/27) リソース構造 22日に記事を上げようとメモ帳に書いたところで放置してしまった．いつもの悪い癖． 以下は17～27日の状況と思ってほしい． OAuth認証は面倒だなぁ，と嘆いていたらTwitterには簡易版のxAuthというのがあるようで． でもまあOAuthで認証する所まで行けたしいいか． 後は気が向いた時にでも少しづつやっていくつもり． 数学もチマチマとベクトル，行列，座標変換と進み今はクォータニオンで苦戦中． 当然ながら四元数の名の通りまずは複素数から学ばないと入っていけないようだ． そしてゲームの話．リソース管理について． 今まで同じリソースは1本の可変長配列で管理していた． （例えばテクスチャならテクスチャ全体で1本，モデルならモデルでというように） リソースにはハンドルという番号を割り当て，ユーザーはこれをマネージャに渡して実際のポインタを得るわけだ． しかしこの構造はゲームで使う上で問題になる． ぶっちゃけ図を入れるまでもないが・・一応説明しておくとこの図は 新しい要素を追加する時に空きが足りなければ新しく領域を一本確保して既存要素をコピーするという可変長配列の動作を示している． アクセス自体はインデックス一発で高速なものの 誰かがリソースを使用していると勝手に拡張も出来なかった． どんな時にマズいかと言えば あるテクスチャAを読み込み中にテクスチャBも必要だとわかった 続けてBも読みたいが，配列に空きが無いので拡張したい（新しく領域を確保して，そこへ既存の領域をコピー） しかしAは使用中なので勝手にメモリを移動できない = Bを読めない といった具合． もちろんこのケースではBの読み込みを遅延させる方法で回避可能だ．しかし根本的な解決とは言えないのも事実．例えば テクスチャAの関数内でモデルXの関数を呼ぶ モデルXの関数ではテクスチャBの情報が要る（Bはまだ読み込まれていない） となればやはり破綻する． 悪い事に実際ゲームでは上の状況は日常茶飯事なのだ． 今までは騙し騙し小細工で乗り切ってきたがいい加減に抜本的な改善が必要である． 考えてみればそもそもリソースを一本の配列でメモリに置かなくてはならない理由など無いのだ． （いや，出来るだけ1箇所に纏めたいが） 一先ず大まかなデータ構造で思い付くのは「配列（ベクタ）」「線形リスト」「ツリー」・・だろうか． とりあえずアクセスの度に大量の分岐が入る線形リストは論外だし ツリーにしても乱暴ではあるが似た様な物か． だからといってリソースをハンドルを使わず生ポインタで管理するのも避けたい．というかそれではリソース管理の意味が無い． でも根元の部分だけに速度はある程度欲しい・・・ 結局インデックスアクセスだろう，配列1本が駄目なら2本以上だという考えに至った． 配列を拡張したいのにそれが使用中であったら新しく配列を確保してしまえという方向． この図を見て「やっぱ目的のリソースがどの配列にあるか分岐が要るじゃない？」と思われそうだが ある種の制限を加えれば計算で一意に求まる．それは 各配列サイズは2の累乗とする 新しく確保する配列のサイズはこれまでの全要素数に等しい のような物． 2つ目の項目は何を言ってるのかというと{ [2] }の状態で新たに配列を確保する時のサイズは要素数=2, 新しい配列サイズも[2]であり， { [2],[2] } となる．更に追加すれば { [2],[2],[4] } になる． まぁこんな小手先テクニック，大して高速化にならんだろうが・・ 頃合を見計らって一本に纏める機能もつけた．車輪の再発明感がプンプンするがこれで先ほどの問題解決に至った． 臭うどころかこのようなデータ構造は既にあって，前にネットでそれらしい資料を見かけたのだが 当時は全く必要としていなかったため「フ～ン」と流してしまっていた． 適当に単語で検索しても一向にヒットしないので仕方なくそれっぽい実装をしてみたわけだ． あちらの実装では各配列のサイズが可変だったかな？ (2011/04/16) 再び寄り道 ゲームの方は進んではいるが未だ光明がみえない． キャラクターのアニメーションやマップとの当たり判定，場面（会話シーンや戦闘シーン） を包括的に管理する仕組みというんだろうか？ いわばゲームの裏の部分をせこせこと作っている． 一回作り方を確立してしまえばスムーズに進むとは思うが・・ HLSLと違って結果が地味なだけにモチベーションが低下せざるを得ない． そこで前々からやりたかったシリーズが再び発動（前回の入力ログは完了した） 今回のお題は「Twitterのクライアントを作りたい！」である． ゲームとは全く関係ないが気晴らしという事でご容赦願いたい． とはいえフツーなクライアント出来ました～なんてやっても誰も使ってくれないどころか自分も楽しくないし 正直言ってそんなのは作る意味がない．1つでもオリジナリティが要る． 作るというからには何か思いついたんだなと察して貰って結構だが詳細に関しては後ほど． 少し前にBasic認証は廃止されたのでOAuth認証が最初の壁か？（そのくらいは自分で書きたい） で，更にそれとは別に最近は数学の勉強をしている・・といったら大げさだが 今まで3D描画の時になんとなく計算していた行列を，プログラム見直しのこの機にキッチリ押えておこうと． （行列の各列が基底を表していて～くらいは分かるがクォータニオンはブラックボックス） 具体的には「ゲームプログラミングのための3Dグラフィックス数学」という本を中心に ネットに散らばる資料を参照しつつたまにテレビでやっている放送大学の「線形代数」を録画してみたり マイペースでやっている． いつまでにコレをやるという目標は特に無い．必要だと思うからやっているだけの事なので． というより基本的な座標計算を生涯ライブラリに頼るなんて格好悪いじゃないか． (2011/04/12) キーログ 既に3回ほどオブジェクト継承やステート実装について記事を書こうとメモ帳に下書きしてはみたものの 例によって文章がまとまらない．完成してないんだから当たり前か． とは言ってもその部分が何時終わるのか見通しつかないので 気晴らしにとキー入力のログ取りと再現のルーチンを実装している． レースゲームやタイムアタック要素のあるゲームで定番の，デモを撮る（動画ではない）機能だ． 今作っているゲームに必須ではないのだが「前からやってみたかったシリーズ」のうちの1つであった． 特定の状況でのみ起こるバグの原因究明にも使えるかと思われる． 動作はフレーム毎のキー入力をテキスト形式でファイルに書き出し，読み込んでキー入力を再現する・・・という 単純なものだ．説明の必要はないだろう． もちろん毎フレーム分の状態をバカ正直に書き出したのではメモリとファイル容量の無駄遣いである為 キーの入力状態が変化した時だけ記録し ファイルへの読み書きもfstreamを使用したストリーミング形式としてある． キー入力再現の次にやりたい事といえばクイックセーブ ロードであるがこれは難易度が高そうだ．