約 601,583 件
https://w.atwiki.jp/slice/pages/6.html
アーカイブ @wikiのwikiモードでは #archive_log() と入力することで、特定のウェブページを保存しておくことができます。 詳しくはこちらをご覧ください。 ＝＞http //atwiki.jp/guide/25_171_ja.html たとえば、#archive_log()と入力すると以下のように表示されます。 保存したいURLとサイト名を入力して"アーカイブログ"をクリックしてみよう サイト名 URL
https://w.atwiki.jp/slice/pages/158.html
テンスキ（TwitterID @ten_suki）さんから、誕生日祝いに頂きました。
https://w.atwiki.jp/slice/pages/79.html
(2011/09/30) 放置 例によって例の如く記録を放置してしまった．思い出せる範囲で書く． 前回書いた描画ソートはもちろん既に終わった． エディットボックスのような内容が変化する文字列など予め頂点バッファに転送せずに描画する物は すぐに描画命令を呼ばずにある程度メモリに溜めてから一気に処理するようにした． と，これだけなら簡単そうに思えるが実際には頂点形式や使用するテクスチャが違ったりすると バッファを結合できないのでその辺の判別方法とかが要る． 具体的には最初にオブジェクトから「描画タグ」と言う物を収集する． 描画タグには先程書いたような使用テクスチャ，頂点形式，(HLSLの)Techniqueやαブレンドの有無といったオブジェクトの描画ソートの材料になる変数が記載されていて， これらとユーザーの提示した「ソート手順」を用いオブジェクトのソートを行う． そしてソートの結果「一括描画出来る」と判断した範囲については一括描画，そうでない所は個別にD3DのDrawAPIを呼ぶ． 1つのオブジェクトからは複数の描画タグを出力でき，またタグを取得する際に文字列の「キー」を指定する仕組みで 例えば"low"を渡せば遠距離用のローディティールモデル，"high"なら高精度なモデルを描画するよう 仕向ける事も出来る． （というか別にオブジェクトと1対1にする必要性も無かったからそうなってるだけ） 毎フレームタグを収集，ソートしてたら重いのではないか？ これについては感覚だがオブジェクトの数が50くらいまでなら問題ないだろうという判断． 大量のパーティクルや2Dシューティングなんかの弾幕を描画したいのなら それ専用のクラスを作って纏めて管理するとか． まぁ実際に速度で問題が出たらおいおい改良していくとして・・・ ここまでが上旬の話． 中旬はSVNの履歴を見るにカメラクラスの移植， キー入力クラス，行列クラス，ベクトルクラス，テキストフォントキャッシュ周辺のリファクタリング それと3D空間内でのテキスト描画などなど． 実を言うと自作エンジンをLuaメインに据えて作り直してから まともに3D空間を扱ってなかったからちゃんとしました，という． 下旬に入ってからは「Debugビルドとはいえ，な～んか重いなあ・・・」という訳で 前々から気になっていたコリジョンの判定ルーチンを作り直し． 逐一コリジョンタグ(※1)を見て内部リストの展開の有無や衝突判定関数の呼び分けをする関係上 分岐を多用していて，これは計算時間もそうだがキャッシュに悪い． そもそも双方のコリジョンタグを見た段階で手順は決まる物だから前処理で手順をリスト化するか 初回だけ計算で求めて以降は使い回すのが普通だろう． 前計算すると組み合わせが膨大になるのでここでは後者を選択した． さてパフォーマンスは・・・と思ったら期待した程ではなかったのでここに来てプロファイラを導入(※2)． するとどうだろうか．当たり判定自体よりもLuaからのデータ転送に処理を食っているという・・ よく調べてみるとLuaのAPIを呼ぶ分には速いものの自作のLuaValue互換クラス(※3)が重い． 更に調べるとマルチスレッドに対応するためのリソースロック，アンロックを何かする度にしているので これがネックという事がわかった． かといってLua-APIを直接呼ぶのでは本末転倒，改善策を考える． 思案の末「マルチスレッド対応は必要な部分だけする」という至極真っ当な結果に． 単にラッパークラスとして使いたい場合にリソース管理だなんだの同期は無駄な訳で． 要するに「シングルスレッド動作で構わないクラスはロック・アンロックしないバージョンを使う」という事． 言葉にすりゃ簡単だが既にマルチスレッド対応で作ってしまった物を じゃあ一部だけ速度重視のシングルスレッド動作させようかと思ってもなかなか面倒ではある．（が，やるしかない） 悪あがきとしてテンプレートを使ったポリシーで速度とコード量の両立化を計ってみたりとか． 今月はパフォーマンスアップのためのアレコレが多かった． しかしあと2箇所程修正，改良すれば速度が懸念される部分は無くなるので一安心といったとこか． ※1 ポリゴン,円柱等の物体の形状やリスト構造を表すID ※2 Game Programming Gems 1に記載されている簡素なアルゴリズムを，ちょこっとアレンジしたバージョン ※3 スタックベースのLua-APIをラップしてテーブルのアクセスを["item"]等C++風に記述できるようにしたクラスを 更にリソースハンドル管理，マルチスレッド対応にした物 (2011/09/05) 描画ソート 最近なんだかwikiが重いから更新する気も起きない・・・ 更新の間が空くと何したかを忘れるからそれ用の時間を決めたい所だな． さて．現在描画の最適化をしている． この前はフォント描画をまとめてやる話をしたけど今度は本腰を入れた大がかりなエンジン改修． 実にエンジン本体クラス8割のコードを書き換え． というのもTwitterAPIで試しに最大20件の呟きを取得し，その数だけ自前GUIのウィンドウに表示させたら思いの外重かったからだ． Debugビルドとはいえこの程度で処理落ちとは情けない話ではないか． 原因はというと，描画にはすべてUP系の関数（つまり1つ矩形を描く度に頂点バッファをその都度確保，破棄している）を使う関係上 多大なオーバーヘッドが生じているのは想像に難くない． 丼勘定でウィンドウ1つにつき矩形3つ，枠が2つ，テキスト1つを要し これが20個だと60, 40, 20回のDrawPrimitiveUP()が呼ばれている計算になる． 恐らく今時のプロセッサなら1フレームに120回の呼び出しなんぞ余裕だろう． が，UPなのでバッファの生成・破棄も120回ずつのおまけ付き．途端に厳しい． そもそも何故UPかと言えば単に自分が勉強不足なだけで動的な頂点バッファ，インデックスバッファを利用したことがなかった為だ． というわけでいつも通りMSDNを参照しつつ動的バッファの使い方やD3Dのパフォーマンスを引き出す方法を学んだ． パフォーマンスを引き出すと言えば大げさだが特に小難しい話ではない．ざっくりと説明するなら大まかに3つ． 「DrawPrimitive関数の呼び出し回数を抑える」 GPUはCPUと独立して動いているという事を念頭に置いた設計（D3DLOCK_DISCARDなどのロックのフラグを適切に選択） 「リソースの切り替えを最小限に」 GPUのキャッシュに影響 「不透明ポリゴンは手前から描画（Zクリップを期待）」 Zクリップされれば以降のピクセル処理が不要になる 基本的にオブジェクトの描画順を工夫するのだなという事は察しがつくと思う． エンジンはオブジェクトの描画要求を受け取ったらすぐには描画せずにキューに貯めておき 描画の必要性が生じたらテクスチャやカメラからの距離をキーとしてソートし，まとめてD3Dにコマンドを送る． ソート対象のキー，優先順位は予め定義されたソートアルゴリズムのインタフェースを配列として表現． 例えばまず距離でソートして，その内距離が10.0以内のオブジェクトを同位置として扱い更にテクスチャでソートをかけたいなら SetSortAlg(new IFSortDistance(true, 10.0f), new IFSortTexture()); とする．ちなみにこの関数は可変引数としてあり，任意の数のソートをかけられる寸法． IFSortDistanceの第一引数は降順か昇順かのフラグである． テクスチャのソートは同じ種類が隣に来るという点が大事なのであって降順だろうが何だろうが関係ないので引数無し． 頂点バッファとインデックスバッファについても以下同文． 後はソートしたオブジェクトを普通に描画すれば冗長なステート変更はD3D内部で自動的に省略される(※1)ので処理の効率化が望める． ううむ，言葉にするとそれだけだな．実装は仕様が二転三転して難航したのだが． ※1 ドキュメントに書いてあった．http //207.46.16.248/ja-jp/library/bb219721%28VS.85%29.aspx 「D3DCREATE_PUREDEVICE フラグの目的は何ですか」の項を参照．
https://w.atwiki.jp/slice/pages/131.html
(2015/04/27) また絵を仕上げた 今度はドラゴン。といっても洋ゲーに出てくるようないかついのではなくて 絵本で少年と一緒に旅をするような、でっぷりした食いしん坊のイメージで描いた。 例によって高解像度版はPixivへ上げた。 で、その前には大神っぽい和風タッチの練習もしていた。 練習というからには本番もあるという事だが、こちらはまだ下書き止まり。 SFタッチな絵の下書きもあって、上記の和風な奴とどちらを先にやろうかなと迷っている所だ。 プログラミング？ って。待ってくれ。 自分で過去記事を読み返してて「最近プログラミング全然してなくね？」と思わくもないのだが。 いや…vineのページに、幾つか動画を上げてたか。 今回は剛体の速度や角速度から姿勢を計算するんじゃなくて、 剛体を表現する3つの質点の位置関係から物体の姿勢を割り出し めり込んでいたらその分だけ質点の位置をずらす方式。 当然ずらしたら質点が示す図形は歪んでしまうのでそれは質点間のバネ拘束で補正する。 詳しくは後ほど書きたい。 前はめり込んだ部分の形状を求めてそれに応じた圧力を計算してってやってたから安定してる分動作が重かった。 今回は速度を重視して主にGJKの接触判定とEPAによる最深点の算出だけしか やってないのでどうだろう？それより軽いとは思うが…これも後ほど試したい。 で、vineの動画にある通り剛体物理は今の所、紐みたいのは再現出来てる。 相変わらず位置関係によってブルブル震えたりはするんだけど…まぁいいだろう。 ustreamとtwitch ライブ動画のアカウントの事だけど、 twitchの方は割とフォロワー（？）が居たのに先日「不正っぽいアクセスがあったから凍結しといたで」 と言われ、アクセスするも以前のメールアカウントが必要 - gooメールの無料版は既に無くなってて終了 という流れで消滅。うかつだった。 メール1通受け取るためだけに有料版の登録も、ちょっと。（ついでに本当にgooメールだったかも怪しい） HNは以前のsliceではなく「でがらし」にまとめたかったのでまぁいいかなぁと。 ustreamの方もsliceで、こちらも規約の変更で以前に保存した動画等は消されてしまっているし 別に要らない気がしてきた。 今度やる時は新しく作ると思う。 (2015/04/08) 絵を仕上げた ホワイトデーに合わせて描いていたつもりが背景を描き込みすぎて死んで放置してた絵を仕上げた。 当初アニメ塗りの予定でやってたんだけど自分の能力不足か、顔などがどうにも上手く線を引けず 結局厚塗りしてしまった。 この場合、基本的に下書きしたら塗り始めるので線画が実質無駄という。 一応せっかくだからと合成すれば輪郭がはっきりして違った風味にはなるんだけど…不要といえば不要。 そもそも自分はアニメを見ないのでデフォルメの仕方が良くわからん。 日本のアニメでよくある、目が大きめで顎がシュッと尖ってるああいうのは全く描けない。 さらに言えば背景なんて良く観察したこともなかったんで 遠景は普通に水彩ツールとかで適当にやればそれっぽく見える事も知らず。 アニメ塗りに代表される陰影がくっきりはっきりしてる塗り方って主にキャラクターだけで、 他は結構グラデーションやら何やら使ってるのね… で、途中でそれに気づいて「どうせみんな見ないだろう」 という箇所をテキトーに筆でちゃっちゃとやってみたのがこの右側の部分。 うむ。奥なんてこんなんでいい。かけた時間が段違いですわ。 プログラム まだあたり判定やってた！ 主にGJKのテストコードのfloat誤差で死んでた。 今は2Dのランダム凸形状をひたすら生成して結果を比較するテストが一応通って一安心してる所だが リファクタリングしないと効率悪い実装だし、まぁなんというかご愁傷様です。 判定自体はともかくゲームフレームワークとの連携とか試してないのでこれもやらねば。
https://w.atwiki.jp/slice/pages/164.html
手 4 手 3 手 2 手 1
https://w.atwiki.jp/slice/pages/84.html
まずは一緒に配布したDLLをプログラムと同じフォルダに放り込む． (現在のバージョンでは1つのアーカイブに入っている) 初回起動時はブラウザが立ち上がってこのような画面になる． ユーザー名とパスワードを入力して「連携アプリを認証」ボタンを押す． するとこのような7ケタの番号が出てくるので Twilveの方に入力する． 認証に成功するとこのようなメッセージボックスが，失敗ならその旨を通知してくる． このメッセージボックスはメインウィンドウの後ろに表示されてしまう事が多々あるので注意． 味気ないが，これがメイン画面である． 画面上部に3つのボタンと，2つの「通信スレッドステート」ウィンドウが表示されている． これは只単にモニタの為なので閉じてしまって構わない． 初期状態では何も表示されないので「ソース」と「プラント」を初期化する． 順序はどちらからでも問題ないがここではプラントから配置しよう．赤丸で囲んだ「Place Plant」ボタンをクリック． プラントの種類を聞いてくる． Flowはツイートを川のように流すプラントで，次から次へと新しいツイートを出現させる． Poolはユーザーがツイートを読むまで留めておく． 例としてFlowを選択． いきなり画面が真っ黒になって面食らうかもしれないが，落ち着いて欲しい． この格子平面はプラントを配置する奥行きを表している． マウスのホイールで前後に動かせるので，適当な位置に調整． 次に画面上をドラッグすると線分が描画される．これが「どこからどこまで」ツイートを流すかの指標だ． ボタンを離すと今度は輪が描画される．今度は「どのくらいの範囲で」を聞いてきている． マウスカーソルを動かすと半径が変化するので適当な場所でクリックすると最終的な座標が決定され，プラントが作成される． ベタ背景だと思ったらカメラは既に3D空間を映していたという訳だ． その証拠に何もない箇所でマウスをドラッグすればカメラを回転させられ，W,S,A,Dキーで上下左右に動かせる． ここでプラントをクリックするとカメラが側に寄り，詳細ウィンドウが表示される．使い方は説明の必要ないだろう． さて．次はソースの作成．「Source Manager」ボタンをクリックすると・・ ソースマネージャが表示される．APIの名称と意味については各自調べてもらう事にし 例と言うことで手っ取り早くツイートが見られる[STREAM]sampleを選択し， 名前ボックスに適当な名前，その後 ボタンをクリックするとソースが作成される． すると，ツイートが先程のFlowに流れてきている筈だ． ツイートをクリックするとカメラが寄り，投稿者のアイコンが表示されたりする． 最後にツイート投稿．画面上部の「Tweet」ボタンを押すとこのようなウィンドウが出てきて 文章を入力した後にsendボタンで呟ける．
https://w.atwiki.jp/slice/pages/22.html
niconico 【ニコニコ動画】 もしアカウント持ってないよ！って人が居たら以下をどうぞ if you don t have niconico account, try this youtube
https://w.atwiki.jp/slice/pages/133.html
(2015/06/12) 絵は進む 新たに2枚ほど絵を描いた。 突然！マッチョマンのパロディとシャドウゲイトの死神さん。 前回「人物が1人と小物が少々の他背景は黒ベタ（グラデーション）なので…云々」と書いたのは、実は死神さんの事だった。 …と、言いたいところだが。実は違う。ざんねん、両方とも思いつき。 やっぱり絵は最初の勢いで一気に描いてしまったほうがいいね。 ずっと後回しにされてるやつは気長にやります… ゲーム うわぁぁぁ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂ …では流石にちょっとアレなのでいつも通りgitの履歴を見ながら書くと リアルタイムプロファイラ 描画ソート OpenGLのバッファ切り替えカウント 全部パフォーマンス関連。 プロファイラというのは特定のルーチンにかかった時間、呼び出し回数などを測ってツリー出力する物。 描画ソートは描画するオブジェクトをテクスチャやバッファIDでソートしてGPUのキャッシュ効率を上げようという、よくあるやつ。 OpenGLのバッファ切り替えカウントは文字通り。 あとはバグフィックスをちょろちょろと。 いい加減何か造らねばという事で 上から視点のローグライクシューティングなんぞを考えていたりする。 とりあえず仮素材はサクッと用意してみた。 最終的には3D描画の生ポリゴンで行きたいけど当分1枚テクスチャで我慢。 サウンドもフリー素材から選別しておいた。 サウンドに限らず素材集で自分のゲームにピッタリくる「これだ！」っていうのはまず無いので（仕方ないか） 選ぶのも結構面倒なのである… 絵よりはマシだけどねぇ。
https://w.atwiki.jp/slice/pages/159.html
ガリでもマッチョでもなく 骸骨と心臓 心臓 練習 塗ってみた 練習 砂漠(? 見ながらの練習 47 練習(その3) 練習(その2) 練習(その1)
https://w.atwiki.jp/slice/pages/118.html
(2014/06/22) 左下に軸表示するとモデラーぽくて格好良いね とはいえ、まだそんな事やってるのかという・・ いつも通りgit履歴を見ながら書く。 テクスチャ表示はオマケ。こんなんチャッチャとやればパッと出るわみたいな。 OpenGL APIのラップ OpenGLの関数を読み込んでそれをラップしたクラス経由でAPIを呼び出す仕様なのだが Debug版では自動的にglGetErrorによるエラーチェックを挟み、何かエラーがあればコンソールに出力するようになっている。 （勿論glGetError自体はチェックしない） OpenGLを真っ当に使うならそれで問題無さそうだし 「もし問題あっても、コンソールに出力されるだけだからいいよな・・・」と放置していた。 例えばGLSLシェーダーに特定のuniform変数が存在するかをチェックする場合 仮に無かったからと言ってエラーにはならない。 が、先日とある箇所のデバッグをしていたらその「何でも無い」警告がエラー出力を埋め尽くしてしまい バグに直結するようなエラーやログが検索しないとわからない、見通しが悪い、 1フレームに何百個も発生していたらさすがに遅い等の問題に遭遇した。 当たり前っちゃあ当たり前だ。 そんな訳でどうするか考えた結果、Debug時でもエラーチェックをしないバージョンのラップ関数を用意する事で落ち着いた。 glGetUniformLocation() という関数なら glGetUniformLocation_NC()みたいな感じ。 勿論Release時はどちらを呼んでも同じ動作にした。 AMDのドライバにハマる AMDのドライバがクソと言われる所以が少し、わかったような。 結論を先に書くとAMDドライバではGLSLに整数を渡す時にglVertexAttribIPointer()を使わないと値が化ける。 更にGLSL側でfloatで受けたりしても駄目、逆にfloat - intも駄目。 Nvidiaとかだと普通に動きそうな気がする。 GLSLのattribute変数(頂点入力変数)にソースを渡す時は VertexBufferObjectを使うかによらず大体、glVertexAttribPointer()を使うと思うのだけど これが曲者で。 APIの公式リファレンスを見るとglVertexAttribPointer()以外にも 整数専用のglVertexAttribIPointer()や64bit浮動少数点数用のglVertexAttribLPointer()なんてのがあったりするが glVertexAttribPointer()にはGL_INTも渡せると書いてある。 公式に書いてあるし、そもそもOpenGL ES2にはIPointerの方は無いのでglVertexAttribPointer()だけで組んでいたら 整数を渡すと値が化ける事に気づき・・ かなり時間食った。 その他 自作ライブラリの細々としたバグ修正など。 あと、最近プログラミングや3DCG以外に取り組んでる事があるとだけ。 (2014/06/12) 例のごとくまた放置してしまった。 相変わらずプレビュー表示で止まってる訳だけど、まぁ進んでいると言えば進んでる。 見た目の変化といえばグリッドに色がついてノードの軸表示が出来ただけっていう。 前回から何をしたかなんて忘れてしまったのでgitのログで振り返ると コンパイル環境をC++11からC++14に移行 階層構造を持ったモデルを描画する為の機構 上と関連してスキンメッシュ描画の色々 ベクトルの初期化と代入のstd initializer_list対応 Uniform変数配列に対応 システムUniform変数を管理するクラス 更新フラグ管理のクラス Actorクラス こんなとこである。 コンパイル環境をC++11からC++14に移行 新しい規格という感じもあまりしなくなったし、もうそろそろ使ってもいいんじゃないかと思ったので。 主に汎用ラムダキャプチャ、ジェネリックラムダ、関数の戻り値推定など。 他にも色々機能が追加されてるようだが自分は上記が目当て。 階層構造を持ったモデルの描画 モデルから関節ノードを読み込んでそれぞれの角度や位置を描画時に反映してって 要するにキャラクターを描画するってだけで。スキンメッシュも対応はしてあるがまだテストしてない。 ベクトルの初期化と代入のstd initializer_list対応 ベクトルの初期化は今までVec3 v(1,2,3) としか出来なかったのをVec3 v = {1,2,3}と記述できるようにし、 関数の引数にもAddVector({0,1,0}, {1,0,0})といった感じで直接書けるようにした。行列も同様。 なんで今までやってなかったんだろうというレベル。 Uniform変数配列に対応 これもなんで今まで（略 システムUniform変数を管理するクラス World、View、Projection、Transform行列(World*View*Projection)や、 EyePosition, EyeDirectionベクトルなんかのよく使うuniform変数は ライブラリ側で名前を決めてしまったほうが管理が楽そうだと思ったのでそうした。 World行列が更新されたらWorldの逆行列やTransformは計算し直しする等のフラグ管理なんて アプリケーションごとに何度も書きたくないし。 更新フラグ管理のクラス 変数同士の依存関係をマクロで記述したら後はフラグ管理を 自動でやってくれるようなテンプレートクラスも作ったりした。 マクロというのが若干格好悪いがいつもキャッシュ変数を持ったクラスを書く時のモヤモヤが解消したので良しとする。 ソースコードはGitHubにあるのだが簡単に説明すると boost preprocessorのsequenceを使って (キャッシュ名)(変数型)(依存キャッシュ名0)(依存キャッシュ名1)... という形で依存関係を記述する 上記の行列であれば (World)(Mat44) (View)(Mat44) (Projection)(Mat44) (WorldInv)(Mat44)(World) (Transform)(World)(View)(Projection) こんな感じになる。 World, View, Projectionは4x4行列変数で、他の何にも依存しておらず WorldInvはWorldに依存し、TransformはWorldとViewとProjectionに依存している。 各変数は、これまたマクロで自動記述されたgetXXX()という関数で取得するようになっていて戻り値がconst参照である。 getWorld()を呼ぶと何もチェックをせずそのままconst Mat44 (中身はWorld) が返り、 getWorldInv()はWorld変数が更新されていれば別途ユーザーが記述した 関数refresh(Mat44 mWorldInv, World*)の内部でgetWorld()を使って再計算した上でconst Mat44 (中身はWorldInv)を返す。 といった具合。 Actorクラス 名前からしてありがちで説明の必要も無いんじゃないかという程だが一応。 モデルと関節ポーズを内部に持ち、draw関数でポーズを適用しつつ描画する物。 このクラスもそうだがFBXローダーもまだまだ作成途中なのでGitHubに上げてない。 予定 引き続きFBXローダー。 以上