約 602,938 件
https://w.atwiki.jp/f_tps/pages/32.html
Bungie Studio Haloシリーズの開発元。 2000年にMSに買収され、それ以後しばらくMSの傘下にあったが2007年に独立した。 代表作 Marathonシリーズ(Mac用ソフト) Halo Halo2 Halo3 Halo3 ODST Halo Reach? Marathon Durandal 参考リンク 公式サイト
https://w.atwiki.jp/slice/pages/74.html
(2011/05/29) Unicode対応完了 変換プログラムを作った後にふと「メインプログラムもunicode対応しておこうか」と思い立ってしまったのでそれをしていた. こんなカスのようなプログラムでもそれなりコード量があって 想像だけでおなか一杯だが何時かはやらねばならんのだ. というかShiftJIS版Luaを使わずに行くと決めた時点でunicode対応は必須事項. 最初unicode対応と聞いてプログラム中の文字列を全部wchar_t型に置き換えるのかと勝手に決めつけ ソースコード中の文字列をひたすら_T()で括りstd stringはtstring(※1)に,その他ルーチンを対応の物に置き換えていたのだが 実際そんな単純な話ではない.例えば XMLパーサのxercesライブラリは元々内部表現としてunicodeを使用している為にANSIから変換するコードが不要になるし HLSLのクラスであるD3DXEFFECTはメソッド引数にANSIしか受け付けない(※2). Luaとやり取りする文字列に関してもシステム定数なんかの 「アルファベットと数字だけと分かっている」文字列はどちらにせよASCIIコードの範囲内だから unicodeで定義する必要はない(というよりASCII文字だけの場合はUTF-8にしようがコードは同一であるからむしろcharのままが自然) 他にはBOM(Byte Order Mark)のスキップやら対応してないエンコードを弾くなどの処理も必要だがこんな所である. ちなみにunicodeは仕様上最初の2バイトは必ずASCII文字であるので最初の4バイトを見ればUTFの何でエンコードされているか判別可能だ. そもそもなぜunicode対応(UTF-16)をするのかといえば WindowsAPIの内部表現がそうなっているから(ANSIだと都度変換がかかる) 日本語の扱いを簡単にする(全角も半角も同じ2バイトだから扱いが楽.ShiftJISのような2バイト目にバックスラッシュと同じコードが入って不具合を起こす事も無い) だった. しかしその後の調査で1番目はともかく2番目に関しては1文字につき基本2バイトだけど4バイトの文字(サロゲートペア)もある事がわかって利点が半分崩れる格好となった. LuaからC++に渡した日本語の文字化け回避くらいしかこれといった利点が・・・(※3) ※1 UNICODEがdefineしてあるかで分岐して std string か std wstring をtstringとしてtypedefした物. ※2 そもそもHLSLのコンパイラからしてunicodeに非対応,MSDNを見るに文字列型も仕様的にASCIIオンリーとしてある. ※3 しかし同じunicodeといってもExeで扱う形式はUTF-16,LuaはUTF-8なのでASCIIなら無変換で渡せるのに対しUTF-16では変換の手間があるという中途半端さ ~続く~ (visual studioで「unicode文字セットを使う」を選ぶと何が変わるの?という疑問が浮かんだので 調べたらUNICODEがdefineされるか否かだけらしい.なんとまぁ・・) (2011/05/24)#2 サロゲートペア 前回でUTF-8ならばluaでunicodeを扱えそうだという事がわかり, じゃあ早速UTF-8とUTF-16を相互に変換するルーチンをググって探して組み込めば良いだろう. と思いきや,暫しググった後 ふと「そんな細いの探すのも面倒だし元々相互変換しやすく設計されたんだからちゃっちゃと表を見ながら作ればいいのでは?」 (unicodeの理解を深める為にも!) そんな考えが浮かんだ. 実際やってみたら割とアッサリ出来た. んで折角作るのだからとサロゲートペアにも対応してみた・・・が.BMPに含まれない文字は,少なくともwindowsXPにおいて 付属のメモ帳はともかくvisual studioでさえ「・」や「□」(適切なフォントが見当たらない時の表示)になってしまい少々調子が狂う. これはファイルに保存する文字コードをUTF-8に設定しても変わらない.インターネットエクスプローラも駄目だ. しかしFireFoxでは普通に入力可能.結局アプリケーションに依るところが大きい. XPの内部表現がサロゲートペアに対応してないという事なんだろうか. まだXPで頑張るつもりの自分としてはなんとも残念な話だがVista以降は大丈夫でしょうな? (2011/05/24) LuaとUnicode そういやluaってunicode対応してたっけなぁと思い,調べたり. ソースコードをどの文字コードで書いたらOKなの?とか. 結論から言えばUTF-8でソースを書き動作させるのは可能である. 独自にShiftJIS対応したバージョンを開発して配布してる人も居るようだが 本家luaがバージョンアップした時にまたShiftJISバージョンまで待たされるのもアレだ(というか出る保証もないし). そんな訳で本家バージョンを使いつつなんとかする方向で行く. で,"lua unicode"などのキーワードでググって出てきたページでは 8bit目は問題なく処理するから対応してるどうのこうのとか小難しく言ってたが 平たく言えばluaは マルチバイト文字には対応してない 文字列はそのままバイト列として扱うから(0x00で終わってさえいれば)中身は関係ない そしてUTF-8の特徴は ASCIIコードと互換性がある 文字の2バイト目以降はASCIIコードが現れない である. この事からUTF-8でソースを書く事はコメントと文字列定数以外ASCIIで書くのと同義である. 文字列は先述した通りバイト列として扱われ,終端文字もASCII(=0x00)であるのでこれも問題ない. コメント文についても閉じタグがASCIIなので(以下略) luaのソースがUTF-8で書けるというのはそういう事のようだ. 基本的にソースコードをUTF-8で保存するだけでunicodeに対応できるが 当然luaから送られてくる文字列はUTF-8なので文字列表現にUTF-16を用いるユーザープログラム側で 変換をかまさなければならない. こうなるとゲームでの処理負荷が気になる所だが所詮は文字列.何百回もループするわけでなし気にしない事にする. (2011/05/16) Unicode ファイルパッキング自体は完了.ついでにUnicode対応もしてみた. 何故今までしてなかったかというと VC++でUnicode文字セットを使う設定にすると文字列の型がchar(1バイト)からwchar_t(2バイト)となるのだが ネットで調べるとUTF-8は1~4バイトだとか,UTF-16は2or4バイトだとか書いてあり 1文字2バイトにしたところでどうなんだと,合点がいかなかったからだ. 更にUTFはUTFでもUnicode Transformation Formatや, UCS Transformation Formatの略でもあるとかで 自分がUTF-8で調べて文字長が1~4なのと1~6なのとで混乱したのはこれの違いだった. え?UnicodeとUCSは違うの?どうやら少し違うらしい.訳がわからん.貴様らDVD+Rと-Rか. (コンピュータ関連各社が参加するユニコードコンソーシアムで制定されたのがUnicodeで 後にISOが国際規格として標準化したのがUCSのようだ. 当初は世界中の文字を1つの文字コードに統一する目的で別々に動いていたが途中で歩調を合わせるようになり云々・・) 個人的な理解は Unicodeで定義された文字全てを表すには21ビット必要でそれを満たしCPUにとって扱いやすいサイズは32ビット(4バイト)である. 4バイトを1文字とする形式はUTF-32と呼ばれる. 基本多言語面(BMP, Basic Multilingual Plane)は2バイト,それ以外は4バイトで表すのがUTF-16. ASCII文字を主に使うケースにおいてアルファベット1つに2バイト使っていたのでは無駄が大きすぎるという事で生まれたのが(多分) ASCIIコードの0x00~0x7fの範囲は互換性を持たせそれ以外の文字を1~4バイトの可変長で表すUTF-8. UTF-16を7ビット単位でしかデータを扱えない環境(メール送信とか?)でUnicode文字を送受信する場合にBase64などで細工をかました形式がUTF-7. またUTF-32とUTF-16にはそれぞれリトルエンディアンとビッグエンディアンの両方が存在しUTF-32LE,UTF-32BEと表記したりする. とまぁそんなところである. 話が長くなったが windowsXPで使われるUnicodeはUTF-16LE.単にUnicodeといえばUTF-16を指す事が多い. UTF-16は2or4バイトなので結局文字列処理の複雑さがShiftJISとかと変わらん気もしたが通常 BMPは2バイトで表される為に,特にゲームでは無視しても大丈夫なのだろう. でも「鮭(サケ)」は2バイトだけど「
https://w.atwiki.jp/slice/pages/155.html
(2016/09/30) 特に目立った成果も出せず9月も終わろうとしている。 プログラムも地味に続けてはいるが延々基礎部分を作って一生が終わりそうな勢い。 絵も言うほどは進んでないな? とりあえず、アニメ風の描写が苦手だったので練習。 見たまんま、注射器。オリジナルもなにも無い気がするが何かの丸写しでもないので フリー素材とする。透過pngなので何かに合成可。 こうして見ればマアマアだけど途中までが悲惨な出来で放棄しようかと思ったことが何度か。 そんなもんなのかね… 特に多いのが線画の線が浮いてしまうパターンで、細くして誤魔化したりとかしてる。 途中で統合って、わからんどうすんだ。 線画に着色も試したがそれはそれで違和感だし、線を半透明にすると「もう線無くていいんじゃない?」となる。 初心者にありがちな、メリハリが無くノッペリしてるのはバッチリ当てはまるし かといって影になってる部分を濃くしたりすると今度はわざとらしいという。 厚塗りにしても我流なので筆遣いが雑というか、いかにも初心者が時間かけて取り繕いました感が漂う。 塗り始めの時点で完成形が見えてないのが問題だろうか。 予定 引き続き絵とプログラムを地味にやりつつ、 raspberry pi3を手に入れてしまったのもあってオレオレwebページとかも少し興味出てるのでそっちの方の勉強も少し。 pythonも少し触ったのでblenderでエクスポートプラグイン書いてjson出力 - 自作ライブラリやwebGLで表示できればと思ってる。 あと先月買った人体の本も週に3,4回は開いて読む。 そんな感じで。
https://w.atwiki.jp/slice/pages/25.html
調整(2008/09/01) 本日はポータル作成のパラメタ調整してました。 浮動少数点変数の型はfloat使ってます。いやいやdoubleなんてシミュレータでも作らなきゃ必要ないだろー とか余裕ぶっこいてたら「ある頂点が平面上に存在するか?」という判定するときに丸め誤差で苦しめられました。 今回の場合はfloatが精度不足ではなくて自分が適当な実装してるからですけど。 float使うメリットってメモリ節約しかなさそうな気がするけどfloatでも出来る計算を特に理由もなくdoubleで計算するのは無駄な気がして・・ ゲームではAIに力入れるつもりだからその部分にメモリを注ぎ込むつもりで他は少しでも節約しておきたいとの思いも。 ぶっちゃけ今のPC事情だと仮に推奨メモリ容量1GByteでも余裕な気はしますが。 メーカー製PCでも普通にそれくらい載ってるしねえ。vistaも載ってるけど! そうそう、で ポータルは正常に作成できるようになりました。 実は(2008/09/04) 実はあの後ポータル同士の可視情報が「たまに」正常に判定できてないって現象が起きてまして。 原因究明に丸一日費やしてたり。 問題が起きるデータに関してバグと関係ないとこをどんどん省いていってやっと原因の関数を突き止めました。 突き止めただけなので修正しなきゃならんわけですけど、まだです。これからやります。 修正した後に他に不具合が出て無いかも確かめなきゃならんし。 ナビゲーションメッシュ(2008/09/09) はい、再び。まあでもポータル関連をいろいろ弄ったからってんで動作確認するだけです。 ついでに前は試してなかった立体交差マップの動作確認・・・したら案の定いくつかバグが。 とはいえ一発OKで動いた方が逆に気持ち悪いですけど。 さてさて直そうか。これから。 見た感じナビゲーションメッシュの連結情報がうまく設定されてないようだな。 ああそうだ前回の動画では「ナビゲーションメッシュを最短経路探索に使う」みたいな感じで紹介しました、が。 実は使いません 実際に動画その2でも使ってません ナ、ナンダッテーって感じですか。正確には「そのままは使いません」ですけど。 どうなってるのかはとりあえず明日にでも書く予定。 ↑の続き(2008/09/11) ナビゲーションメッシュを元に通路の角を検索してそこにウェイポイントを置く。 ウェイポイントって何かって?ぐぐってくださいすいません。 キャラが通れる道を定義する点です。 それらを使ってグラフを作り最短経路を計算する寸法です。 利点は、ナビメッシュだと主人公の後ろを取ったりとか複数の経路探索が出来ないが (できるけどすごく重い)通路の角同士を結ぶウェイポイントなら割と軽い処理で可能。 あとはナビメッシュ上を経路に沿って滑らかに動かそうとするとそれなりの計算コストがかかるが ウェイポイントなら単にポイント間を直線移動すれば良い。 そんな感じです。 進捗(2008/09/11) どうやら、細かいナビゲーションメッシュが密集してるエリアで ウェイポイント間のリンクが張られない場合があるなコリャ 原因究明中 超停滞(2008/09/15) ナビメッシュを直すと今度はポータルがバグり、逆も然り。 ずっとこんなことやってるなあ、もっとやる事ある気がするが。 動画作りたいが(2008/09/18) 時間的になんか無理そうなので小動画になる可能性大。 ナビメッシュずっと直してる。どんだけって感じ。 現時点では変に入り組んだマップにしなければ不具合が起こることも無いだろうけど、 ランダムマップだからそのへんの対策はしっかりやっておかねば。 ランダムマップの生成方法はとりあえずパーツを組み合わせる形式でやってみようかと。 パーツ組み合わせたらナビゲーション計算してライトマップ計算して敵やアイテムの配置と続きます。 本当はもっと凝った事したいけど当面はってことで。 火花・・・とか(2008/09/23) 火花みたいなエフェクト作成中 なんとか派手なのが作れればいいが。 動画・・ですか 無理無理無理無理無理無理無駄ァッ ちょっと休んでました(2008/09/29) これまでほとんど毎日のようにゲーム製作してて疲れたので動画を区切りにして ちょっと休暇みたいな。 今日辺りからぼちぼち再開です。 進捗状況のページを適度に分割しようを思ってたけどやってなくて でもさすがにページが上下に長すぎるので昔のログは月別に分けてみました 次だ(2008/09/30) 視錐台クリッピングっていったっけな? ちゃっちゃと実装してしまいたいが、いかんせん自分の能力が・・・
https://w.atwiki.jp/slice/pages/157.html
作業させないドラゴン レオパとアゲハ 描いた後にアゲハが小さすぎると気付いたけど無理やり拡大して見た所、 どうもしっくり来ないのでそのままに。 というか参考にした画像群にアゲハとキアゲハが混ざってたので模様も曖昧な箇所があったり等、色々思う所がある絵。 練習 模写です
https://w.atwiki.jp/slice/pages/97.html
(2012/10/31) メモリリーク ふと,メモリどの位使ってるのかなーと前回のデモを起動してみたら32Mbyte程度だった.まぁそれはいいとして ライト1個出す毎に5kb程度のメモリリークが. プログラム終了時の解放し忘れならともかく動かしてる最中にこれは不味い.直さねば (2012/10/30) windows8導入 アップグレードでサクッっと,別パーティションに. 今すぐ乗り換える必然性というのは無いのだが。なんとなく. たまにDirectX10(11)を触ってみたくなるのと対応ゲームも割と増えてきたとかは一応理由にはなるか. あとXPからのアップグレード(ダウンロード版)はちょっと気が乗れば買っちゃう値段だし・・(結局これが一番) メトロだったかモダンなんちゃらは全く興味ないので即効ClassicShellを入れ、フォントのアンチエイリアスも切った. メモリが相変わらず4GBなんで64bitにする意義があまり感じられないとか、案の定HDDが足を引っ張ってスコアが下がってるとか色々 ところで 試しにwin8で自作のプログラムを動かそうとしたらd3dx9_43.dllが無いとか言われて起動できなかったのだが,DX9は動かない? そんな訳ないよなぁ・・ #追記 というかD3DXって何処で使ってたっけ?と思って検索かけたらD3DXEffectがそうじゃないか.これは流石に外せない. 他にはD3DXCreateCubeTextureFromFileInMemoryEx,D3DXGetImageInfoFromFileInMemory,D3DXSaveSurfaceToFileInMemoryと,ファイル入出力系の関数が. 現状 HDRのトーンマッピングまでは行けたものの,その後のブルームエフェクトをかけるにあたり (何段階かに縮小してそれぞれガウシアンブラーしてってやつ) レンダーターゲット記述フォーマットの不備があってまたしても頓挫中. あと,画面サイズが例えば640x480の時にレンダーターゲットを640x480そのまま確保していいのか やっぱり2の累乗サイズ(この例では1024x512)で確保して一部分だけ使った方がいいのか悩む. 速度的な意味で. (2012/10/24) パーツを削除 Twitterパーツを排除。理由は重いから。 メニューを出したり畳んだりするスクリプトも排除。理由は(ry 上記の為だけに導入したjQueryもお払い箱。 デモについて アンチエイリアス(DLAA)が追加された。 内部は1500行程書き換えたけれど動作は変わらない。 前と違ってMRTの定義、管理とか別ファイルでちゃんとやってるしHDRあたりすぐ出来ればいいが、 今までの分からするとそうは問屋が卸さないのだろうな。 WebGLがwiki上で動かない トップのカウンタが急上昇してるのはなんのことはない、 自分がトップページにWebGLのポリゴンデモを載せようと悪戦苦闘してただけだ。 元々このwikiにはjavascriptを記述する為のブロック文が用意されてはいるんだが文法が妙で 他のファイルからインクルードしたければ script src="..." とHTMLタグを書くし(これマニュアルに載ってる?) もちろんjavascript文法をそのまま書けたりもする。 しかしインクルードとその他文法を一緒のブロックに置くと不正な文字列とみなされエラー(コマンドだだ漏れ) インクルードのsrcにURLを記述するわけだが、他のサーバーから持ってきたりするとページリロード5回に1回くらいの割合で 勝手にsrc="about blank"にされてしまう。 あの手この手で頑張ってWebGLを表示させるところまでは行ったものの、今度は他のページへのリンクやらが反応しなくなる。 これはWebGLコンテキストを取得した段階でなる様だ。その後すぐ破棄しても駄目。 正直言って訳がわからん。折角4年以上続けてきたatwikiだけど乗り換えようかねと思わざるを得ない。 ちなみに WebGLでテストしたソースはGitHubに上げてある GitHub RSJe (2012/10/20) Passは必要か HLSLのPassを今までロクに使ってなかったのでこれを機に頑張って対応はしてみたものの・・ Passは幾つかのシェーダーを1セットで使う時に 見た目と描画処理が若干スッキリする事くらいしか利点が無い気がする. 例えばTech Aの1pass目(エッジ抽出),Bの1pass目(ガウスフィルタ),Aの2pass目(何かポストエフェクト) という描画順序だとすればpassを纏める意味が薄い. この場合Bの1pass目に相当する宣言をAにコピペで加えれば良い話ではあるが同じような記述を何遍も書くのは,ちょっと. 内部的にも特にpassの切り替えでどうこうって訳でもなさそうだし OpenGL(GLSL)に至ってはPass自体存在しない(よね?). MRTが一般的でなかった頃のForwardRenderingにおけるマルチパス用途かなあ?と思う. Techの中,Passの外に書けて重複するステート設定を省けますよってんなら分かるが,それは出来ないようだ.よくわからん. 現時点であって困ることはないがOpenGL用に移植しようとなるとやはり不要・・ ちなみにVertexShader = compile vs_2_0 Func(); 等と書くコンパイル宣言はTechの外でも可能. というより複数箇所で使う場合にはその方が容量が小さくなる. ま,ともかく. 以前の表示が出来る段階までは来たのでデモまでもう一踏ん張りといった所か. #追記 とは言いつつも冗長とはいえステート記述をコピペして1纏めにするのも悪くない気がしてきた (2012/10/19) レンダーターゲットの管理 アンチエイリアス(DLAA)はサンプルをほとんどコピペして早々に完了していた。 しかし次のHDRを実装するにあたってブルームに必要なガウスフィルタ等を組み込む作業で 「この際レンダーターゲットの定義とかちゃんとしようと」仕様を決めてたら思った以上に大掛かりで てんやわんやしてる所である。 まだ延びるようであれば一旦アンチエイリアスだけのバージョンをv0056_1として公開してしまおうかと。 定義方法については2,3種類試した末に「別途JSONファイルとして記述」となった。 各RTのフォーマット、テクスチャとしての設定、クリア方法など・・ これに限った話ではないけどスクリプトやシェーダーはテキストデータなんで興味があればどうぞ。 現在もう少しで新方式で前と同じような描画が出来るかな?という段階。頑張るしか無い。 (2012/10/09) デモ更新 んーまあ,目新しい所といえばオートカメラとライトがランダム軌道で動くの位しか・・ 透明な円柱がちゃんと前後関係を考慮して描画される!とはいっても,こちとら数百回は見てるんでもう飽きた. あと色々変えてたらスキンメッシュが正常に描画されなくなってしまったので一旦除外しておいた.そのうち直す. 見えない所ではログファイルが出力されるようになっている, ウィンドウ閉じでプロセス残るバグの修正,透明物が視界に入ってない場合のカリング,アンビエントライト調整・・等. それ以外特に書くことがないので,次は見栄えのする更新がしたい. ゲーム以外の事 ちょくちょくとOpenGL(WebGL GLSL)をいじっていたり. Qtライブラリを最新版のgccでビルドしたいし,どうせならLinuxからLinuxとWindowsバイナリ両方を出力できたら便利だと思ったので Linux - Windowsのクロスコンパイル環境を構築しようと思い立つ. 当初,QtをWindows上のmingw32でビルドしようと思ったら,どうやら32bitWindowsのメモリ2GB制限でデバッグ版が生成できなくって ここで大人しくwindows7を買おうとなるなら技術者として失格な気がした. そんな訳で悪戦苦闘. QtはLinux - Linuxなら問題なくビルドが通るのだがmingw32でクロスコンパイルするとリンクエラーが出たりする. QSjisCodec QSjisCodec()がundefinedとか行って来るから仕方なく手動でそのクラスをコンパイルしオブジェクトファイルを突っ込むと 今度は_imp__XXXXなんちゃらかんちゃらがundefinedと言われる・・ので未完. ちなみにQt5で試すと今度は undefined reference to `__dso_handle と undefined reference to `__cxa_atexit が出る(もちろんターゲットlinux-g++では出ない) これってgccにおけるC++のコンストラクタとデストラクタ周辺の関数だっけ? もしかしてgccが新しすぎるとか? 誰か詳しい人教えて欲しい. 予定 サクッと2つほど視覚エフェクトを実装してデモ公開へ. アンチエイリアスとHDRとか? (2012/10/01) 遅れが目立つ 無念.結局あれからデモを出せないまま10月を迎えてしまった. 1ヶ月1回ペースとかじゃ(何となくだが)駄目.せめて週1ペースで行きたい. ようやく解決か・・? 当面の予定としては「とにかく一日でも早くデモを出す」事に終始するわけだが・・ 境界ボリュームを求める為の主成分解析がえらく難航している. 一応ルーチン自体は組めたけどいくつかの問題点が. 1. 物体が大き過ぎると行列の固有値が虚数になる 対称行列の固有値は実数になる筈 2. 球体,円柱など軸対称オブジェクトにおいて主成分3軸が求まらない 最後の連立1次方程式を解くと全部0になってしまう 1については適度に物体を縮小してやれば解決できた.浮動少数点数精度の関係だろうかね? floatはもちろん,doubleで計算してもなかなか厳しい様子.もしかしたら計算間違えてる可能性もある. 2はスマートに解決する手段を思いつかなかった. ので,どうせゲームだし大体でいいやと思い一度計算してみて駄目だったら 全部の頂点位置を微量ずつランダムに動かして再計算というある種の暴挙に出た. ただこれが割と上手くいってるようで2回目のトライで使ってるモデルは全部通る. 残る課題と妥協 これを利用した透明物体ソートの動作確認と,ライトの軌道制御がカクカクしすぎているのでパラメータを少し調整したらデモ出せそう. 複数モーションの補間についてはコーディングしたっきりで碌にデバッグをしていないのと やはりサンプルが難儀という理由で見送り.
https://w.atwiki.jp/slice/pages/66.html
(2010/10/30) ゲームとは直接関係ないけどDirectX11が気になる頃だね. Vista=DirectX10をスキップしたけど7から入る人って結構居るんだろうか? ジオメトリシェーダーやテッセレーションは名前しか知らないっす. 流行ってたHDRも触っただけで本当に「ちょっとやってみた」レベルだし・・ 今だとテクスチャへ静的に影の焼付けなんて時代遅れかもわからんね. こうなったらモバイル機器へ逃げるか?なんて思ったり思わなかったり. 片手に収まる機械で自作ゲームを動かすのは夢の一つでもあるから. さて,現在は当たり判定ルーチンに取り掛かって・・って前回書いたわけだが. 先週はなんやかんやで別の作業してたな. 確かコリジョンのデータ配置,更新タイプ考えたり メインで使うであろうゲームオブジェクト基底クラス(以後GObj)の整備 毎フレーム送られてくる"UPDATE"メッセージでは指定フレームだけ更新を停止するsleep()のような関数を用意. これで move_left(), sleep(10), move_right(), sleep(10) ... とやれば左右に10フレーム周期で移動する処理が簡単に実現できる. GObjのメッセージ受信の仕組みは のようにメッセージIDと対応する処理関数をテーブルとして一括記述し,これをステートと呼ぶ. ステートとはオブジェクトの状態を表す物で例えばアクションゲームの主人公なら 「停止」「ジャンプ」「ダメージ食らいモーション中」... となる. ステートを適用するにはGObj setstate(ステート)と,GObjの専用メソッドを呼ぶ. また特定部分だけ処理が違うけど他は同じにしたいという場合は Luaのメタテーブルを利用し setmetatable(ステート, {__index=ベースステート})とすれば良い. と長々説明してみたはいいが多くの人の感想は「なんのことやら」とか「だから何?」だろうな. (自分が何をしたかの確認の為に書いただけなんで別にいいが) (2010/10/19) Cでは配列インデックスは0からが普通だがLuaは1からッ 使っていれば案外慣れるもんだな. Lua変数にアクセスする時に面倒くさい手続きが要るのもあってそこで思考が切り替わるようだ. さておき,当たり判定の構造を表すIDを生成するルーチンなど実装. 最初におおまかな球で判定して当たってたら詳細なポリゴンで判定とか. 躓いたのは表現する手段.結論から言ってLuaではテーブルで表す事にした. 前提として基礎となる判定形式は球ならVolumeクラス,円柱ならCylinderクラスと言うように作りこんでおき それぞれに1からの連番IDを付加. (0からだとC++のルーチン実装の時に不便だったんで) 例えば {COLLISION.VOLUME, COLLISION.CYLINDER} とすると最初に球,その後円柱で判定の意味になる {COLLISION.VOLUME, {COLLISION.POLYGON}} ならば最初に球,次に複数のポリゴン・・・といった感じ. でまあC++からでもIDを生成したいよねってことでC++用の関数も用意. こちらは int calcID(int c_id, ...) と,可変引数を使う. 判定が1つ終わった後に次のレイヤーを展開するかはコリジョンIDにフラグをOR合成. 引数終了判定はこのフラグが付いてない時とした. Luaの例と同じ意味合をC++で生成すると 前者は calcID(VOLUME | PAIR, CYLINDER) 後者は calcID(VOLUME | NOTPAIR, POLYGON) となる. まだコリジョン構造を数値で表現しただけの段階だが,これからボチボチ中身を実装しようかと思う (2010/10/16) リソースはマネージャで読んだ後はオブジェクト指向ぽく [ハンドル] [メソッド名]でいちいちマネージャを介さず各種情報へアクセスするようになり扱いは簡易になった. それ関係の細かいバグ取り等もした. 進まない進まないと言いつつ,んまぁなんだかんだで. 今度は当たり判定の実装で悩む. 前のバージョンは極力条件分岐を減らす方向でテンプレートを駆使したコードを書いていたら プログラムが肥大化して処理が本当に速くなってるかわからん状態だったし 挙句コンパイルするのに時間かかるわメモリ1.2GByte以上必要とかなってたんで. 本当はどちらが速いか比較検討したうえで決めるべきだけど 激しく面倒だから現バージョンでは汎用性重視で書く(と宣言して踏ん切りをつける魂胆) 今時のCPUなら条件分岐よりメモリアクセス減らした方が良くないか? 幾ら間接参照が遅いからといってもキャッシュに収まればほぼ問題ないわけでしょ?等の理由もある. 前に頑張って書いたから捨てたくないのは山々なわけだが 本当メンテナンス制が悪かった.倍以上速くなければ採用したくないくらい. 肝心の当たり判定の中身はどこに置くかについては流石にLua側に置いていては遅すぎると思ったのでC++側で. (正確にはメモリ領域自体はLuaで確保してもらって中身の読み書きはC++で行う) となるとオブジェクトが移動したら都度書き換え関数を呼んでもらう事になるが・・・こればっかりは仕方ない. オブジェクトに更新フラグ持たせてそれが必要な時だけ転送というようにはするか. 結果的にC++とLuaで同じ意味合いのデータを持つ訳でちょっとスマートでは無いものの,これは妥協. 超大きいデータだったら毎フレームC++側から座標データを取り出して移動させてまたC++へ格納なんて手段も考えられなくはない. 遅いけど. (2010/10/11) 10月もそろそろ半ばだってのにまだメモリ周りいじってるんですけど・・ コードはあちこち書き換えてるハズなのに全然前に進まないの.もうやだ. 「処理の効率化のために極力間接呼び出しは使わない」とかやってた過去のコードに引きずられている. ここ最近の作業は実は,型で処理分けしてた部分を汎用インタフェースに作り変えてるだけだったり. ああ処理効率を追求すると本当に汎用性が下がるんだな~と実感. だがスクリプト使う時点で諦めろと. (2010/10/03) Luaでのリソースハンドルの扱い方がいろいろと矛盾してて試行錯誤 とりあえずコーディングまでは終わった(コンパイル通ったという意味) デバッグはこれからだけど実際動かせる段階まで来れば気分が違うものだ. で,また仕様変更. リソースの内部クラス初期化関数の引数はこれまでファイルを読む事しか想定してなかった. だからstringか,又は無し(ファイルを読まないリソース.カメラ等)だったのだが 先日のインプットデバイス初期化云々によりGUID等も使う必要が生じたため 汎用の構造体を渡し,そこに必要な情報を設定するようにした. ・・・メモ帳でああだこうだやってたのに書いてみればこれだけか.
https://w.atwiki.jp/slice/pages/140.html
(2015/10/08) またか。 そうなんだ。その、またなんだ。 別の絵の前座みたいな感じで練習がてら軽く描くつもりだったけど結局、ガッツリ系に。 プログラムはなんだ、その…いつも通り過ぎて書く気が。すまぬ
https://w.atwiki.jp/slice/pages/87.html
(2012/02/26) 進捗(web編) アコーディオンメニューは実際作ってみたら 正直言って操作性と視認性に疑問を感じたので止めた.入れ子にした所で重いしやはり見づらい. そもそも当サイトでは項目を畳む程のコンテンツがないという(ログぐらいか?) という訳でポップアップメニューに切り替え. 最初は既存のソースを参考にしようと探したが慣れないHTML+CSS+Javascriptというのもあってか 読んでもいまいちピンと来なかったのと 大した行数でもなし自分で1から書かなきゃ頭に入らない気がしたので,そうした. 楔形は出来たので後は組み込むだけ.クラス化は・・・するまでもないか. アクセスカウンタはページビューとユニーク訪問者数を表示させ,更に今日,昨日,週間で集計させる物が出来た. まぁ普通なので特記事項は無し. 自前web拍手的についてはまだ着手していない. どうせ作るんなら5段階評価も入れたいよね. 似たようなシステムで投票も出来そうだな.Googleの円グラフAPIでも使ってみようか 等とメモ帳に書き込んでいる段階. 日本語・英語対応についてはHTMLに両方の文面をそれぞれ異なったクラス指定で書き込んでおき 例えばHTMLがこうだとすると div class="Japanese" 日本語テキスト /div div class="English" English Text /div JavaScript側で $(".English").hide(); とかやって他方を非表示にすればいいんだろうか? ページ分けるのは管理の手間の観点で避けたい. デフォルトでどっちにするかはユーザーのブラウザ情報を使えば何とかなりそうだ. PHPでは確認したがJavascriptでは・・まぁ出来るんだろう. そしてスクリーンショットギャラリー. 巷ではLightbox2というのが流行のようだが 如何せん自分様がお気に召さないのでサムネイル一覧と詳細ウィンドウを並べた従来タイプ?にする, 現時点で恐らく半分程実装したんじゃないかと思う.詳しくは後ほどという事で. (2012/02/21) 迷走 ここ最近迷走してるようにしか見えないが,実際そうだろう. 前回「CSSだのjQueryだのAjaxだの沢山あってヤバイ」 と言っておいてアレだが,結局全部手をつけてしまった.だって互いに関連してるから・・ 流石にNode.jsだけは止めておく.あれまでやってたらもう一ヶ月吹っ飛ぶ. ついでに習得したweb関連の技術で作ろうと思っている物リスト. スクリーンショットギャラリー アクセスカウンタ web拍手的な物 アコーディオンメニュー又はポップアップメニュー 日本語と英語切り替え どの言語や機能を使えばいいかは目星ついてるつもり. 正直これだけあったら新規にwebページ作った方がいいんじゃ?と思っている. というか既にSQLとPHPが使える無料スペースを確保していたり. 本当に移行するかは別として. ゲームの方も少し書いておこうか.例のRUDPだ. まず,でかいパケットを自動的に分割して送受信できるようになった. その際オプションでフラグを指定する事によりファイルをバイナリで送れ,受信側は一時ファイルに保存するようにした. 幾つか数キロバイトのファイルで動作確認したら上手く動いているようだった. 対戦プログラムの方は. 各々の操作を受け付けて同期しつつ2Dスプライトを動かす所まで. 折角だからちゃんとゲームとして動くのかタイルベースのマップを表示して弾でも飛ばしたい(今やってる) あとこれはゲームとは関係ないがVisualStudio2010に変えてから早速右辺値参照やラムダ関数やauto変数を堪能中.便利の一言. しかし時たまシンボル検索か何かの処理がハマッってしまってメモリを食い尽くす謎現象が発生するのは何故. (2012/02/12) 現状 最近,WindowsよりUbuntuの起動時間が長いな・・ さてMySQL, PHPが一段落した所で 昔流行ってたCGIチャットをこさえて懐かしんでみたりした(こんなシンプルに作れたのか!) とりあえずC++からMySQLに繋ぐ方法がわかれば,今のスキルでオンラインスコアボード位は作れるかもしれない. 逆にwebから何か情報を入力してゲーム側に反映させても面白いかもね. その他SQL自体は複雑なデータベースから欲しい情報を効率よくクエリする物なんでSQLiteを使えばweb関係なく ゲームでも使えそうだなあ・・・などと夢は膨らむ. 最早ゲーム作りたいのか何がしたいのかわからんと突っ込まれそうだが折角PHP覚えたのだから 何かwebページを・・と思った時に,PHPだけではどうしても華がないというか. 基本的にサーバから読み出したらリロードかページ移動まで情報変わらないもんなあ. これも勉強して初めて知ったのだけど. と言うわけで今度はJavaScriptをやっている.ちょこっと触ってみたらCSSだのjQueryだのAjaxだのと. この辺はキリがなさそうなんでちょっとした自前のページ作る程度で切り上げないとマズそうだ. スクリーンショットのギャラリーとアコーディオンスタイルのメニューが作れればそれでいい. 話は変わってUDP通信クラス.大がかりなリファクタリングが終わり現在動作確認中. web70%, C++30%くらいの力配分なので進行が非常に遅いとはいえソース書き直すだけでこんなに手間取るとは思わなんだ. 完成すればデカいファイルも送れるようになる,筈.(対戦サーバ接続時に持ってないマップを即席ダウンロードだとか) 今まで面倒くさがって開発環境はVC2008を使い続けていたが,ここに来てようやく2010へ. インテリセンスがガンガン効くかと思いきや特に変わったことは無し.デバッガが若干軽くなったかもしれない. あとはインクルードパスや参照ライブラリの設定方法が変わってて設定し直したくらいか? そういやC++0xの右辺値参照とラムダ関数が使えるんだっけか.試してみよう. (2012/02/05) ネットワーク関係のあれこれ 取り組み中な事ばかりで 完了したと自信を持って言える項目は残念ながらないのだけど. 現在進行中リスト MySQL とあるキッカケにより.オンライン要素のあるゲームを作る布石. PHP これもSQLと関連して.触った感じLuaと似たような物かな.まだ基本的な構文と幾つかの関数を学んだ程度. UDPによる通信クラス 当然対戦したりcoopなゲームを作る為. 前回「ネットワーク関連の~」と書いたのがコレ. 同じく前回「描画関連の~」と書いた物はここ2週間放置気味なので時期が来たら書く. その他MySQLとPHPの練習のためにUbuntuをVirtualBoxに導入, 所謂LAMPスタックを構築したり文字のアンチエイリアスが気に食わんから切って 新UIのUnityも微妙だからgnome風味にしたり見よう見まねでカスタマイズ.などなど. PHPを勉強してるとwikiじゃなくて自分でwebページ作りたくなるね. で,ネット対戦に使う通信クラスだけど 前はTCPで実装していたのをUDPで組み直している.UDPじゃないと駄目って事もないが TCPではその仕様上「途中でデータをロストしたら再送し,確認が取れるまでは次のデータは送られない」から さほど重要でないデータ(エフェクト類とか)を送りたい場合に不都合だから. バイト単位で結合・分割される為にデータの切り分けが面倒だとかもある. いやいや,尤もな意見を並べてみたが本当の所は「UDPで作ってみたいから」である. 勿論単なるUDPでは送ったら送りっ放し,届いたかの確認も何もあったもんではないのでそれなりの工夫をする. そこで登場するのがReliable UDPという奴だ. http //www.4gamer.net/games/105/G010549/20100905002/ 実はこの記事を読んでたら実装してみたくてたまらなくなったというのが事の真相. あんまり詳細については書いてないのだがそこは自分で補完しつつ,つい先日 「ホストに接続・切断」,「同期処理」,「復帰処理」と一通り動くとこまでは来た. ちなみに通信の形態はP2P,格ゲーやシミュレーションゲームなんかで用いられるキー入力同期方式である. だが作りながらの仕様変更が祟って案の定スパゲッティコードに. あと1つ問題が.デカいデータを送れないのだった. 1つのUDPフレーム(一回のsend()で送るデータサイズ)は1500バイト程度に押さえないと経路の途中で分割されて効率が落ちてアレだし そもそも8000バイト以上送ろうとしたらAPIに拒否される. 解決は単純で,複数のフレームに分けて送ればよいのだがこれがなかなか一筋縄ではいかない. UDPは届く順序が保証されていないから届いたデータをソートする必要があるし, 前からある(分割されてない)フレームソートの部分はスパゲッティで触りたくないしで八方塞がり. と言うわけで1から書き直す事にした.動作確認も含めもう2~3日かかるだろうか. ひととおり通信プレイが出来るようになったら固定画面,2人対戦の簡単なゲームを作る予定. 簡易的なゲームホスト列挙サーバをSQLとPHPで作れる気がしているのだが・・・
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) 何の変哲もない、普通のキューブマップシャドウと 前に一度やってた、これまた論文通りの分散シャドウマップ つまり今回も特出した結果は出せていないという事だが、まあ中身は色々変わっているので自分的には良し。 この調子でバンプマップ、視差マップ、水面、ライトブルームといった感じで復習を進めていきたい。