2011/07/12

DarkPlacesというQuake1互換のエンジンがあったので最近気になっていたけど2010年の4月からNewsのページが更新されてなっかたのでエンジンも円熟して枯れたものになってんのかなーと思ってたんだけど、6月以降、更新頻度が高くなってるみたい。

作者のLordHavoc'sさんは家庭用ゲーム機版のNexuizの開発にも参加しているのでそちらも気になるな。この辺は詳しくないけど、Nexuizは元々DarkPlacesエンジンで作られたものだけど今回の家庭用ゲーム機版ではなんか知らんけど(おい)CryEngine 3に差し替えられた。んでなんかしらんけどフォークしたのがXonotic。

新しくリリースされたDarkPlacesエンジンでは実験的にソフトウェアによるレンダリング(3Dグラフィックスの描画をGPUではなくCPUで計算する)とDirect3D9によるレンダリングが追加されたみたい。どちらも今のところ推奨されていない。

ソフトウェアレンダリングの方はフレームレートが低いが描画自体はとても正確らしい。Direct3D9の方は影の生成処理がOpenGLの場合よりかなり遅くなるっぽい。どちらも今後の最適化に期待。

あと、6時間毎に自動ビルドされた開発版のダウンロードが可能になり、LinuxとOS X版を排除してその分サイズが小さいWindows 32bit版と 64bit版のビルドも新たに追加されている。

以下は用意されたバイナリではなく自分でビルドしたい場合のメモ。

DarkPlacesの配布物にはソースコードも同梱されているがWindowsでビルドする場合、visual studioのプロジェクトしか同梱されていないっぽいのでMinGWでビルドしたい場合は(つーか他の*nix系OSも含む)SVNリポジトリから直接開発版のソースをダウンロードしないとだめかも。いやWindowsバイナリオンリーのやつダウンロードしたからかもしんないけど。とにかくmakefileがあればいい。

ビルドには事前にDarkPlacesのlibjpegやogg等、依存ライブラリがインストールされている必要がある。

自分の環境ではmingw32-make 3.82とmake 3.81があってなぜかmingw32-makeだとダメでmakeだとコンパイルできた。

そのままmake releaseと打つとlinux版のビルドはじめちゃうのでこういったことを回避するためにmake時にmakefileで定義された変数の値を上書きする必要がある。

make release DP_MAKE_TARGET=mingwだけだとccがないと怒られたのでCC=gccも追加する。

make release DP_MAKE_TARGET=mingw CC=gcc

これでコンパイルが通るはずだけどインストールされているSDLのバージョンが1.3だとvid_sdl.cで使われているSDL_SysWMInfoがSDL 1.2と定義が違うので途中でコケる。
のでvid_sdl.cのコンパイルエラーで指摘された箇所のinfo.windowをinfo.info.win.windowに書き換える。

まぁdarkplaces-sdl.exeなくてもdarkplaces.exeだけでよければSDL版はビルドしなくても大丈夫だけど。

makeの変数って-eオプションで上書きするんだとおもってたけど、makeの内側に書けばかってに上書きされるのね。

DP_MAKE_TARGET=mingw CC=gcc make release -e

make release DP_MAKE_TARGET=mingw CC=gcc

どっちでもOK。

http://icculus.org/twilight/darkplaces/index.html

2011/07/08

WinDumpをローカルで。

ネットワークについて素人が書いているので間違いがあるかも。というかよくわかっていない。

メモ

  • tcpdump - パケットを解析するためのソフトウェア
  • libpcap - パケットを解析をするためのライブラリ
  • WinPcap - libpcapのwindows版。WinDumpやWireShar等、多くのソフトウェアで使われている
  • WinDump - tcpdumpのwindows向けの実装
  • WireShark - GUIで操作するネットワークプロトコルアナライザー


windumpでローカルのパケットキャプチャをしたかったのでhttp://wiki.wireshark.org/CaptureSetup/Loopback を参考にとりあえず解決。


以下は翻訳もまじえてるのでなんか変な感じ。

windowsのTCP/IPスタックではループバックインターフェイスを実装していないのでwinpcapではローカルループバックアドレスの127.0.0.1をキャプチャできない。(127.0.0.1がインターフェイスを使ってループバックを実装してないのでキャプチャできないという意味かな)
そこでMicrosoft Loopback Adapter等のネットワークアダプター(インターフェイスと同義かな?)を追加するが、これで期待通りの結果が得られるかはわからない。

Windows 7 での追加方法はhttp://blogs.wankuma.com/hatsune/archive/2010/05/13/189032.aspxを参考にした。

このアダプターは擬似ループバックアダプターを提供するが127.0.0.1では動作しない。このアダプター独自にIPアドレスを割り当てて使用する。
ループバックアダプターはシステム上にひとつしかインストールしてはいけない。
このループバックアダプタでキャプチャするにはWinPcap 3.1以上の必要がある。

ループバックアダプターのプロパティを開き静的にIPアドレスとマスクを設定する。
Windows 7 の場合、コントロールパネル -> ネットワークとインターネット -> ネットワークと共有センター
で左カラムの「アダプターの設定の変更」からMicrosoft Loopback Adapterを選ぶ。

WireSharkのwikiだと、そのあとarpやrouteコマンドをつかってるんだけどこれは必要なのかわからない。

とにかくループバックアダプターが使えるならWinDump -D でインターフェイスが表示される。
自分の場合はアダプターをインストール後にPCを再起動しないと表示されなかった。

んで自分で書いたプログラムとかの通信をループバックアダプターに設定した静的なIPアドレス(127.0.0.1ではない)で行うんだけど、この辺はよくわからない。自分で設定したのと通信するときの実際のアドレスが若干違うというかなんというか。arp -a で表示されるアドレスに適当に通信してるんだけど。IPアドレスとサブネットマスクとかよくわかってないので。まぁとりあえずキャプチャできてるので今は良しとしよう。


他にも方法はあってrouteコマンドでなんかする(?)みたい。

上記はWinPcapを使ったソフトウェアの対処法なのでTDIなどのカーネルモードで動作する低レイヤーのライブラリを使ったソフトウェア(TDIMonとかLocal NetWork Monitor等)ならそのままlocalhost(127.0.0.1)をキャプチャできるはず。

2011/07/01

std::vector<int> x;
はスコープを抜けると自動的に要素のメモリも解放される。

std::vector<int*> y;
上のように要素をポインタにした場合は勝手に解放されないので
自分で解放しないと要素はメモリリークする。

それぞれの要素を自分で解放する。

std::vector<int*> y;
y.push_back(new int(1));
    ....
for (unsigned int i = 0; i < y.size(); ++i) {
  delete y[i]; //配列の場合は delete[] y[i]
}
// イテレータで解放する場合
for (auto i = y.begin(); i != y.end(); ++i) {
  delete i;
}

自分で解放するよりスマートポインタとか使ったほうがいいのかな?

2011/06/30

ゲームとストーリーについて(仮)

http://www.choke-point.com/?p=9665を読んで、すこし前にゲームのストーリーについてなんか書こうとしたけど途中でやめたのを(ちょうど1年前)思い出したので、とりあえずのっけとこ。Braidを皮切りにっての時点でテキトーなかんじ。

"Braidを皮切りにストーリーをプレイだけで語るLIMBOのようなゲームが出てきた。いままでのストーリーを語るゲームはプレイ 部分とは別にストーリーを語ってしまっていた。これはこれでアリだけど純粋な(?)プレイだけで体験するストーリーを模索する方が好きだ。ストーリーを カットシーンで語るならゲームにする必然性みたいなのが薄れるし、映画の表現技法に囚われて表現の幅をせばめてしまったらもったいない。

ランダムな要素を上げ「プレイした個々の体験がストーリーになる」ゲームと「カットシーンでストーリーを語る」ゲームとの中間に「プレイでストーリーを語る」ゲームが出てきたってだけだけど。"

2011/05/07

MMDからMDDを吐く

 ::Update (5月19日) MMDBridge Ver 0.41に対応(たぶん)

MMDBridgeというクールなソフトウェアが公開されている。

・MMDBridgeは、pythonからアクセスできるAPIを備えており、それを使用して、
  MikuMikuDanceが描画している頂点・法線・テクスチャデータなどにアクセスできます。
・つまり、1フレームごとにほぼ全てのジオメトリ情報を他のレンダラに引き渡すことが可能です。

とのことなので連続したフレームを頂点モーフィングとして書き出すスクリプト
を書いてみた。

このスクリプトについて

3DモデルをWavefront obj、頂点モーフィングをNewTek mdd形式のファイルにそれぞれ書き出します。

以下のファイルで構成されています。
  • preprocess_mdd.py
  • export_mdd.py
preprocess_mdd.pyはMMDBridgeのスクリプトです。描画フレームが呼び出されるたびに頂点情報を./tmp/pre.expmddに追加で記録します。

最初のフレームは./out/export_mdd.objと./out/export_mdd.mtlとテクスチャも書き出します。すでに同名のファイルがある場合は書き出さないので別のモデルに切り替えたときは注意。
(obj書き出し部のコードはmmdbridge_octane.pyから引用)

すべての描画が終わったらexport_mdd.pyで./tmp/pre.expmddを元に頂点モーフィング情報を./out/export_mdd.mddに書き出します。

export_mdd.pyはMMDBridgeのスクリプトではありません。pythonから直接、実行してください。


ダウンロード

https://gist.github.com/960168

ダウンロードしたファイルはtarとgzipでアーカイブされたファイルなのでそれらを解凍する手段がない場合は、downloadではなくexport_mdd.pypreprocess_mdd.pyの各ファイル名の右側のrawと書かれたリンクをクリックして生のテキストファイルをブラウザから保存してください。

使い方
(前提としてMMDBridgeのインストールと使い方をわかっていることを想定しています)
MikuMikuDance Ver 7.35とMMDBridge Ver 0.41とPython 3.2で動作を確認
  1. export_mdd.pypreprocess_mdd.pyをMikuMikuDanceのフォルダに置く。
  2.  MikuMikuDanceを起動してメニューのMMDBridgeのプラグイン設定を開き、使用するスクリプトをpreprocess_mdd.pyにする。
  3. すきなフレーム数分、モーションを書き出す or 再生する(スクリプトの呼び出しタイミングの設定による)。
  4. MMDBridgeでモーションをフックしたあとコマンドプロンプトで python export_mdd.pyとするかexport_mdd.pyをダブルクリックで開き、どのプログラムで開きますか?みたいなのでpython.exeを選択して実行する。
  5. カレントディレクトリのoutフォルダにexport_mdd.obj,export_mdd.mtlとテクスチャとexport_mdd.mddが保存される。
注意点

頂点モーフィングの特性上、毎フレームの頂点情報を./tmp/pre.expmddにテキストファイルとして書き出していくのでハードディスクの空き容量に注意してください。

動かない背景オブジェクトなども律儀にかきだすので描画フレーム数によっては数GBを楽に消費します。

最終的に書き出す./out/export_mdd.mddはバイナリファイルなのでそれより小さくなりますが気をつけて下さい(たぶん5分の一くらい)。メモリが少ないとmddファイルを3Dソフトなどで読み込めない場合があると思うので注意。
背景ぬきでモデル単体で描画したほうが無難。

頂点モーフィングなのでカメラワークなどは保存されない。カメラは削除したほうが無難。

途中でオブジェクト(頂点数)が増減するとモーフィングにならない。

スクリプトの呼び出しタイミングをAVI出力時に設定していてもフレーム操作でフレームを移動させるとMMDBridge(ver 0.3)がスクリプトを実行し始める(頂点情報などはなしで)。

その他

NewTek mddは頂点モーフィングの形式としては割と一般的(というかこれ以外あまりない?)
だと思うので3D統合環境ソフトなら扱えるかもしれない。

とりあえずBlender 2.49bでは動作確認済み。Blender 2.5.xではmddを読み込むとモデルが崩壊。2.49bでもモデルが反転するので書き出したmddの座標系とか変える必要があるのかもしれないが数学に弱いのでそういうことはわかりません。たぶん右手系と左手系を変えるだけだけど3Dソフトウェアによって違うとおもうので...。
2.5.xで読み込む場合は一度、2.49bで読み込んだあとblendファイルで保存し、それを2.5.xで読む 。


http://www.geocities.jp/higuchuu4/
https://sites.google.com/a/render.jp/mmdbridge/home
http://www.dstorm.co.jp/dsproducts/lw9/developers/Technical_Data/MDDFileFormat.html
http://www.ef9.com/ef9/PO1.5/LW/PointOven_lw.html

2011/04/22

LuxRenderをBlender 2.5.xのレンダラにする場合...

 *追記-2 LuxRenderに同梱されているLuxBlendはBlender 2.4向けのものだった(たぶん)のでLuxBlendが組み込まれたBlenderがやっぱり必要だった。俺だめすぎる。

 *追記-1 最新の公式で配布されているLuxRenderをダウンロードしてみたらそもそもLuxBlendとPyLuxは同梱されている。のでわざわざ公式配布以外のBlenderをダウンロードしなくてもいい。つまりここに書かれていることはほとんど意味なし。

LuxRender0.8.x, Blender2.5.x共に枯れていないので自分でプラグインをインストールしたりするよりプラグインが組み込まれたBlenderをインストールしたほうが手っ取り早い。

GraphicAll.orgで親切な人々によって最新版や公式ビルドより最適化されたBlenderをダウンロードできる。LuxRenderやSmallLuxGPUをつかえるようにビルドされているバイナリもあるので、タイトルにLuxBlendやSLGと書いてあるのをダウンロードする。

LuxRenderやSmallLuxGPUは基本的には別途必要(同梱されている場合もある)。

インストールしたらアドオンを有効にし、レンダリングエンジンを切り替え、外部レンダラの実行ファイルにパスを通す。

2011/02/15

SDL_NumJoysticks()が返してくれる値は可変かと思っていたがジョイスティックを抜き差ししても返り値は変動しない。
SDL_InitかSDL_InitSubSystemでジョイスティックを初期化した時点の値しか返してくれないので楽に接続の増減の検知ができない。
SDL_QuitSubSystemでジョイスティックを一時的にシャットダウンし再度 初期化すれば値を更新できるみたいだけどこのへんのオーバーヘッドはどのくらいなんだろう。

http://forums.libsdl.org/viewtopic.php?t=4066&sid=c06d2c75884b3d50e74a9d6301926

2011/02/05

mingw(windows全般かな?)でSDLを使う場合にprintfやstd::coutが標準出力ではなくstdout.txtにリダイレクトされてしまうっぽい。

試してないので間違っているかもしれないけどSDLのライブラリをソースからリダイレクトしないようにビルドすればいいらしい。configureオプションに--disable-stdio-redirectオプションを付加してビルドしてlibSDLmain.aを作り直す。そのご自分のアプリケーションとリンクするときは-mwindowsをはずしてコンパイルする。

自分はBlender Foundationから提供されているバイナリをつかっているので一般的な解決方法化わからないが
#include "SDL.h"
#ifdef __MINGW32__
#undef main
#endif
のように#undef mainを定義して(__MINGW32__の部分は開発環境による)リンク時には-mwindowsと-lSDLmainをはずしてコンパイルすると標準出力に表示される。まぁよくわかってないので適当だけど。

SDLでglewを使う場合、SDL側のGL拡張と干渉するためNO_SDL_GLEXTを定義する
#include "GL/glew.h"
#define NO_SDL_GLEXT
#include "SDL_opengl.h"


http://sdl.beuc.net/sdl.wiki/FAQ_Console
http://d.hatena.ne.jp/gamesyokunin/20041226#p3