8.31.2008

浮気ばかりでごめんなさい。

SDLで2Dをいじりながらも、やっぱり3Dが楽しそうやなぁと思う今日この頃。
そんなわけで浮気しちゃいました。

っていうか、3D関連のほうが作っていて楽しいし、動いても楽しいんだよね。

まずはモデルの表示と、それにテクスチャを貼るだけ。



CypherS TufTさんのラグナロクキャラクターの3次元モデルを利用させてもらいました。

こういう扱いやすいモデルをおいていて下さるサイトさんが少ないので重宝してます。

んで、今後はこれを動かせるようにしたいなぁと。
もちろん先日入手したジョイパッドで(笑)

アニメーションをつけるには、RokDeBone2というツールが便利そう。
Xファイルへの書き出しもできるみたいだし。

先んじての問題は、私にセンスがないということと、ライブラリについての学習がぜんぜんできていないってことかな。

気になっている人のために言っておきますが、Delphi + QuadrupleDが制作環境です。
付属のドキュメント以外にドキュメントらしいドキュメントが転がっておらず、検索結果では一見ドキュメントっぽくみえても、私のように書き散らしただけのものだったり、ドキュメントとして機能してくれるドキュメント、特にサードパーティー製のドキュメントが皆無に等しいので(何回ドキュメントって言った?)、リファレンスを読みつつ、試行錯誤的にがんばっている状況です。

今後はしばらく、これに絞って遊んで行こうと思ってますよ。

8.30.2008

SDLよぉ!私は帰ってきたぁぁぁあ!!!

タイトルに意味がないのはいつものこと。そん
そんなわけでLesson27.
アルファブレンドのサンプルコード。

SDLを用いれば、アルファブレンドも値を設定して
SDL_SetAlpha( 透明度を指定したいサーフェス, 方式, 透明度 );
って関数を呼び出すだけで、簡単にサーフェスの透明度を指定できる。
あとは下地になるサーフェスの上に重ねて表示させてやれば、アルファブレンドが完成するというお手軽さ。

ノベルゲーム作る時なんかはサーフェスごとに透明度を設定できるわけだから、キャラクターのサーフェスはそのままで、背景だけフェードアウト→場面転換というような演出をするのには重宝するかもね。

あとは、雲のサーフェスを青空に重ねるときに、アルファブレンドを施してホンモノっぽく見せるとか。
(まぁ、雲のサーフェスが時間とともに動くような状況でもない限り、一枚絵で用意しちゃった方が簡単なんだけどね。)

そんなわけで、いつもの通りアイディアだけは浮かんできますな。

画像はサンプルプログラムを実行した時の画面。
フェードインとフェードアウトに使う画像だけこちらで作成、差し替えました。

キーボードの上キーと下キーで透明度を調整できるようになっている様子。
なかなか面白い。

これってクレーマー?

こないだブログにも書き散らしたり、本部オフィスにもブロークンなイングリッシュでメールした効果だろうか?
Delphi7のUpdateが利用できるようになりましたってメールが来ましたよと。

前回紹介したサイトからは(落とすだけ落として)まだ利用していなかったのでありがたい限り。
なにせこちらは公式のお墨付きだもんね。

さっそくおとしてアップデート。
でも、アップデート中に思った。

これってクレーマー?(笑)

いや、受けられるべきサポートを正当に受けようと思っているだけだよね……?

# そんな気持ちが、実に短い文面ではあるものの、お礼のメールを書くに至ったのかもしれない(笑)

8.29.2008

Joystickを華麗に操る。

SDLのLesson 25。
しばらくSDL触ってなかったけど、案外覚えてるもんだ。

んで、先日某カメラ量販店にて、580円でジョイパッドを手に入れてきた(モチロン10%のポイントもつけてもらった!)ので、それを試すべくLesson25に挑戦しようと思った次第。

ざっと組んでみてだけど、SDLのJoystickの扱いは、まるでファイルを扱うようにして扱えるというところがポイントだと思った。
デバイスをファイルという形で抽象化するのは、UNIXの文化なんだってね。(どっかで読んだ。)

ともかく、そのおかげで
・Joystickへのポインタを定義する
・SDLサブシステムを初期化して、Joystickが接続されているかどうかを調べる
・Joystickが接続されていたら、先ほどのポインタにSDL_JostickOpen( number )関数を使って、Joystickへのハンドルを割り当てる
・SDL_Eventを通じてJoystickから投げられてくるイベントを処理する
・使い終わったら、ハンドルを閉じる
というごく単純なステップでJoystickを華麗に操ることが可能になっている。

応答速度もそれなりなので、簡単な2Dのアクションゲーム程度なら処理できそう。
(もちろん、OpenGLやらDirectXやら使って3次元のシューティングとか実装した場合にも対応できると思う。)

せっかくジョイパッドを手に入れたし、なにかこれを使って遊べるゲームでも組もうかと思う今日この頃。

不思議な不思議なDirectX

という訳でDirectXの話。

SDLといい、まるでゲームプログラミングブログだな。
楽しいからいいけど。


さて、このDirectX、前にSDL+DirectXで簡単な三角形を表示させた時には取り上げなかったけれど、DirectXっていうのは実に奇妙な挙動を示す。
これは、ほかの言語から使っても同じ。
(たとえば、私はいまさっきDelphiからDirectXを利用するコードを書いたけれど、やっぱり同じだった。)

それはどんな挙動か?
それは、対象のウィンドウを乗っ取るという挙動だ。

SDL+DirectXで参考にしたソースコードを見直してみればわかると思うけど、描画するべきウィンドウのハンドル取得している。

おそらくウィンドウズは、DirectXから「これこれのハンドルをもつウィンドウについて、描画権をよこしなさい」といわれると、まったく反論できずに描画権を渡してしまうんじゃないだろうかと。
そう考えると、結構アレゲなライブラリなんだね。
DirectXって。

ともあれ、DirectXを利用するならSDLかますよりもDelphiから使った方が便利そうだというのがわかったから、DirectX叩かなくちゃいけないゲームとか作るときはそっちにお世話になろう。

なにより、Pascalがとても書きやすいし(笑)
C++とは大違いだ。
やっぱり理解している言語っていうのは差がでるものなんだね。

8.28.2008

ジェダイの騎士は強かった。

マックよりモス。
ロッテよりモス。

そんなモス派のケチャップが、午前4時半ぐらいをお知らせします。


深夜です。
最近体調がおかしくて、変な時間に起きてしまいます。

さて、先日Delphiの話を持ち出したのに、実はシステムを再インストールして以降、PCにDelphiを入れていなかったことに気づき、急きょインストールしました(笑)

そしたらCodeGearのサイトからDelphi7.1のアップデートパッチやらドキュメントやらがダウンロードできなくて、今日まで方々探してましたよ。

結論からいうと、ダウンロードできるところは見つかったんんだけれども、まずはCodeGearの日本オフィス曰く、「本社のサーバシステム移管の関係で、ダウンロードできない状態になっている。復旧のめどは立っていないが、早急に必要であればCDに焼いて送付しますよ」とのこと。

おかしな話だろう。
Delphiが製品として優れてるのは知ってる。
CodeGearがソフトウェア作りに関していい仕事してるのも知ってる。
でも、サポート体制がこれじゃ、顧客から見放されるのも無理無いと思ってしまった。
少なくともマイクロソフトに似たような事柄でデッドリンクを報告したときは、直しときましたからお好きにどうぞ的なメールが返ってきたのに。

CDを送付してもらうにも手間がかかるから、結局ネット上を調べたところ、どうやらCodeGearのFTPサイトにはファイルが置いてある様子。
っていうか、FTPに置いてあるならリンク修正するだけじゃないかw
「仕事しろw」とか思いながら、FTPにあるならきっとまとめページがあるハズ!とぐぐってみると、やっぱりありました。まとめページ。

それがこちら

このくらいの代替えページをさっと用意して使ってくださいって体制をとるぐらいのサポートは、やってくれてもいいと思うんだけどどうよ?>CodeGearさん

# 余談だけど、今はCodeGearってのはEMBARCADERO(えんばーきゃどえろ?)って会社の一部門らしいね。




んで、ここからが本題(笑)
SDLにハマってるってことのつながりで、DelphiにもSDLバンドルがあるだろうってことで探したら、JEDIってプロジェクトがSDLバンドルを作ってた。

でも、これ、ソースがすごい変態的になるというシロモノ。

もうちょっと工夫できなかったんだろうか?

一応入れてはあるものの、使う可能性は低いかなぁ。
ただ、JEDIの提供しているJEDI VCLってコンポーネントは驚くほどよくできていて、ちょっとしたツールを作るときにはものすごく役に立ちそう。


今日の朝食はモス。
そう決めたケチャップが、午前5時前ぐらいにお送りしました。

8.24.2008

Delphi2009とC++Builder2009

CodeGearからのメールより引用。

Delphi 2009 and C++Builder 2009 product announcement and two weeks of Live Webinars
start on Monday, August 25 at 5am Pacific Daylight Time (UTC-7)


ということで、Delphi2009とC++Builder2009が登場する模様。
MicrosoftがC#やらVBやらに注力して以来、経営のまずさもあって死んだといわれている両開発環境だけれども、当時Delphi7を数万円のバイト代をはたいて購入した俺にとっては、Delphiというのは絶対に捨てられない環境なのです。

今思えば、オブジェクト指向開発も、コンポーネント指向開発も、プログラムにかける情熱も、すべてにおいてレベルアップさせてくれたのはDelphi7だった。
モチロン、未だにお世話になってます。
まだあの価格を取り返せたとは思っていないのでね(笑)

詳しくはアナウンスやらスピーチやらで語られるのかもしれないけれど、.NETFramework3.5には対応するんだろうか?
……まぁ、次に使うとしても、Delphiを購入することはせず、フリー版で使うんだろうけど(笑)



そうそう、これからC言語を学習しようと思っている人で、ボーランドのC++コンパイラ(いわゆるBCC)を使おうと思っている人がいるならば、C++Builderを利用するといいです。
理由は簡単。
コマンドライン版のみのコンパイラは5.5だかで止まっているけど、C++Builder付属のものは最新バージョンのものだから。
パスさえ通せばコマンドラインからもbcc32コマンドで利用できるし、Windowsアプリケーションが書きたいと思えば、面倒なWindowsAPIを叩かなくても、お手軽にRADプログラミングが楽しめますよ。

8.23.2008

あなたは何言語プログラマ?

プログラミング業界って、たとえば
・Cプログラマ=C以外の言語は使えない人
・Javaプログラマ=Java以外の言語は使えない人
・VBプログラマ=(以下略

という認識が一般的なものなのだろうか?

私はC言語できますってことで多方面に自己紹介しているんだけれども、昨日あった人も、そんな自己紹介に上記の認識をあてはめて私に話しかけてきた。
「C#という、マイクロソフトさんが開発した言語がありましてですね……。」
とか。

いや知ってるでしょ。それくらい……。

ざっくりシステムの概要を話してくれればいいものの、.NETFrameworkを導入するとはどういうことかとか、.NETFrameworkの導入でプログラムが安全になりますとか、そんな話をしてくれた。

あんまりにも時間を食うんで、「アンセーフなコードをそちらさんが書かないという保証はありますか?」って聞いたら、「は?」って顔された。
だから、あんまり時間とられるの嫌なんだよねーって顔してみたら、横にいた上司がこちらがわかっていることを察したらしく、さくさくとシステムの概要だけ説明してくれた。

終わってから聞いたら、どうやらこの4月に入ってきた営業さんらしい。
理系出身者って、語りたがるからいけませんよねぇ。申し訳ないとか言われちゃった。


俺も理系なんだけど(笑)

8.16.2008

15パズルをいじくる毎日。

だんだんとSDLの扱いにも慣れ。

……Bloggerのマイレポート画面が変わってら。

あ、DistroFreakが雑誌に掲載された件がいつまでも上にあってうざったかったので、下のほうに沈ませましたw

さて、タイトル通り15パズルをいじくってみたという話。
昨日公開したアーカイブですが、一部環境で動かない現象が確認された(っていうか、zlibのdll同梱し忘れた)ので、差し替えておきました。

それから、少しいじくったバージョンがこちら

・どのくらいいじくったかっていうと、画面がおっきくなりました。
・ヘッダーと実装を分離してみました
・お手本画像が表示されるようになりました
・スクリーンサーフェスの取得方法とかを変更しました
・将来の拡張に備えて、関数の設定を変更しました

ってところだろうか。
相変わらず大域変数使いまくりの非オブジェクト指向なコードに変わりないけどw

ソース…じゃなかった、ケチャップがほしい方はこちらから。
コンパイル時にはmysdl.aを付け足すのを忘れずに。

8.14.2008

15パズルできあがり

今回リライトした一件で、私は(もしかしなくても)C++がダメな人間なんじゃないだろうかと思え始めた。

というか、オブジェクト指向な書き方をしない方が楽しい。
(いや、正確には、RubyやC#のように、完全にオブジェクト指向で書けるなら、それはそれで楽しいんだけど)

結局、パネルをオブジェクトとして扱っていたこれまでと違い、数値だけを配列に管理させるようにした。
(そうしたら、劇的に速度も向上した)

判定関数やシャッフル関数の実装も単純になったし。
何でもかんでもオブジェクト指向すりゃいいってもんじゃないな。
オブジェクトの設計考えてるときは楽しいんだけどね。

で、せっかくブログで作ってます日記を書いてたから、報告までに出来上がり品をアップ。

■ ランタイムも含まれているバージョンはこちらのリンクから(268KB)

■ ランタイムなんてなくていいぜ!って猛者はこちらのリンクから。(8KB)

■ あと、クソ汚くてもいいからソースよこせって人は帰ってください。
  ソースじゃなくてケチャップがほしいって人はこちらから入手できます。
  ただ、このケチャップもおいしくないです。
(4.57KB)

特にケチャップは、ヘッダーに関数の実装まで書いてるとか、大域変数使いまくりとか、「あー。あんまり考えたくなくて、好き放題やったんだなぁ。」というのがバレバレな内容。
お恥ずかしい限り。

ちなみに、必要ランタイムはSDLのランタイムなのであしからず。
(ドトネトフレームワークくれなんてことは言いませんのでご安心を。)

書き方としては良くないんだろうけど、楽しいからいいじゃん。

そんな趣味グラマのつぶやき。

15パズルをリライトしながら、自分のスキルの低さに嫌気がさしつつ、オブジェクト志向なぞガン無視のプログラムを書き続けている今日この頃。

そんなことを思ったのでした。


# そうそう、ブログタイトルとハンドルを変えました。
# 以後はKetchupとして心機一転、精進して参りますぞ。
# Vectorとかの登録変更は、また後日にでも。

8.13.2008

Distro Freakが雑誌に紹介されました。

そんなわけで、Distro Freakがアスキー・メディアワークス発行の「週刊アスキー別冊 カンタンUbuntu2」に紹介されました。



紹介ページの解説によると、ディストリビューションの紹介数450+だそうで。
そうか。そんなに紹介してたか…。

さて、当然気になる雑誌の内容ですが、基本的には以前に発行された「カンタン Ubuntu」の続きです。
以前に発行されたものがUbuntuのインストールに重点を置いていたのに対して、今回のはいかにしてUbuntuをデスクトップLinuxとして使うかという点に重点が置かれています。

大きく、
(1)ウルトラモバイルPC(UMPC)上で実際にUbuntuを使ってみるというレビュー記事
(2)各種アプリケーションの使い方(GIMPなど)
(3)プリンターなどの周辺機器の動かし方
(4)コマンドラインの使い方やほかのUbuntu系ディストリビューションの紹介
(5)Ubuntu使いへのインタビュー
(6)仕事で使うためのTips
(7)Ubuntuでサーバー構築
(8)トラブルへの対処
といった構成になっています。

記事の内容は比較的わかりやすいものの、周辺機器の使い方ではハードまで特定しての解説がなされたり、特定メーカーのみの紹介など、「つまずかないように」が配慮されすぎて、逆に実用上不便かな?と思う点も目立ったり。
まぁ、入門者向けだし、つまずかない解説としては、これがベストなんでしょうけど。

インタビュー記事はなかなか面白かったなぁ。
Linux使いって、自分の環境について語りだすと宗教論争になる可能性があるから、普段あんまり語りたがらないし。

きっと、良かった点はほかのブログさんがたくさん書くと思うので、DistroFreak的に気になった点をあとふたつだけ(笑)

・SUSEがRed Hat系ディストリビューションの代表として掲載されている
これは、Distro Freakとしては指摘せねばなるまい重要な間違いです。
Linuxの系図をみていただければわかるとおり、SUSEはRPMを採用しているものの、Slackware系ディストリビューションだからです。

・無料を前面に押し出しすぎ
重要なのは自由であって、無料はそれがもたらす副産物でしかないのです。
あんまりにもしつこく無料を前に押し出しすぎてて、重要な「自由である」ことがおろそかにされていると思うなぁ。

と、実に「そんなとここだわるの!?」という気になった点でしたが、気になったものはしょうがないでしょ。

とまぁ、そんな内容ですが、UbuntuでLinuxはじめたい人は買って損のない内容だと思うので、書店などで見かけたらよろしくお願いします。

わたしの.emacs

暑さにバテながらいろいろ考えてみたところ、私にとって最も重要なファイルがこれであろうという結論に達した。

さて、そんな悟りはおいとき、実は以前からemacs22にして以来(というかLennyにして以来)、Shellモードで日本語がうまく表示されないという不具合に悩まされていた。

今回も、以前にサポートブログで紹介したようなやり方でemacs環境をUTF-8に整え、環境変数$LANGもja_JP.UTF-8にしてあるから、当然の如くshellモードでも日本語が表示されるんだと思っていた。

けれど、実際使ってみるとそうではなく、ここしばらく、特にSDLを使ったプログラムをコンパイルするときに、頻繁にShellモードを呼び出さなくちゃいけなくなってから、この問題をなんとか解決できないものかと悩んでいたのだ。

で、今日一応の解決を見たのでその結果とともに.emacsを張り付けておこうと思う。

まずは.emacsから。

;;.emacs
(setq inhibit-startup-message t)

(set-locale-environment nil)
(coding-system-put 'utf-8 'category 'utf-8)
(set-language-info
"Japanese"
'coding-priority (cons 'utf-8
(get-language-info "Japanese" 'coding-priority)))
(set-language-environment "Japanese")
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(set-buffer-file-coding-system 'utf-8)
(setq default-buffer-file-coding-system 'utf-8)
(global-font-lock-mode t)
(setq backup-inhibited t)
(setq delete-auto-save-file t)

;; scheme-mode
(autoload 'scheme-mode "scheme-mode" "scheme" t)
(setq auto-mode-alist (cons '("\.ss$" . scheme-mode) auto-mode-alist))

;; html-helper-mode
(autoload 'html-helper-mode "html-helper-mode" "Yay HTML" t)
(setq auto-mode-alist (cons '("\.html$" . html-helper-mode) auto-mode-alist))

;; css-mode
(autoload 'css-mode "css-mode" "Editing CSS" t)
(setq auto-mode-alist (cons '("\.css$" . css-mode) auto-mode-alist))

;; region
(setq transient-mark-mode t)

;; show clock
(display-time)

;; show column number
(column-number-mode t)

;; anthy
(push "/usr/local/share/emacs/site-lisp/anthy/" load-path)
(load-library "leim-list")
(load-library "anthy")

;; uim
(push "/usr/local/share/emacs/site-lisp/uim-el/" load-path)
(require 'uim-leim)
(setq default-input-method "japanese-anthy-uim")
(setq uim-default-im-prop '("action_anthy_hiragana"))
(setq uim-candidate-display-inline t)

(show-paren-mode t)
(setq show-paren-style 'mixed)

;; scheme
(setq process-coding-system-alist
(cons '("gosh" utf-8 . utf-8) process-coding-system-alist))

;; gosh interpriter path. -i option is interactive mode
(setq gosh-program-name "/usr/bin/gosh -i")

;; scheme-mode and run-scheme-mode use to cmuscheme.el
(autoload 'scheme-mode "cmuscheme" "Major mode for Scheme." t)
(autoload 'run-scheme "cmuscheme" "Run an inferior Scheme process." t)

;; pair of brace
(show-paren-mode)

;; indent
(put 'and-let* 'scheme-indent-function 1)
(put 'begin0 'scheme-indent-function 0)
(put 'call-with-client-socket 'scheme-indent-function 1)
(put 'call-with-input-conversion 'scheme-indent-function 1)
(put 'call-with-input-file 'scheme-indent-function 1)
(put 'call-with-input-process 'scheme-indent-function 1)
(put 'call-with-input-string 'scheme-indent-function 1)
(put 'call-with-iterator 'scheme-indent-function 1)
(put 'call-with-output-conversion 'scheme-indent-function 1)
(put 'call-with-output-file 'scheme-indent-function 1)
(put 'call-with-output-string 'scheme-indent-function 0)
(put 'call-with-temporary-file 'scheme-indent-function 1)
(put 'call-with-values 'scheme-indent-function 1)
(put 'dolist 'scheme-indent-function 1)
(put 'dotimes 'scheme-indent-function 1)
(put 'if-match 'scheme-indent-function 2)
(put 'let*-values 'scheme-indent-function 1)
(put 'let-args 'scheme-indent-function 2)
(put 'let-keywords* 'scheme-indent-function 2)
(put 'let-match 'scheme-indent-function 2)
(put 'let-optionals* 'scheme-indent-function 2)
(put 'let-syntax 'scheme-indent-function 1)
(put 'let-values 'scheme-indent-function 1)
(put 'let/cc 'scheme-indent-function 1)
(put 'let1 'scheme-indent-function 2)
(put 'letrec-syntax 'scheme-indent-function 1)
(put 'make 'scheme-indent-function 1)
(put 'multiple-value-bind 'scheme-indent-function 2)
(put 'match 'scheme-indent-function 1)
(put 'parameterize 'scheme-indent-function 1)
(put 'parse-options 'scheme-indent-function 1)
(put 'receive 'scheme-indent-function 2)
(put 'rxmatch-case 'scheme-indent-function 1)
(put 'rxmatch-cond 'scheme-indent-function 0)
(put 'rxmatch-if 'scheme-indent-function 2)
(put 'rxmatch-let 'scheme-indent-function 2)
(put 'syntax-rules 'scheme-indent-function 1)
(put 'unless 'scheme-indent-function 1)
(put 'until 'scheme-indent-function 1)
(put 'when 'scheme-indent-function 1)
(put 'while 'scheme-indent-function 1)
(put 'with-builder 'scheme-indent-function 1)
(put 'with-error-handler 'scheme-indent-function 0)
(put 'with-error-to-port 'scheme-indent-function 1)
(put 'with-input-conversion 'scheme-indent-function 1)
(put 'with-input-from-port 'scheme-indent-function 1)
(put 'with-input-from-process 'scheme-indent-function 1)
(put 'with-input-from-string 'scheme-indent-function 1)
(put 'with-iterator 'scheme-indent-function 1)
(put 'with-module 'scheme-indent-function 1)
(put 'with-output-conversion 'scheme-indent-function 1)
(put 'with-output-to-port 'scheme-indent-function 1)
(put 'with-output-to-process 'scheme-indent-function 1)
(put 'with-output-to-string 'scheme-indent-function 1)
(put 'with-port-locking 'scheme-indent-function 1)
(put 'with-string-io 'scheme-indent-function 1)
(put 'with-time-counter 'scheme-indent-function 1)
(put 'with-signal-handlers 'scheme-indent-function 1)
(put 'with-locking-mutex 'scheme-indent-function 1)
(put 'guard 'scheme-indent-function 1)

;; memo
(setq user-full-name "My Name")
(setq user-mail-address "email@post.com")
(defun memo ()
(interactive)
(add-change-log-entry
nil
(expand-file-name "~/.memo/memo.txt")))
(define-key ctl-x-map "M" 'memo)

;; password hide
(add-hook 'comint-output-filter-functions
'comint-watch-for-password-prompt)

;; c-mode hook
(add-hook 'c-mode-hook
'(lambda ()
(c-set-style "BSD")))

(add-hook 'c++-mode-hook
'(lambda ()
(c-set-style "BSD")))

;; ls color mode off
(add-hook 'shell-mode-hook 'ansi-color-for-comint-mode-on)

;; w3m
(require 'w3m-load)

;; wget-el
(load "w3m-wget")


ポイントは、太字で示したところと斜体で示したところ。
どうやら、太字部分斜体部分よりも前に定義されていないと、正常にエンコしてくれない様子。
(いろいろと順序を変えて試行錯誤しながらやった結果なので、外しているかもしれないけど。)

もし同様の症状でお困りなら、試してみるといいかもですよ。

8.12.2008

15パズルをリライト

やる気が出ないから、SDLのチュートリアルをなぞったりしながら、せめてSDLになれるくらいのことはしようと思って、結局15パズルをリライトすることにした。

まぁ、リライトしたからといってよくなるとは思えないんだけど、シャッフルについてもある程度いいアイディアが浮かんだし、判定関数も何とかなりそうな予感がしてるから、いっそリライトと。

本当は、SDLになれる以外にも、C++と仲良くなろうなんて目的もあったりするんだけどね。

# SDLDotNetなる面白そうなアイテムを発見した。
# こちらはある程度理解でき次第、まとめようかなぁ。。。
# ここで手を出したらアウトな気もする。
# C#の便利さに慣れたら、C++には戻ってこられないよNE☆

8.11.2008

夏バテというやつか。
いまいちやる気が出ない。

一日中ごろごろしてる日が、ここ2~3日続いてる。
まぁ、世の中は今週お盆休みみたいだし、休むのもいーよねー。

ごろごろ。

8.08.2008

MinGWで自作プログラムにアイコンを付与する方法

15パズルなんですが、うまいぐあいの判定関数&パズル生成関数が思い浮かばなくて、結局ちょこちょこと内部をリファクタリングしただけで、ニコニコを見てしまうという悪循環に(以下略

さて、そんな中で、MinGWでプログラムにアイコンを設定できないものかと思い立ち、ちょろっと探してやってみました。
(すでにダウンロードできる15パズルのファイルは差し替わっています)

ちなみに、(SDLとあわせているせいかもしれませんが)ウィンドウ左上のミニアイコンにはリソースからの設定ができていません。
たぶん、ゲームプログラムならフルスクリーンだったり、左上アイコンにはこだわらないだろうから問題ないんでしょうけど。

一番簡単なのは、
101 ICON "iconfilename.ico"
なんてのを適当なテキストエディタで作成して、resource.rcか何かのファイル名で保存しておきます。

次に、windres(今回私が相手にしているクロスコンパイル環境においては、i586~という長い名前だったので、適当にlnしておきましたよ。)を使って、
$ windres -o resource.o resource.rc
とすると、resource.oというオブジェクトファイルが生成できます。

あとはこれをコンパイル時に渡してあげればOK。
具体的には
$ mingw-cc filename.c resource.o
でいけるはず。
私はリソースIDを101にしたんだけれども、(リソースファイル内にほかのアイコンが無いせいかもしれないが)勝手にデフォルトアイコンとして付与されたから、よっぽど変なことしてない限り、これでいけるんじゃなかろうかと。

よし。今度こそ続きは帰ってきてからやろう。

# 何かいい判定関数/生成関数のアイディアをお持ちでしたら、教えてください。


以下、参考サイト(順不同)
http://www.sixnine.net/cygwin/translation/cygwin-ug-net/windres.html
http://www.m-oz.com/soft/mingw.html
http://www.arcpit.co.jp/winapi/api_01/ap010312.htm

気になると眠れない性格。

明日やると言いながら、気になって眠れなかったからつい手を出したらこんな時間に。

何が気になていたかというと、「パネルの入れ替え処理が動くように処理を書いたはずなのに、パネルの入れ替え処理が動かなかったこと」だ。

結論から言うと、クリップされる領域を勘違いしていたために、頭の中のイメージと実際の動作が一致しなかったという話。
紛らわしい書き方した自分が悪いんだけどさ。

そのほか、領域外参照やらマウスがクリックされた位置をゲーム内で使われている座標に変換する処理、升目に格納されている数値にまつわる処理でバグがあって、それをつぶしてたらこの時間(笑)

もう寝られないから、もうしばらくやろう。

ただ、まだ原因不明のバグがあって、それが-Os最適化をかけると、あるていどプレイした段階でSEGVで落ちるというもの。
なんか、普通のプレイにも影響でそうでいやだなぁと思いつつ、-Os最適化を外すと我が家では(今のところ)再現していないバグなので、とりあえず無視しようと思う。


現在の進捗は一人遊び(自分で入れ替えて、自分で解く)ができる程度。
パズルが解けたかどうかの判定や自動シャッフルは実装していない。
(あ、あと音も鳴りませんよw)

それでも遊んでみたい方はこちらからどうぞ。

先に言っておきますけど、バグがある可能性大です。
プレイできない可能性も大です。
自己責任でってやつです。

ちなみに、画像等々合わせて、製作時間にして5時間ちょっと。

うーん。SDLに慣れてないとか、アルゴリズムの基礎がなってないとか、勘が悪いとか、いろいろ原因はありそうだけど、もう少しがんばれないか>自分。

自分で作ってみると、よく理解していないところが浮き彫りになる。

そんなわけで、ちょっと寄り道して、しばらく15パズルを実装してみようと思う。
GDB以外のデバッガが無い中、いろいろなバグ(おもにSEGV)に悩まされつつも、どうにかここまで出来た。

コマの移動処理も書いたつもりだけど、うまく動いてくれない。
出来上がったかどうかも、シャッフルの処理も未実装。

…なんだ、普通に絵が出ただけじゃないか。

特に表示周りをよく理解していないことがよくわかった。
(というか、そこを除いたrSDLって何にも残らないから、要するに何にも理解してないってことなんだろう。)

今日は眠いし、残りは明日やろう。

8.07.2008

SDL:ウィンドウイベントに挑戦。

typo報告のメールは理解してもらえたようだ。
直しといたよという返信があった。こちらも安心したよ!

そんなわけでLesson25…と行きたいわけなんだけど、いかんせんウチにはジョイスティックやジョイパッドの類がない。
だから、Lesson25をとばしてLesson26、ウィンドウイベントをやることにした。
ジョイパッドは、必要になったら戻ってやろう。

# きっと、アクションゲームやシューティングゲーム(あるいは3Dを扱うようなゲーム)だったら必須なんだろうなと思った。

さて、ウィンドウイベントの実装だけど、実装したのは
・ウィンドウのリサイズに対応したイベント
・ウィンドウからマウスのフォーカスが外れたときのイベント
・ウィンドウからキーボードのフォーカスが外れたときのイベント
・ウィンドウのフルスクリーンモードとウィンドウモードの切り替え
ってとこ。

案外対応しているイベントが多くてびっくりした。
ウィンドウからフォーカスが外れたらゲームを一時停止してあげるとかいう処理を書くと親切かもしれない。
特にテトリスみたいな落ちものゲームやアクションゲームだとなおさらだね。

そろそろ何かゲームが書けそうな予感。
でも、ゲーム書くにはゲームに則したアルゴリズムを学ばなければいけないという罠。

# でも安心し給え俺。
# 遊びのレシピというハウツー本があるじゃないか。

画像はフルスクリーンにした状態。
わかりづらいわー…。と思った人は、自分で組んでみよう。

8.05.2008

SDL:ゲームデータのセーブ

Lesson24.
レッスン名的に、普通のファイルI/Oじゃなかろうかと思ったら、まさしくそうだった(笑)

それも、至極単純なファイル入出力。

# いつだか某掲示板で
# 3Dバリバリのすごいゲーム作ってるのに
# ハイスコアの記録方法がわかりません
# って質問していた人が居たのをふと思いだした。

まぁ、C++のファイルストリームに触れられたから良しとしよう。
それにしても、便利だなファイルストリーム。
Cのファイル操作とは大違いだ。

で、いったんコンパイルしたものの、なぞのセグメンテーションフォールトに悩まされた。
GDBで追ってみたものの、SEGVで落ちてるのはSDL_main関数だとか言われる始末。

悩んだ末、もう一回コンパイルかけてみたら普通に動いた。
何が原因だったんだろう?


黒点じゃつまらないから、スマイリーさんを導入。
キーボードも1~4までしか使ってないから、5に黒を割り当てるとかすれば、もうちょっとバリエーションが増やせるかも。

画像が見づらいのはご愛敬。




# あと、typoを見つけたので報告しておいた。
# あのブロークンな英語で伝わるんだろうか…。
# 失礼になっていないだろうか…ヽ(д`ヽ)。。オロオロ。。(ノ´д)ノ

8.04.2008

SDL:名前を入力させる

Lesson23。
残すところ、あと13項目。
この調子だと、一週間かからずにクリアできそう。

たぶん現状の知識でも、簡単なシューティングゲームぐらいは作れると思う。
まだまとまった時間がとれるわけじゃないからやらないけど。

今回はテキスト入力。
ただし、アルファベット+数字のみ。記号やら日本語やらは入力できませんよ。念のため。

もし日本語入力したいなら、SDL_inputmethodってライブラリを当たると良さげ。
(後継のSDL_textmanagerってやつが開発中なのかな?)
たぶん、ネットゲームとかのチャット機能には必須のライブラリになると思う。

さて、そんな入力機能を実装したわけだけれども、案外簡単で拍子ぬけ&自分がC++のライブラリをよく知らないことを改めて痛感。

画像は入力途中と入力後。
フォントは例によってみかちゃんを使用。
いい味出してるよね。みかちゃんフォント。

SDL:背景のスクロール

Lesson22.
キャラクターはそのまま、全く動かず、背景だけがスクロールしていくというプログラム。
そんなわけで、記述するべきコードの量もぐっと少なくなった。

コードの量が少なくなったので、なんか変わったことしようと思ったんだけど、コードを改変するとLessonに沿わなくなるので、コードの編集はやめて、グラフィックを変えることにした。

そんなわけで我が家の犬山係長補佐代理に登場していただいたわけだけれども、その場でアニメーションさせてもよかったかもしれないと、作ってみてから思った。
まぁ、スクリーンショットじゃアニメーションしてようがしてまいが、わからないんだけどね(笑)

SDL:スクロール

某人間のアニメーションでだいぶ手を抜いたので、今回はスマイル君をきちんと描きましたよ。
もちろん、背景も。

今回のプログラムに限っては、当たり判定じゃなくてスクロールがメインだから、スマイル君のように円形である必要もなく、たとえば(こないだから何度か口頭だけ登場している)星型のアイコンを描いてもいいんだろうなぁ。

DOT_WIDTH, DOT_HEIGHT定数をいじれば、もう少し大きめのキャラクターにも対応できそう。
ただ、スクロールが思った以上に広い範囲で行われるのが難点か。

このあたりは改良の余地がありそうな予感。

# どうでもいいけど、Bloggerの途中保存機能がヒドイ。
# これは、Operaとの相性が悪いのか?それともIME 2007との相性が悪いのか?はたまた別のものか?
# うざったいから切ると、今度はスタブで投稿に失敗したときに困るんだよね;;どうしたものか…。

祝・投稿数200件突破。

って、祝うべきなのか否か…。

まぁいいや。


久しぶりにLennyさんでapt-get update && apt-get upgradeしてみたら、驚くほど大量のアップデートが来てて目が点になってしまった。

よく考えてみれば、Lennyってまだtestingなんだよね(笑)

そういうところをまったく考えないで使っているあたり、ダメなんだろうなぁ。。。
これでもし、sidとかに移行したら、私は浦島太郎状態になること間違いなしだな。

cronにアップデートをスケジューリングするのも面倒だし…。

今度からはこまめにするようにしようと、100MB超えのファイル群を見ながら思うのでした。

# アップデートが終わらないことには、安心してSDLの続きができないじゃない!

SDL:アニメーション

英字配列なんて、三日もあればなれると思ってたら、本当に慣れてしまった(笑)
まだ記号系のキーに若干の不安があるけれども、これもそのうち解消されるでしょう。


そんなわけで、SDLのLesson20.
アニメーション男ことFOO氏の画像を用意しようかと思ったんだけれども、サンプルについてきた画像が予想以上になめらか~に動くことと、アニメーションのような連続コマの画像を作るのはめんどいんで、サンプルをそのまま利用することに。

タイマー使ってアニメーションさせれば、たとえばストリートファイターのように待機中にぜぇぜぇした雰囲気のアニメをするとか、ぷよぷよみたく、落ちてくる途中にぷよ~んとした雰囲気のゲームを作るとかできそう。

ってか、最近ゲームの話ばっかりだ。
これほどカッチリ私の性分にハマるライブラリっていうのは、VCL以来なもんで。

8.03.2008

SDL:円形を用いた当たり判定。

Lesson19.
円形を用いた当たり判定のプログラム。
ただし、注意しなければならイのは、楕円でなくて円形での当たり判定だということ。
つまり、きちんとした円出ない限り、判定はできない。

こういうたぐいの当たり判定を使うのって、たとえばブロック崩しゲームのブロック対ボールという、矩形で当たり判定すると苦情が来そうな所に使うとよさそうだよね。
ただ、Lessonでサンプルコードがあるとはいえ、組んでて非常に面倒だった。

ここまで3種類の当たり判定について勉強してきたわけだけども、一番簡単なのはやっぱり矩形での当たり判定だね。(世の中には色による当たり判定なんてのもあるらしいけど)
シューティングゲームの弾なら、十分小さいから、円形の当たり判定をしなくても、矩形で近似できるのかもしれない。

まぁ、ゲーム作るなら、当たり判定はどんな場合も必須だから、一つくらいはきちんと身につけておこう。
(考え方自体はどれも単純だけど、組むのが面倒だからライブラリ化しとくといいかもしれない。)

SDL:ピクセル単位の当たり判定

Lesson18.
ようやく半分。

今回はピクセル単位の当たり判定だけど、こんなに厳密な当たり判定を使う機会ってあるんだろうか?
基本的には矩形単位の当たり判定を応用したようなもので、前回のものが理解できれば、内容的に難しいところはない。

ソース中ではstd::vectorを使って、当たり判定用のマップを作っていたけれど、もしこれが人物ぐらい複雑な形状になったら、いちいち組んでられないと思う。

となると、人物画像の抜き(当たり判定用)画像から、自動的に当たり判定用マップを生成するようなコードを書く必要があるだろうな。

おそらく私は、この後に登場する円形での当たり判定と、前回やった矩形での当たり判定しか利用しないから、ここを詳しく突こうって気にはなれないけど。

あと、個人的には円形じゃなくて星型とか、多少複雑な形状でピクセル単位の当たり判定をデモしてほしかったなぁ。

Visual C#を放り込む。

キーボードとともに押し入れから出てきたウィザードリィをプレイしようとインストールしたら、インストールそのものは成功するものの、どうにもゲームのプレイまで行きつかない。具体的には、#4か#5かを選択する画面で、どちらを選んでもエラーをはいて終了してしまうのだ。

こうなったらしょうがない。
早くSDLを覚えて、そのうちウィザードリィ風ゲームを作らなくちゃいけないだろう。

そんなわけで、いつものとおりcoLinux managerからcoLinuxを立ち上げるわけだけれども、やっぱり右クリックへの反応がいまいち…というか、右クリックメニューが出てこないことが多々ある。

そんなわけで、多少改造できないものかとソースをダウンロード。
誰もやってくれないので自分で改造してみることにした。

が、いろいろとファイル構造が複雑。
うーん。。。こんなのいじってられないなぁ。。。
ドキュメントもないし。。。

ということで、リビルドだけ通してみることに。
対象の.NET Frameworkを1.0→3.5にあげてリビルドしてみた。

いまのところ、右クリックへの反応がいまいちだった症状は改善されているように見える。
今後、どうしても困ることがあったら、より深くソースを見ていこう。

バルーンヒントのON/OFFぐらい調節できるようにしたいしな。

矩形同士の当たり判定

ゲームには欠かせないね。
コリジョン判定ってやつ。
まだ矩形同士だけどw

そういえば、今は昔、SFC版ドンキーコングが神ゲームと称えられていた頃、ドンキーたちの当たり判定は、サルよりやや内側に切られた矩形での当たり判定だったなんて話を聞いたことがあるなぁ。(ソースはない。だから、記憶違いかもしれない。)

なるほど、あれだけアクション豊かなサルたちの当たり判定をどうやってるのか気になったけど、それなら解決できるのかと思った記憶が…。

そろそろテーブルゲームぐらいなら作れそうな予感。

さて、その話とは別に、キーボードが変わったわけだけど、さすがに1年以上触ってないと、US配列に戸惑うね。

アンダーバーとか、プラスとかマイナスとかコロンとかイコールとか、特に記号の入力で凡ミス連発。
特に多いのがカッコ。
微妙に位置がずれてるだけあって、意識しないで入力してしまうことが多々ある。
でもまぁ、この調子で毎日SDL使ったコードを書いてれば、すぐなれると思う。

それ以上に、Fキーが普通に利くことと、これまで利きの悪かったCtrlキー(正確にはCapsLockキー。日本語配列でも、こればっかりは入れ替えて使っていた)が、普通に聞くのはうれしい。
さっとしたタッチでもうまーく入力してくれて、さすがHHKといったところか。
どうしても困ったら、日本語配列のHHKを買おうかと思うけれど、たぶんないなぁ。
きっとこのままUS配列に慣らしちゃうんだろうな。
ともなれば、次にPCを購入するときはデスクトップか、ノートでもUS配列が選べるようにしないと、モバイルに不便だな…。

キーボードを持ち歩かないのは、HHKの理念からは外れてしまうんだろうけど(笑)

8.02.2008

Fキー対策

やっぱりFキーが聞かないのは不便。
たとえばEmacsの移動でもCtrl+Fを多用するし、私の場合、メールアドレスもFが入ってる。

Fが打てないor打ちにくいというのは、わたしにとって致命的なわけだ。

そこで、以前使っていたものの、諸般の事情から押し入れで眠っていたHHKLite2を引っ張り出してきた。

配列こそUS配列になってしまうけれど、2,3日もすればなれるだろう。

言うまでもなく、ノートパソコン標準のものよりずっとキータッチがいいし、Fが打てることで作業も快適になりそう…。


# あ、Debianのキーマップを変更しなくちゃいけないのか。
その必要はなかった。
よく考えてみれば、Putty経由で利用してるんだから、当たり前っちゃ当たり前なんだよね;

周りは夏祭りに出かける中、涼しくコーディング。

SDL, Lesson16.

今回は画像を動かすという話。
キーボードの上下左右キーに対応して、画面内の丸が画面を動き回るというもの。

きちんとDotクラスを設計して処理してるから、たとえばニュートンの運動方程式(ma=F)に従って、落下運動をするボールのシミュレーションとかなら、すぐに書けそう。

背景はFillで白い矩形に塗りつぶしているけれども、別の画像に差し替えてもよさそう。
(カラーキーの項目でやったのを応用すればいい。)

あと、いい加減Fキーの利きにウンザリしてきた。。。。
どうにかならないものか??

DirectX SDK を入れ替えてみる。

私にとって影響のありそうな変更はなかったものの、なんとなく気になったので入れてみる。
また400MB強をダウンロードしてしまった…。
おかげでWiiのバーチャルコンソールで落としたゼルダがだいぶ進んだ。

落としたら、前回同様Windowsにインストール→Linuxにコピー→Windows側のSDKを削除。
コンパイル&リンクも問題なし。
前回と同じ内容のプログラムだが、stripしたら9KBというコンパクトサイズで実現できた。
(いや、DLLが下請けしてくれてるからってことなんだけど)

最近気になってるのが、coLinuxManagerの安定性。
0.7.0以降更新されていないみたいなんだけど、タスクトレイに常駐するのはいいものの、たまに右クリックメニューが出てこないことがある。

バルーンヒントのON/OFFも調整したいし、いじってみるかと思ってダウンロードしたら、ソースがC#だった。
…開発環境入れるのが面倒だから、とりあえず我慢しよう。

あと気になってるのが、キーボードのFキー。
たまに利かないことがある。

4年目で色々ガタが来てるし、そろそろ修理なり買換えなり考えないといけないんだけれども、そんなお金はないんだよなぁ…。


よし、そのうち考えよう。

ムペンバ効果騒動、ここまでのまとめ。

スラッシュドットで話題になっていたので、ちょっと取り上げてみる。
(われらがボルツマンの敗北か!?と一瞬気になったのでw)

はじめに、ここまでのムペンバ効果に関する流れを整理しておくと

1.NHKのためしてガッテンにて、ムペンバ効果なる効果が取り上げられる。
2.大槻名誉教授のもとに、あれって本当なの?というメールが届く。
3.熱力学的にありえないだろwwwと、大槻教授がブログで批判。
4.他ブログやニュースサイトでも取り上げられる。
5.NHKは何度か実験しましたと主張。ブログ読者からも、実験しないで批判とは何事かと、大槻教授が批判される。
6.大槻教授も実験。すると、NHKの主張とは違った結果がでた。
7.ためしてガッテンを監修した北大教授が、複数の条件下ではあり得ると反論。
8.日本雪氷学会が本格議論へ。

といったこところ。
私が考える、今回の一連の騒動でまずかったと思えるところは

・NHKは、まるでお湯のほうが(どんな場合にも)早く結氷するように報じてしまった。(条件を整えるとなるとか、確率的な現象であるという説明があったが、それはほんのオマケのようなものだった)
・科学の世界では謎というような、昨今の脱科学、似非科学、オカルト科学な風潮を煽る(具体的にいえば、大槻教授がかみつきやすい)報道をしてしまった。
・NHKが何度も実験したとする実験も、いくつか疑問点が残る実験だった。
・大槻教授は、ためしてガッテンを確認せずに実験/批判を行った。

といったところ。
一部ブログでは、本筋と離れたところから大槻教授の主張を批判したり、本筋とは全く関係ないところに突っ込みを入れてるようなブログもある様子。
#(お祭り好きの集まりみたいな状態になってるという印象。
きちんと議論するつもりは無いんだろうね。こういう人たちは。)

ひとつひとつ、問題点を紐解いていこうと思う。

まず、NHKがお湯のほうがどんな場合にも結氷するかのように報道したことについてだが、最近のテレビの流れだと、これは仕方なかったと思う。
でも、視聴者にそういう誤解を与えたならば、報道局として謝っておくのがいいんじゃないだろうか?

次に、似非科学風味な報道をしたということについてだが、これも昨今の報道スタイルとしては当たり前な気がする。(いつだかの、でんじろう先生を使った歯磨き粉のCMに関して書いたときと同じ気持ち。)

3番目に、NHKが何度も実験したとする実験についてだが、疑問点については後に挙げる参考サイトが詳しいので、そちらを参照してもらいたい。

最後に、大槻教授の行った実験のまずかった点だが

・70℃と17℃という、実験の前提条件から大きく外れた水で実験を行った
(Wikipediaによれば、この効果を確認するには、35℃と5℃の水で実験するのが望ましいとされる)
・東京都水道局のページに掲載されている、対流が結氷に影響を与えるような、深い製氷器を利用しなかった
・深い製氷装置としてペットボトルを選択してしまった。
(ムペンバ効果の(再)発見者とされるムペンバ君の報告では、熱のやり取りは水の界面を通じて行われるとのことだったので、口の小さいペットボトルでは、それほど良い成果が得られないと考えられる)
・実験条件を整えないまま実験して、批判してしまった

というところじゃないだろうか。

この問題について、私が言えることは、
お湯を作るにも、お湯を結氷させるにもエネルギーが必要で、そのエネルギーは、水を結氷させる場合より大きくなることは明らかであるから、エネルギー問題が叫ばれる昨今、ホイホイとやるのは良くないよねってこと。

いろいろ調べてたら、よくあるお祭り状態になっていて、結局どっちが正しくても、みんなかまわないんじゃないだろうかと思った。

だって、お湯を沸かし始める時間から結氷させれば、結局水を結氷させるのと同じぐらいの時間を使っちゃうんじゃないかなと思うし。

よくわからない結論になったけど、要するに大槻教授はもう少し問題をきちんと把握してから批判しましょうってことと、NHKは科学者に批判されないような報道を心がけましょうってこと。

お祭り騒動に疲れた方は、どうぞコメントにて身近な環境問題対策についてお話しください。

以下、参考サイト。
スラッシュドット・ジャパン
大槻教授のブログ
Wikipedia - ムペンバ効果
水のおもしろ実験「お湯のほうが先に凍る?」- 東京都水道局
Archives - ムペンバ効果調査中(1)
Archives - ムペンバ効果調査中(2)
Archives - ムペンバ効果調査中(3)
Archives - ムペンバ効果調査中(4)

8.01.2008

SDL + DirectX9 + Direct3D + MinGW + Debian/GNU Linux での、DirextX9アプリケーションのクロスコンパイル

フレームレートの計算ばっかりじゃ面白くないなぁと思っていたら、手が勝手に動いてました(笑)
8月一発目のネタがこれとはね。

そんなわけで、やたら長ったらしいタイトルの通り、ド変態クロスコンパイル環境に、さらに変態な環境を付け加えてみようという試み。

まず理解していただきたいのが、DirectXを利用することで、確かに最近の3DCGで話題な機能の恩恵を受けることができるものの、SDLを使う意味はほとんどないということ。
つまり、SDLの利点であるマルチプラットフォームとか、高い移植性とか、そういうのをガン無視できる人だけがやっていい裏ワザ的なものだということ。
(もしマルチプラットフォームを捨てたくないならば、素直にOpenGLを使うべきですよ)

それから、そんなにWindows環境に依存したアプリを書きたいというのなら、素直にクロスコンパイル環境じゃなくてVisual C++とかを使うべきだということ。

この辺を理解していないと、(理解していても)「???」が頭に残る展開になること請け合い。



まず、前準備としてDirectX 9 SDK(以下SDK)をダウンロードしておく。
執筆時点での最新版はMarch 2008。ライブラリファイルを覗くと、すでにd3d10.libとかが用意されてる。違った。よく調べてみると、June 2008が最新らしい。時間があったら差し替えようか…。でも、そんなに大きな変更はないみたいだしなぁ…。悩むなぁ…。)

ダウンロードしておいたSDKを展開して、インストールを開始する。
入れるのはヘッダーとライブラリのセットだけ。
x86版に限れば(SDKにはx64版も付属している)、ヘッダーとライブラリを合わせてzip圧縮かければ、せいぜい3MBちょっと。
それに対してSDK全体の容量は圧縮時で400MB強、展開時で1GB弱。

なぜMicrosoftは必要なものだけダウンロードしてくれる、JavaSDKタイプのインストーラーにしなかったんだろうと小一時間考えたら、インストールしたヘッダーとライブラリをいつもの場所にコピー。
ヘッダーはめんどうならベタでコピーしてもいいけど、私はDXってディレクトリを新たに切って、そこに放りこみましたよ。(ライブラリはベタで放り込んだ)

いつもどおりの事だけど、ライブラリの変換作業とかそんなのは必要なかった。
いつからMinGWはこんなに進化したんだろう?

それが出来たら、チュートリアルサイトを見ながらコードを組む。

あ、WindowsにインストールしたSDKはもう必要ないから、削除してかまわないですよ。

出来上がったらコンパイル。
ここでもコンパイルコマンドには気をつける必要があって、
mingw-c++ filename -lmingw32 -lSDLmain -lSDL -ld3d9 -ld3dx9 -mwindows
のように指定する必要がある。
※ 必ずSDL関連ファイルを先頭に指定するというのがミソ。

あとはできたものをWindowsにコピーして実行すればOK。
サンプルそのままだと、全画面表示になるので注意。

ソースをみてもらえば分かると思うけど、コードはほとんどが通常のをDirectXを使ったプログラミングで使われるものがそのまま使われている。
というのも、DirectX自体、渡されたウィンドウハンドルを持つウィンドウに描画を行うかららしい。

だから実は、SDLで作られていようが、WinAPI直叩きで作られていようが、DirectXさんにとっては何の関係もないものということだ。

それなら私は、ウィンドウ生成が楽チンなSDLを選ぶなぁ。実行時にDLLが必要って手間はあるけどさ。
そうそう、コンパイルしたバイナリを動かすには、最新のDirectXランタイムが必要だから、動かない場合はそちらをインストールするとよさげ。