ケロロ軍曹をやってる時間に起きたり。最近の土日の生活では考えられないくらい
健康的！(そうか？)
ちょろっと本屋に行ってファミ通WaveDVDを買って来たり。
DVD観ながらペットボトル潰し。あれ？まだDOAって出てなかったんだっけ？
とか思ったり。個人的に目をひいたのが「大神」。水墨画っぽい画面なのですが、
それが動くと、これぁスゲーなぁって感じ。技術的にはトゥーンシェーダーの
延長上にありそうな感じなのですが、水墨画の場合、線の太さがパラメータと
して重要な位置を占めると思われる(例えば太くするべき所とそうでない所を
逆にしてしまうと、絵としてナシな感じになる)のが、うまく表現されていそう
な所がなかなかスゴイと思ったのです。因みに、
以前なにげに水墨画の本を買った
時には、絵を描く道具としてのCG筆表現は当分無理とか書いてますが、
表示についてはなかなかどうして、今回見た「大神」も「モジブリボン」も
うまくやってそうだなぁと思ったりしました。ただ、ゲームというジャンルに
限って言えば、この手の映像表現は一度使ってしまうと(陳腐化して)二度と
使えなくなってしまうのが厳しい所だなぁと思ったりもします。
HairMakerのWinアプリ化続き。取りあえず一通りのキーバインドをメニュー化
してみたり。残るはPOV出力のパラメータダイアログの作成という感じ。
出張。帰着。ふぅ。
猛烈に眠くて死亡。
一日死亡。
ダイアログウインド上でのコントロールを開く練習をしてみたり。
.rcファイルの書き方さえ判れば、何も問題無しという感じ。
手で書くのなら、.rcファイルというフォーマットを使用する必要
は無いようにも思うのですが、ICONだとかイメージだとかを含むと、
うまくいかないという事なのかも。
出張。飲みで深夜帰着。
出張。
いきなり休業。
昼頃起床。
ソース整理の続き。途中ファイルをOpenして操作して別のファイルを
OpenしたらSegfaultで死んだり。原因はfree()してはいけない配列変数領域を
free()していた為、メモリ使用マップ管理がとちくるってて、
実際にSegfaultを起こすのはmalloc()になるという、ヘンテコバグを埋め込んで
ました(^^; GLUT版のでもmalloc()で死ぬ現象があったので、ヘアガイド本数の
上限を8192にしたような気がするのですが、実はそういう事だったらしい気が
してきました。修行が足りません。あと、GLUTやWinアプリではgdbが
使えないという問題があるので、スタックダンプのスタックトレースを見て
追いかけるという技を身につけてみました(^^;
ぐうたらGRADIUS Vなどやって過ごしたり。なかなか先に進めないなぁと
いう感じ。
save/loadを付けたり、ステータス表示を行なってみたり。
POV出力の所はパラメータをいじれる様にしたいのですが、数値入力だとか
の技をまだ習得していないので一端保留。
懲りずにGRADIUS V。クレジットが除々に増えていて、なんとか５ボスまで
辿りついたのですが、ちょっとこのボスは詐欺まがいの予感がしますよ？
結構豪快なレーザーを撃ってくる辺りは、敵ながら爽快という感じですが。
昼頃起床。ぐうたら過ごしてあっという間に夕方。
「GRADIUS V」を買ってみたり。
Webで先日のPostMessage()とSendMessage()の違いを調べてみたり。
SendMessage()はメッセージを送った後、その先の処理が完了するまで
関数が戻って来ない。逆にPostMessage()はメッセージを送るが、その
メッセージによる処理の完了を待たずに関数が戻ってくる。PostMessage()
は非同期メッセージの転送という事みたい。従って、RedrawWindow()で
RDW_UPDATENOWフラグを付けることでWM_PAINTを「Send」しているの
ならば、キーセンスイベントは描画が完了するまでキューイングされる
という事になるという事でしょうか。しかしながら、例えば
WM_PAINTメッセージをPostMessage()で実際の描画が完了する前に何度
も送るとどうなるのかは不明。動きからみると、描画中に送られてきた
WM_PAINTメッセージは消滅しており、次のメッセージが受け付けられる
タイミングは描画完了後に最初に受けたものだと推測されます。何故なら、
そうしないと結局描画イベントが溜まっていく事になりますから、
操作を止めた後も画面書き換えが止まらないという結果になると
思います。でも、そうならないので、描画の追いつかないフレームは
ロストしているという推測です。
ファイルオープンとか付けてみたり。問題は、今までコマンドラインで
ファイルを指定し、オープンできなければ終了という処理を行なっていた
のが、初期ファイル無しという状態や、既にファイルが読み込まれた状態で
別ファイルを読み込むといった、今までに無い状態が生じるのですが、
それらの状態に対して全く無防備という点でしょうか(^^;
あと、頭部オブジェクトと、ヘアガイドとは別データで管理していた
のですが(元々ヘアガイドの前身となるベジェ曲線リストに、頭部オブジェクト
も表示できる様にした結果が今の状態なので)、それぁデータ構造として
あまりにもよろしく無い状態の為、大幅なデータ構造変更を行なわなくては
ならない予感(^^;
ひと休みで「GRADIUS V」をやってみたり。グラフィックが今風なフル3D表示に
なり、ちょっと「斑鳩」が入ったような色味になっていますが
(ただし最初の方の面しか見れてないのでそこまでは ですが)、
TANE的には随分と良い感じになっていると思いました。
一番大きな違いと言えば、やられた時に面の区切りまで戻される方式
(ここではGRADIUS方式と呼びます)から、
最近のシューティングゲームでよく見られる、そのまま続きで復活できる
方式(ここでは沙羅曼蛇方式と呼びます)になっているという点でしょうか。
正確には、GRADIUS方式と沙羅曼蛇方式はコンフィギュレーションで
トグルする事ができるので、復活パターンの美しさに命を懸ける人には
GRADIUS方式に切り替えてプレイするのが良いでしょう。あと、
沙羅曼蛇方式では、オプションだけは復活時に拾う事ができますので、
はげちょろけ状態になって、連続死するという事は無いようです
(いや、ヘボなので連続死しますが(^^;)。
そんな訳で、III(スーファミ移植は除く)とかIVとか、素人門前払いと
いった感じがあったのですが、それから言うと随分と遊びやすくなって
いるように思います。ハマれるかどうかは微妙ですが、今の所、
TANE的には「悪くない」といった感じです。
ソース整理......ごちゃごちゃになって死亡(汗;
日付け越え前に帰着。
RedrawWindow()のRDW_UPDATENOWフラグを外したら、めっちゃビンゴでした(^^;
postとsendの違いがイマイチよく判っていないというか、RDW_UPDATENOWの
有無で動きがどう違うのかイマイチ判らないというかそんな感じですが、
取りあえずOKそう。
急速に眠くなって死亡。
出張。帰着。ふぅ。
KOJIさんより掲示板にて助言をいただき、それを元に色々こねくりまわした
のですが、結局 結論としては、メッセージキューからWM_SYSKEYDOWN,WM_KEYDOWN
を削除するという方法でないとうまくいきませんでした。
まず、SendMessage()でWM_PAINTを送る事自体は本質ではありませんでした。
理由はRedrawWindow()に変えても何も変化が無かった事、3Dではアングルを
変えると殆どの場合、全面書き換えとなるので、部分最適化は今回の問題
の解決には恐らく繋がらないという事なのでしょう。
次にマウス座標取得をGetCursorPos()＋ScreenToClient()で行なう様に
しました。これにより、マウス座標のキューイングは行なわれなくなり、
マウスカーソルに3Dカーソルの赤い点が追従する様になりました。
恐らくGetCursorPos()によりまさに今マウスカーソルのある位置を取得
できるからなのでしょう。
しかし、キー押下はバッファリングされている為、キーを離しても
しばらくアングル変更モードに入ったままとなる期間は生じました。
結局、画面書き換えを行なっている最中に、キーを押している事が
キューイングされ続けている事が原因であるため、画面書き換え
中のキー押下を受け付けない様にするか、画面書き換え完了と同時に
キューイングされたキー押下メッセージをフラッシュするしか、
うまくいく方法は無いという結論に至り、Win32APIのリファレンスを
眺めていた所、PeekMessage()なるAPIを発見しました。で、以下の様に、
:
case WM_SYSKEYDOWN:
case WM_KEYDOWN:
{SHIFT/ALT/CNTLキーの状態フラグ更新}
{
MSG msg;
PeekMessage( &msg, hWnd, WM_SYSKEYDOWN, 0, PM_REMOVE ) ;
}
break ;
出張。
出張。
昼頃起床。ぐうたら過ごしていたらあっという間に夕方(汗;
先日のキーバッファリングによるスローダウンの話について、
掲示板にてKOJIさんより御教授を受けました。ところが、どうもイマイチ
うまくゆかないといいますか。まず問題点について整理してみました。
簡単化の為、マウス系メッセージについては一つにまとめて、
キーの状態はGetKeyState()で取得する様にしました。
case WM_LBUTTONDOWN:
case WM_LBUTTONUP:
case WM_LBUTTONDBLCLK:
case WM_RBUTTONDOWN:
case WM_RBUTTONUP:
case WM_RBUTTONDBLCLK:
case WM_MOUSEMOVE:
{
__GLUW_mouseX=LOWORD(lp) ;
__GLUW_mouseY=HIWORD(lp) ;
:＜略＞
if (GetKeyState(VK_SHIFT) < 0){ /*** VK_CONTROL,VK_MENU(ALT) も同じ要領 ***/
__GLUW_ACS_keystat|=GLUW_SHIFT_KEY ;
}else{
__GLUW_ACS_keystat&=~(GLUW_SHIFT_KEY) ;
}
:＜略＞
if( gluw_mouse( __GLUW_ACS_keystat, __GLUW_mouseB, __GLUW_mouseX, __GLUW_mouseY )!=0 ){
SendMessage( hWnd, WM_PAINT, 0, 0 ) ;
}
break ;
}
昼頃起床。
ぐうたら過ごしてから、暑いので丁度良いかもと風呂掃除したり。
HairMakerのWinアプリ化作業を行なってみたり。先日作成したテストプログラム
と同じノリで切り離して、とりあえず表示する所はできてみたり。
マウスもそれなりに動かせるのですが、視点切り替えの為にALTやCntlといった
キーのセンスがイマイチ期待と違う感じ。WM_KEYDOWNやWM_KEYUPといった
メッセージを拾って、押しているか否かのステートを更新しているのですが、
どうも押しっぱなしにしていると、何度もWM_KEYDOWNが発生する＆バッファリングされている
ようで、それのせいで何やらスローダウンしてしまうというか、反動でしばらく
勢いが付いて視点変更が止まらないというか、そんな変な感じになって
います。もしかするとマウスカーソルのモーションもバッファリングされて
いる為なのかも知れませんが、どうすれぁいいのやら。
出張。帰着。ふぅ。
何気にCygwinのMailingListアーカイブを眺めていたら、mmap()の
バグについての投稿があり、勘で読んでみると、どうやら
例のmmap()バグが遂に
潰された模様です！バグの原因も当時調べた結果とほぼ同じ事が
リプライされているようです。流石に本気で直している為、
変更個所は多いですが、これでWin9xを使っている人でもppcsimが
安心して使用できるというものです(＜使ってる人居るのか？)。
という訳で、fork()性能改善パッチだけをあててビルド。
malloc()テストを実行してもずっこける事は無くなりました(^_^)
それにしても、TANEがこの問題にぶつかってから１年以上経った
今になるまで、あまり問題になる人が居なかったというのが、
不思議不思議。Win2000やWinXPへの移行の方が進んでいると
いう事なのかも。てゆーか、Win98系はメーカーの製品サポート外通告が出てた
訳ですから、むしろ今になって発見された事の方が不思議なの
かも。
そういや、cygwin1.dll非依存のバイナリを生成する際のgccオプションに
ついて勘違い。gcc --target-helpで確認すれば判る話なのですが、
-mwin32 Set Windows defines -mwindows Create GUI application -mno-cygwin Use the Mingw32 interface
出張。
出張。
もう一日休業。だんだん悪化している気が.....
試しにGLUTで遊んだプログラムを使って、GLUTの分離を試みたり。
glutDisplayFunc()や、glutReshapeFunc()で登録する関数を
WM_PAINTやWM_SIZEなどのメッセージに対応付けて実行する様にして
みました。何故かglMaterialfv()を実行するとSegfaultで死んだり、
WM_SIZEやWM_PAINT内でprintf()を使うとアクセス違反を知らせるウインド
がどうにも閉じない状態の半死状態プロセスが残ったり
する謎にはまりながら、どうにか動く様にしてみたり。
まるでWindowsアプリみたい(笑。
ファイル指定方法がGLUT+コマンドラインとでは大きく変わるので、
そこんとこをどうするか考えて、とりあえずHairMakerの
Windowsアプリ化を行なってみる事を画策中。パラメータ類の変更だとか
をどうしようかと思いつつ、結局ほったらかしにしていたのがどうにかなると
良いなぁ。
本日も休業。
OpenGLとWin32APIから使う方法について探ってみた所、どうやら
PIXELFORMATDESCRIPTOR なるピクセルマップの書式を割り当て、
wglCreateContext(),wglMakeCurrent()でOpenGLの描画先を生成
してやる事で、gl*(),glu*()系描画関数を普通に使用できると
いう仕組みになっているみたいです。GLUTが担っていた
ウインドの初期化だとかイベントハンドリングなどを自分で
メッセージ処理する事で、w32apiとOpenGLとを共存させる事が
できるという感じ。GLUTで行なっていた、キー入力、マウス入力、
再描画処理、などをどう置きかえるか、ちょいと考えなくては
ならない予感。
なんか具合悪くて休業。一日中寝てたり。
復活した所で、先日購入した「猫でもわかるWindowsプログラミング」の本
を眺めてみたり。
Cygwin上でcygwin1.dllに依存しない実行ファイルを生成するにはMingwを
使用する(gccで-mwindowsオプションを指定する)という程度は判るのですが、
例えばメニューバーを生成する方法が判らなかったりと、Mingwを使うとして
果たして使い手があるのだろうかと思ってました。そんな訳でその辺の調査を
行なってみる事にしました。で、どうやら猫のサンプルとかを眺めてみますに、*.rcに
メニュー構造の記述があり、それを何かしらの方法でバイナリに変換して
リンクするという事が判りました。*.rcの変換にはwindresというbinutilsの
コマンドを使用すれば良いという事が判ったので、早速、猫のサンプルを
ビルドしてみた所、一応できたので rcファイルをハックしてみる事に。
とは言っても、通常、ウインドデザイナのようなツールでもって自動生成
されるモノの様で、メニューの部分以外は触らないのが良いという感じ(^^;
それを差し引けば、メニューを増やしたりする程度は問題無い感じです。
後、日本語(SJIS)でメニューアイテムを書くと文字化けする様子。
windresのオプションに言語指定ができるようなのですが、HEXで何かを
指定すれば良いらしいのですが、具体的に何を指定すれば良いのかが
不明。
OpenGLをうまくひっつける方法があれば良いのになぁと思ったり
もしているのですが、GLUTを使った例が圧倒的に多くて、それ以上の事を
やろうとするとgluiやQtなどに行きつくという感じ。因みにgluiは使う
のを躊躇しているのですが、理由は「常にCPUを食っているから」です。
GLUTのフルセットを単にメニュー付きのWindowsの枠にはめ込むだけで
良いのですけどねぇ。
昼過ぎ起床。
ぐうたら過ごして、ちょっと出かけて一日終了。何故かひがな一日、
猛烈に眠くて何もせずじまい。イカンイカン。
攻殻観たり。ぴひゅー。
出張。帰着。ふぅ。
早めに帰ってきて床屋に。それにしても、普段、日中に外を歩く事が
なのですが暑いです。すっかり夏ですなぁ。
gcc-3.4.1が出ていたのでppc-gccのクロスコンパイラをビルドしたり。
ビルドはエラーなく終了。povrayをmakeして確認した所、ほんの少し
(0.00004%くらい)実行命令数が増えているようですが、コンパイラと
しての動作は取りあえずOKそう。
以前、うちのBBSで教えていただいた^Cさん
のホームページの日記で、Windowsのコンパチビリティについての
話題を読みました。その中の、Windows3.1版のSimCityにおいて、
アプリケーションバグの為、Windows95では動作しない状況にあった
のを、動作するようにカーネルの中に特殊コードを組み込んだという
話に正直少し感動しました。こんな状況が仮にUNIX系OS上で発生した
としても、一切まかり通らないと思われるからです。
しかしながら、そこまでやる理由というのは
こちらでも書かれている様に、ユーザー視点から見た事を考えればもっとも
な訳で、ユーザーにしてみればOSにバグがあるのかアプリケーションにバグが
あるのかはどうでも良くて、とにかく動かないのでは用事にならないと言うに
決まっているからだと思います。普段使っているアプリケーションが動かない
のに「新しいからそちらのOSの方が良い」なんてのは理由にならない訳です。
技術的に美学に反すると感じても、結果的にその方がトータルで考えて
メリットがあると判断するならば、特殊対応を行なうというのはアリな考え方
だと思います。
そういえば最近職場でWindowsXPを使う様になったのですが(今まで
SunOS系UNIXを主に使っていました)、なかなか安定していて良い
なぁと思っています。ただ、タスクバーは見た目整理されている
様に見えて使い勝手も良さそうに見えるのですが実際に使ってみると
合わないといいますか。私の場合、一度起動したアプリはしばらく
閉じない上、だいたい使うものが決まっているものですから、
起動の順番を決めてタスクバー上の大体同じ位置に「いつもの」が、
配置されるようにしています。そんなもんですから、
アプリケーション名で整理される事には全く意味が無い上、
同名アプリを複数起動している場合に、
ポップアップメニューが出て一発で目的のウインドが出せないのが
個人的にちょっとイマイチな感じはしてます。
深夜の映画で「AKIRA」をやっていたので観たり。10年以上ぶりに観たの
ですが、普通に観て面白いなぁという感じでした。
流石に当時の未来予想よりは今の方が少し進んでいるようで、例えば、
町の中で人が沢山いるような場面では、携帯電話を持っている奴が一人も
居ないハズは無いとか、コンピューターや計器はもう少しデジタル化が
進んでいてもおかしくないといった感じに思いました。後者については、
劇中、意外と紙ベースのシーンが多く出て来たり(流れ出てくるプリント
出力は描くのも相当に面倒に違いない(^^:)、SOLが破壊された直後、
端末が火を吹いたり(あり得ません！)、機械の「何やら訳の判らなさ、難しさ」を
表現する演出だとは思いますが、今となってはレトロな表現が沢山出てくるなぁ
というのが、久々に観て思った点かも。絵そのものについても、
柱のパースを視点によって合わせたり、今ではCGを使えば楽勝な点も
手描きなので(確かCGは、あのよく判らない何かのパターンを示すあれ
くらいにしか使っていないという話もあったような)、その点では、
現在のアニメーションは各段に絵が良くなっている事がうかがえます。
出張。
出張。
出張。
出張。
出張。
昼過ぎ起床。
ちょろっとTVを観てたら再び眠くて死亡。寝過ぎ(汗;
食事を買いにお出かけ。ファミ通WaveDVDを購入。
メシを食べながらファミ通WaveDVDを観たり。E3後という事も
あってか、新作映像が多かった様に思います。個人的には
鉄拳５の
風間一族
女子キターー
ってとこが(＜ってそこかよ)。いや、もうね、
こんな感じだからね、
仕方無いんですよ。そんな感じで楽しみにしています。ただ、
アーケードは2004年稼動開始みたいですが、ゲーム機移植版は2005年
発売らしい....って遠いなぁ.....
そういや鉄拳シリーズも(多分バーチャも)、もう10年に渡っての発売
となるのですね。１とか２ってついこの前って感じがしていたの
ですが、改めて言われてみるともうそんなに経つの？って感じ。
そんなに経つのと言われれば、グラディウスシリーズもそんな
感じかも。85年から数えて新作のＶまで、おおよそ20年ってもんだから、
一つの歴史を刻んでいるという感じがします。30年とか50年
とかに渡って出たらそれはそれでスゴいよねとか思ったりもしますが
どうでしょう。
ども。たしかに青いとくれば「ブルーハワイもの」しか
思い付かないのは確かですね。主観ですが、青いと「ソーダ味」か、
何故か「異常に苦い」かのどちらかしか思い付かないです(^^;
冷蔵庫。自炊でもすれば自動的に
必要になるのだと思いますが、それが無いのでやっぱ要らない
って感じ。そんなだから、食べる分しか買わなくなるので、生ゴミ
も殆ど出ないのですが、たまに具合が悪くなって外に出るのも
ままならない状態になった時、食料が無くて地獄を見るのだけが
どうにかならないかなぁと思う時はあります(^^;
来週は土日休み欲しいなぁ.....そんな感じで明日から出張です。
出張｡帰着。ふぅ。
眠くてウトウト。「モンキーターンＶ」を観てから死亡。
出張｡
出張｡