RPGツクール2000はPNGファイルの読み込みに対応している。 というわけでsusieプラグインでPNGを読もうとプログラムを書いていたら、とても下らない所ではまった。
typedef struct tagBITMAPINFO {
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO;
bmiColors が何故長さ１しかない配列なのか、パレットをどこに格納するのか悩んでいたのだが、何のことはない
BITMAPINFO *bmp_info = (BITMAPINFO *)malloc(sizeof(BITMAPINFOHEADER) + 256*sizeof(RGBQUAD));としてビットマップ情報とパレットをひとつのメモリブロックに格納できるようにする工夫であった（上の例ではパレット256色分）。 本当はメモリ確保もmalloc()でなくてしかるべきAPIでやるべきだろうが。 とにかく格別やる必要のないプログラミングは金輪際やらないぞ！と決意を新たにしたのである。
新マシンを組み立てて早半年、 AKIBA PC Hotline!で CPU、メモリ、HDDの価格調査を久しぶりに見て驚き桃の木山椒は小粒でもピリリと辛い。 何と我がマシンのAthlon1GHzは一万を割り、それどころかThunderBirdコア自体消えかかっているではないか。
メモリにしても全く冗談のように安くなっており、これはもうPC133(CL2)512MBでも買うしかあるまい。 そうすると半年前に７千円ほどで買ったPC133(CL3)256MBが無駄になるが… 今や２千円前後であるからしてまあいいか。
RPG用の良いマップエディタは何かないであろうか…とベクターで探す。 あるいはRPGで使用するデータの規格で良い物があれば真似したいとも考えたのだ。
マップエディタは結構たくさんあるが、どれもチップを配置するという程度の物であった。 J-RPGCreatorという RPG開発ソフトを見つけたが、どうもマップエディタの動作が重い。 これで作られた作品などをプレイしてみないと何とも言えない。
promotion@century21-hk.comとやらから同じメールが数十通延々と来ていて困る。 ここまであからさまなスパムを喰らったことがないのでどうしたものか首を捻りつつ手をこまねいている私であった。
今日も延々と続くスパム。
いつの間にかスパムが来ないようになった。
RPGを作る際、イベントをスクリプトで記述する事はよくある。 しかしスクリプトの文法やコマンド体系等の規格を考えるのは骨であるし、 それを解釈して実行するシステムを作るのはそれ以上に骨である。 しかもそうやって作った所で、自分しか分からない原始的言語が一つ生まれるだけのこと。
言語の規格については既存のフリーソフトで公開されている物が幾つかあるようだから、 それを真似するのも一つの方法ではある。 この不満をsugi氏に漏らしたところ、 「プログラム中に直接イベントの内容を書く手がある」 という一言を受け取り、これによってある方法を閃いた私であった。
イベントの内容を関数に書き、この関数をまとめてDLLに固め、実行時にロードすればどうだろうかと。 メッセージ表示などはゲーム本体がAPIとして提供し、イベント関数はこれを呼び出すのである。 ただマップ毎にDLLを作るのか、それともゲーム全体で固めるのか、 さらにはDLLのロードは実用的な時間で行えるのかといった問題が山積しており、 物になる考えであるかは未知数である。
「まあいざとなればDLLにこだわらず実行ファイルに直接くっつければ良かろう…」 それに…もしもDLLの関数をひとつロードする毎に システムリソースが消費されるような事があるとすれば、全く非現実的な考えだ。
韓国製の「辛ラーメン」のカップヌードル版を吉池で買って食す。 袋ラーメン版は結構美味かった記憶があるので少し期待したのだが…出来がかなり悪い。
蓋を剥がそうとしたら２層に別れて上だけ剥がれ、下はべりべりに破れてしまった。 さらに湯を注ぐ前に粉末スープを入れるようになっているが、袋が容器の口よりも大きいので入れにくい。 湯を入れた後も麺はほぐれずに塊となって箸で掴める始末。 スープはまあまあだがこれなら日清のキムチラーメンの方がずっと…。
半年前に買ったキーボードのＬキーの反応が悪くなり、プログラムを打つ時に結構ストレスがたまる。 98のキーボードなら何年でも、キートップが磨り減るまでも酷使に耐えるぞ！ まあ安物（石丸で４千円ぐらい）なので今度はマイクロソフトの製品でも買うか。 そういえばこれを買った時の石丸のおねいさんは、自転車で持ち帰れるかどうか心配してくれたいい人だったと反芻する。
サーチエンジンでたまたま目に入った 戦国史をプレイ。 午後２時から始めて５時間ぶっ通しでやってしまった。
戦国シミュレーションなのだが、自家が弱小勢力の内は周囲の強い勢力に従属しないとすぐに滅んでしまう。 また大勢力であっても、少しでも傾くと傘下の勢力が雪崩を打って裏切ってしまう点など素晴らしく面白く、 これまで脅かされていた勢力があっと言う間に没落するのを見るのは楽しい。
ユーザーインターフェースには使いにくい部分もあるが、 これは家の当主が一人で何もかもやるのは不可能というわけで内政や軍事を 「軍団」に任せるというシステムを活かす目的があるのかも知れない。
WinGL 0.12 beta のバグである、 「16bppモード時にパターンをロックすると落ちたりパターンの内容が壊れる」 の原因を追跡する。 その結果、PatLock2()はパターンにDIB部が無いとこの分のメモリを確保し、 PatDraw2()でDAR部からここに画像の内容を書き込むのだが、 そのPatDraw2()が呼んでいる描画関数が原因であろうという予測が立った。
ところが肝心のその描画関数はアセンブリ言語で書かれているらしくソースが無い。 作者にメールを出すか？
しかし実はこの問題は自分で描画関数を新たに書けば解決するのであった。 さらにはこの問題を追跡する労力と時間でその描画関数は楽に書けるのだ。 と言うか実は１年ぐらい前に既に書いていたりしたのだ…ああ…またしても無駄な時間を…！ と血涙せずにおらりょうか。
さてWinGLの描画関数を自作の物と置き換えよう…として急に虚しくなった。 こうもWinGLにこだわる必要があるのか？
ゲームが8bit色で作られるのが当たり前だった時代ならその設計は優れた物であり、 またWindowsやDirectXに疎いプログラマにとっては、優れたフレームワークであり続けている。 私にしてもDirectInputやDirectSoundやDirectMusicやらに関しては未だに、 それを使用するコードを読んだ事すらない。
しかしWinGLの最新ベータ版にはバグがある。ベータ版でない方は8bppしか使えない。 だが今さらDirectXに乗り換えるのも気が進まない… と思っていたらWinGLGetDD()という、内部のDirectDraw情報を得る関数を発見。
今の今まで隠蔽されていると思い込んでいたので、 「ヘルプかドキュメントに書いておいてくれ」と号泣する私であった。 まあいい！紆余曲折はあったがこれで素直にWinGLとDirectXを適当に組み合わせて使うことができる。
キーボードのＴキーがいよいよ効かなくなってきたので秋葉原へ赴き 「マイクロソフトインターネットキーボード」を購入。 さすがマイクロソフト、使い心地がいい…。
キーボードも一新してWinGLGetDD()でDirectDrawだ！と思ったら一撃でＯＳごと落ちる。 まあ結局ポインタの扱いを間違えた非常につまらない理由であった。
しかしDirectXを直接扱っての開発は何とも気の遠くなる話なのだ。 旧98のDOS上で開発していた頃はプログラムを一度実行する度にリセットしたりしたが、 その時代を彷彿とさせる。まあそこはどちらの場合も腕のへぼさ故という面が大きい。