第一種臨界不測日記

前回に引き続き、分散バージョン管理ソフトについてのお話です。

Mercurial という Python 製の分散バージョン管理ソフトもあります。
大きなプロジェクトでは Mozzila のバージョン管理に使われています。

■Mercurial雑感

こちらは、今のところ日本語文字コードの対応など
Windowsでも比較的安心して使えるようです。

何故、Mercurial = hg なのかっていうと、コマンド名が hg だからです。

TortoiseHgというエクスプローラー統合の GUI ツールもあります。
上記画像はTortoiseHgのものです。

ただし、付属のdiffツールが文字化けたりするので、
小物ツールを別途用意する必要があります。
また、「ファイル名の変更」などGUIでは足りないコマンドがあるので、
コマンドラインも使えるようになっておくことが必要です。

GUIの充実はまだこれからと言ったところですね。

とはいえ、コマンドラインでは十分使えるようですので、
今から触っておいて損はないと思います。

コマンドライン版の入門には、下記のページが参考になりました。
（まだ読んでいる途中）
『特集：Mercurialではじめる分散構成管理｜gihyo.jp … 技術評論社』

自分はコマンドラインは毛嫌いしていたのですが、
gitで使ってみたりして大丈夫になりました。

また、Tortoiseなんとか、みたいなGUIツールも結局は
コマンドライン版をラップしたような形なので、
憶えておくと GUIツールの方も機能対応がわかり、
非常に使いやすくなります。

Subversionとの相互運用ですが、現時点では hg convertという
変換機能はあるみたいですが、まだまだ微妙な動きのようです。
hg svnみたいな外部ツール(プラグインやスクリプト)もあるみたいですが、
まだどうも相互運用には厳しいようです。

これは相互運用は過去の資産をいかせるという意味からも
すごくよい機能なので、今後に期待したいです。
(この辺のことを重視している git はさすがという感じ)

Mercurialのことは、wikiに少しずつまとめています。

■Mercurialのリポジトリホスティング

gitに対するgithubのように、
Mercurialに対応したリポジトリホスティングもいくつかあるようです。

例えば、

• bitbucket.org
• Project Kenai
• Assembla

などがあります。

そういや、gitのリポジトリホスティングもgithub以外にけっこうでてきたみたいですね。

さて次回は、Bazaarと行きたいところですが、
まだMercurialを使いこなせてないので、
もう少し使ってみてからにします。

最後に、ぜひ、みなさんも
分散バージョン管理ソフトを使ってみては？と思います。
それでは！

■参考リンク

• Google Open Source Blog: Develop with Git on a Google Code Project
  Google Code Project で gitを使う方法
• TortoiseHG
  MercurialのGUIツール
• Mercurial - TOBY SOFT wiki
  wikiにまとめているところ
• 特集：Mercurialではじめる分散構成管理｜gihyo.jp … 技術評論社
  Mercurial入門によい
• Mercurial hosting — bitbucket.org
  Mercurialリポジトリホスティング。
• Project Kenai -- We're More Than Just a Forge
  ここも、Mercurialリポジトリホスティング。フォーラム、ML、wiki、バグトラックつき
• Accelerating Software Development | Assembla
  svn,git,Mercurialにも対応しているリポジトリホスティング

前回に引き続き、分散バージョン管理ソフトの話です。

最初は Linux の Kernel ソースのバージョン管理にも使われている git を使ってみました。
Ruby界隈で流行っているみたいで、Ruby on Railsのバージョン管理にも使われているようです。

ちょっと使ってみたところ、
git は Windows 環境だとなかなか厳しい感じです('A`)

• CRLFの扱いが変(diffとか)
• cygwin版での文字コードがらみ(日本語ファイル名が×)
• TortoiseSVNみたいなGUIツールがないので人に勧めにくい

などなど、細かいところは大分解決できましたが
本番環境で使うにはかなり問題があります。

GUIで履歴表示する gitk とかは結構、見やすいんですけどね。
(記事上の画像はgitkです)

gitのすごくよい点としては
Subversion からの変換や相互運用の簡単さみたいで
git svn なんてコマンドが用意されてます。

Subversion対応しかないGoogle Code Projectでgitを使おう、なんていう記事もありました。

まーつまり、Subversionのリポジトリ（ソースコードの倉庫）から
git に引っ張ってきて(pull相当)、
git で編集して(コミット)、
また Subversion のリポジトリにもどす！(push相当)
みたいなことが簡単にできるようです。

gitに関するトラブルやTipsなどは、wikiにまとめておきました。
でも今はMercurialに移行中なので、あまり更新されないかも ^^;

Unixで使うにはすごくよさそうなツールなんですけどねえ。

■リポジトリホスティングgithub

実はgitには、 github
なんていうリポジトリを貸してくれるサービスがあります。
オープンソースプロジェクトのような公開プロジェクトの場合、
現在は100MBまで無料で利用できます。

これがどうも界隈で git の火付け役になっているみたいです。
Ruby界隈その他ではかなり使われているみたい。

また、githubの面白い試みに、Gist
というソースコード貼り付けサービスがあります。
単一のソースコードを貼り付けられる系のwebサービスで、
それをgitでバージョン管理してくれるというものです。
webサービスですが、コマンドラインからでも管理できるとか……。

gistに貼り付けてみたサンプルはこちら
gitstに貼り付けたコードをblogなどに埋め込むこともできるとか。

実は自分もgithubを、ちょこちょこと使ってみています。

Delphiのexeをバンバンコミットしてpushしていると、
100MBだとすぐに一杯になりそうに感じました ^^;;

■他にもgitのリポジトリホスティングはあるよ

githubの他にもgitのホスティングサービスはあるようです。

• Assembla
  プロジェクト数無制限。200MB。svn,Mercurialにも対応。Trac,wikiつき。
• Unfuddle
  プロジェクト数1つ。200MB。svnにも対応。
• Rubyforge
  ※Ruby用です。最近 git 対応になった。

githubの影響かいろいろなところがgit対応になってきてますね。
sourceforgeもそのうち対応するんじゃないんだろうか？

■次回は……

次回は、別の分散バージョン管理ソフト、
その３ Mercurial編です。

■参考リンク

• Git - Fast Version Control System
  git公式サイト
• Git - Wikipedia
  Wikipediaで歴史などを参照できます。
• git - TOBY SOFT wiki
  Windows上で自分の遭遇したgitのトラブル、Tips等をまとめています。
• Your Dashboard — GitHub
  gitリポジトリのホスティング・サービス
• Gist — GitHub
  ソースコピペ・サービス
• Accelerating Software Development | Assembla
  プロジェクト数無制限。200MB。svn,Mercurialにも対応。Trac,wikiつき。
• Unfuddle: Subversion Hosting, Git Hosting, Bug and Issue Tracking
  プロジェクト数1つ。200MB。svnにも対応。
• RubyForge: Welcome
  Ruby用のホスティングサービス。最近 git 対応になった。

最近、ソースコードやドキュメントの管理に
分散バージョン管理ソフトを試してみています。

具体的には gitとMercurial(hg)を使ってみています。

■利点とか

それら分散バージョン管理ソフトを使ってみて感じた利点は以下の通り。

• 中央集権的でない使い方が可能
• サーバーにつながっていない時も使える（！！）
• 分散＝分散バックアップにもなる
• ブランチ(枝分かれ)が簡単
• 複数人でかなり作業がしやすそう

などがあると感じました。

■分散型の利点

以前使っていた、cvs や Subversionは、
中央集権型のため、
ひとつのリポジトリ（ソースコード置き場）に対して、
コミット（変更の反映）したりしていました。
例えばそのリポジトリはサーバーなんかに置いていました。

で、サーバーと繋がっていないと、
ちょっとした変更もコミット、反映できなくて困ったりしました。
（社内サーバーとかだとよくある）

ところが分散管理だと、
他のリポジトリから clone（リポジトリの複製）すると
まず手元にリポジトリそのものを持ってきます。

この時点ですでにバックアップにもなっています。

その後は、ソースを編集したら
手元のリポジトリにコミット（変更の反映）しつつ、
サーバーに push (リモートのリポジトリに反映)します。

手元でコミットするだけならサーバーはいりません！
つまり、会社を休んでスタバでプログラミングしつつ、その場でコミットしたりバージョン管理ができます！！
（マクドでも可）

素晴らしくないですか？

誰かがサーバー側に push した場合など、
サーバーに上がった変更を持ってくる時は pull します。

■ブランチ作業のしやすさ

また、これらの作業、つまり
リポジトリのclone、push、pullはサーバーがなくても手元のリポジトリ同士でもできます。

これを使うと簡単にブランチ(枝分かれ)が作れます。

例えば、サーバーから clone してきた、
もしくは pull してきたリポジトリとソース一式があります。
この手元のリポジトリは絶賛開発中なのですが、
クライアントや上からの要望でちょっとした変更を
試したいと思いました。

この時は、開発中のリポジトリとは別に
新機能用のディレクトリに cloneします。
新機能用リポジトリができますので、
それに新機能を足して編集してコミット。

あとは、新機能が実装できたら全部コミットして、
元の開発中のリポジトリに push します。

もし、新機能がいらないやと思ったら、
ディレクトリごとポイッと削除してしまえばいいです。

開発中のと新機能のと、
ソースコードの結合、衝突の回避(merge作業)など、
後の作業はあるのですが、
何がすごいかというと、これが全部サーバーなしで
手元で簡単に低コストでできてしまうことです。

これは分散バージョン管理を使わざるを得ないのではないか！？
と思った次第です。

■次回は……

さて、次回は、実際のソフトを使ってみた雑感をお伝えします。
その2 git編です。

■参考リンク

• バージョン管理システム - Wikipedia

この記事を読まずに、あなたのゲームにリプレイ機能を実装するのはあまりに危険です……。

なぜなら……。

前回のゲームにおけるリプレイの実装方法の続き、後編です。

お読みでない方はまずは前回からどうぞ。

■乱数の処理

乱数は再現可能なものを使います。
最初に使っていたのは線形合同法でした。

GuNMeNのときは何を思ったか、
あらかじめ線形合同法で生成しておいた65536個の乱数テーブルを使ってました。
まあ、これはあまり意味ないです。
（たぶん、家庭用ゲームみたいなことがやりたかったのかと）

今は、乱数生成ルーチンには Mersenne Twister を使っています。
Mersenne Twisterも再現性があります。

ちなみに乱数種（シード）の自分で初期化をする場合は、
そのシード値も記録する必要があります。

さらっと書きましたが、最初にまずハマるところですので注意を。

面倒くさいので最近は、乱数種の変更すらしてませんｗ
つまり、乱数種固定で初期化ｗｗｗｗ

また、これは重要な点なのですが、
自分の場合は乱数オブジェクトを複数持っています。
今のプロジェクトだと主にメインの更新処理で使うもの用と、エフェクト用と、描画用を持っています。

乱数オブジェクトを複数持つ利点は、
ちょっとした変更に強いことです。
つまり、ちょっとした変更をしてもリプレイをずらさないようにすることができるのです。

エフェクト弄りたいなーってときは、
エフェクト用の乱数オブジェクトのインスタンスを別に持っていて、
ゲーム進行に影響を与えないようにしておけば、
エフェクトを弄っても、リプレイに影響がでません！！
（逆に、あくまでエフェクトがメインのゲーム進行に影響を与えない前提です。エフェクトの上にキャラクターが乗れる、とかいう仕様では無理です。まあ、そうなったとしても、それをエフェクト以外に割り当てるだけですが）

■描画を飛ばす場合は、飛ばしていいものだけを書いておく

更新処理が固定フレームレートベースで、
描画をスキップするような実装をする場合、
前提として、描画処理と更新処理をわけます。

そうなると、絶対に実行される更新処理の方（キャラクターの移動とか）は、描画の方に入れないようにする必要があります。

逆に言うと、描画の方には飛ばしちゃいけないものを入れないようにしないといけません。

例えば、こんな感じ。

// 更新処理 procedure TSceneManager.Update; begin // キー状態取得 Input.UpdateKeyState; // 各エンティティの更新処理 MyCharcter.Update; Enemies.Update; Effects.Update; // 判定処理 CollisionManager.CheckAll; end; // 描画処理 procedure TSceneManager.Render; beign // 描画処理のみにする！ MyCharcter.Render; Enemies.Render; Effects.Render; end;

自分の場合、描画処理でも乱数を使いたくなるので、
描画処理用にも乱数オブジェクトを 1つもってます。
そうすると描画が飛ばされたりしても、
更新処理用の乱数には影響がでません。

■ハードウェアは変えないこと

ハードウェアが再生環境と同じアーキテクチャでないとダメだと思われます。
ようするに、リプレイを記録した環境と同じような計算をするハードウェア環境で再生しないとダメです。

これに関しては今は大丈夫ですが、将来どうなるかわかりません。
10年後は再生できる環境が残っているものでしょうか？

極端な例ですが、Intel社のCPUとモトローラー社(以前のMacの)のCPUとでは、
エンディアンが異なりますよね？
考慮していない場合は、同じように再生できません。
（もちろん、浮動小数などそれ以外にも考慮しないといけないものがありますが……。）

■リプレイ時にキー操作

リプレイを再生中に、早送りとか、ポーズとか、終了したりとか。
あれ？キー判定どうすんの？

簡単ですよ！
メインで使っている（再生で使っている）キー入力オブジェクトとは別にリプレイ中のキー操作オブジェクトを生成して使うだけです。

だけです、さらっと書きましたが、キー入力周りをそういう風に組んどけってことですｗ

↓こんな感じ。

記録中は以下のような感じだとすると、

• Player Aのキー入力オブジェクト(記録中）
• Player Bのキー入力オブジェクト(記録中)

再生中は以下のような感じ。

• Player Aのキー入力オブジェクト(記録から再生してるだけ)
• Player Bのキー入力オブジェクト(記録から再生してるだけ)
• リプレイ画面のキー入力オブジェクト(記録はもちろんしてない)

再生中のフラグが立ってるときだけ、「リプレイ画面のキー入力オブジェクト」を処理する。
（記録中は生成すらしない）

リプレイ画面のキー入力オブジェクトは、Player A(B)のキー入力オブジェクトのクラスを使いまわしてます（インスタンスでなくてあくまでクラス）。

あらかじめキー入力をクラス化しておけば、こんなのはサックリできますよ。

■バージョンアップしても大丈夫なように場合わけする

バグ報告をもらってバグ修正したり、
バージョンアップしたりして、
前のリプレイが再生できなくなったりすると、
かなり萎えますよね？

そこでこの方法をとります。

ひそかに、前述の WireBattler や GuNMeN は、
（リリースした範囲の）昔のバージョンのリプレイも再生できます。

これは、リプレイのデータファイルにバージョン番号を埋め込んでおいて、再生時に古いバージョン番号の場合には、古いルーチンを動かしているのです。
ですので、昔のリプレイも同じように再生できます。

例えば、GuNMeNは最初にコミケでリリースしたバージョンより、
現在のリリースバージョンの方がバランス調整がしてあり、
キーボードでもプレイしやすくなっています。
なんと、その新しいバージョンでも、
昔のコミケの時のリプレイデータが普通に再生できるのです！
（現に、タイトル画面を放っておく事で見られるデモプレイは、昔のバージョンのリプレイをそのままつかっているのです）

その代わり、バグって落ちるリプレイとかは、
バグ報告をもらって直しても、依然、落ちるままですｗｗｗ
（今はそうそうないですが、未熟な時代に（WireBattlerを作っていたくらいの時）頻発しました）

ただ、パラメータなどを外部に出している時はちょっと処理が増えるので面倒ですが、やる価値はありますよ。

ていうか、このこと初めてかいたよ！
ユーザーの視点から立つとリプレイデータが使えなくなる、ということは避けるべきは当たり前なのですが、やっている人どれだけいるのかなあ。

大体、リプレイ実装の際の注意点はこんな感じですね。

■コラム：洋ゲー関係のリプレイについて

個人的には、市販のFPS、RTS類のリプレイが気になっているところです。

昔から FPS、RTSなどは大概可変フレームレートですし、
どう同期をとっているものやら、と。

自分が一時期プレイしてた Tribes 2 なんかは途中から記録して、そこから再生も可能でした。
ネットワークゲームですが、記録するマシンのネットワークが遅くてもばっちり対応できてました。
（Tribes2のネットコードの優秀さは定評があったのをさしおいても）

もちろん、可変フレームレートでも、他機種でも再生可能でした。

あとは、RTSもきちんとできますよね。
自分がよくリプレイを見ていた Rise of Nations や Command & Conquer Generals あたりもかなりリプレイはきちんと動いていました。

ただ、ほとんどのRTSはバージョンアップしたら、
前のバージョンのものが再生できなかったり、
再生できても途中からずれるという、けっこう適当なんだけれども……。
（パラメータやプログラムなどのバージョンわけの仕組みはずさんな模様）

まあ、この辺の洋ゲーマジックは一度暴いておきたいところです。

参考になるのは Quake3 のソースとか、
Torque Engine(Tribes2用ゲームエンジン)とかかな？

■まとめ

以上のような形でリプレイ実装の記事を書いてみましたが、参考になったでしょうか？

ちなみに、今回の記事で紹介した実際にリプレイが動いている自作ゲーム「WireBattler」、「GuNMeN」、「GanGanGan 体験版」の全てのソースファイル(Delphi用)は「GuNMeNパッケージ版」に収録されています。

実際にリプレイが実装されて動いているゲームとそのソースファイルが見てみたい方は、お手に取ってみて下さい。参考になるのではないかと思います。
(各ゲームのソースコードは CDの /omake/source ディレクトリに .zipファイルで入っています )

ぜひ、あたなも自作ゲームにリプレイを実装してみてください。
ゲームの提供の幅が広がるはずです。

では、今回はこの辺で終わりにします。
ありがとうございました。

[2008/07/20] 誤字脱字修正。

■参考リンク

• WireBattler:自作2D格闘ゲーム
• GuNMeN:自作2D固定画面アクション
• Gan Gan Gan体験版:自作2Dシューティングゲーム
• GuNMeNパッケージ版:上記3つセットのパッケージ版。ソース付き

この記事を読まずに、あなたのゲームにリプレイ機能を実装するのはあまりに危険です……。

なぜなら……。

さて、ちょっと前の話題ですが、
リプレイに関する話題が流行っていました。

• リプレイバグフリーは実現可能か - ABA の日誌
• リプレイ - PlatineDispositif
• リプレイバグを潰すための七つの方法 (へっぽこさんメモ)

そのことについてうちでの実装方法を書いてみようと思います。

うちの場合は、基本的に入力情報を全部記録して、
再生時に与えてやるという感じです。
いわゆるキー入力記録タイプ。

面倒くさい気がしますが、入力情報を取得するAPIやライブラリにラッパーをかませてやれば簡単です。

大概、WireBattlerとか GuNMeNのときに悩みまくったので、
それ以降、このタイプの記録方式ではそんなに苦労していないですね。

■自分のリプレイ実装の実績

• WireBattler:2D格闘ゲーム
  リプレイの他に、もっとも連続技をつなげたところから再生する機能もあり
  固定フレームレート
• GuNMeN:2D固定画面アクション
  インターネットランキング対応で、他人のリプレイをダウンロードして再生することもできる。
  固定フレームレート。
• Gan Gan Gan:2Dシューティングゲーム
  今のところ体験版のみのリリース。
  ステージごとに再生が可能。
  可変フレームレート（但しベースは60FPS）

■入力情報記録タイプで気をつけることをいくつか

実績を見てわかるように、この記事では、基本ベースフレームレートが固定のものに使えるリプレイのテクニック及び注意点を解説しています。

ぜひゲーム作りにお役立てください。

■途中でずれたらオワリ＼(＾o＾)／

この入力情報を記録するタイプでは、
最初から再生して、途中でずれたらそこで失敗になります。
一度ずれたら、その後ずーっとずれっぱなしになるためです。

なので、かなり厳密に作る必要があります。

■キー入力の記録

まず、この方法の基本はAPIから取得したキー入力を全部記録しておくことです。

かなりメモリーを食うのでは？とか思った人います？
大丈夫です、安心してください。
まあ計算すればすぐにわかりますがたいした容量ではありません。

カーソル4方向 + 4ボタンなら 8bits=1byteです。
60FPSとしたら、30分記録するのに、

1 * 60 * 60 * 30 = 105 kbytes

2人プレイなら2倍、ボタンが2倍ならさらに2倍になるだけです。

全然大丈夫ですよね？

というか、10年以上前から オンメモリーで全部記録していましたが問題はなかったです。
もし精神的に嫌なら、zlibのストリームにでも突っ込んでいけばよいのではないでしょうか？
(WireBattlerのころは一応、自前でリアルタイムにランレングス圧縮をかけてました。今は素でオンメモリーストリームに突っ込んでいるだけです)

記録と再現の仕方ですが、ラッパーを作ってやるとよいです。
つまり、記録時に実際に入力したキー情報をラッパーを通した段階で記録し、再現時には実際のキーは無視してそのラッパーから記録したものを出力してやるだけです。

そうすれば、キー入力を処理する外側からは、
まったく同じように見える（＝同じようにプログラムを組める）よね？

■全部初期化すること

基本的にプレイ開始時に全部初期化することです。
初期化を忘れて、前のプレイの状態変数なんかが残っているとずれます。

一番簡単なのは、オブジェクトのインスタンス確保で、データがすべて初期化されるように最初から組んでしまうこと。

そうすれば、プレイが始まったらインスタンス確保、
プレイが終わったらインスタンス開放。

つまり、メモリも一旦全部開放してすっきりさわやかにしてしまうのです。

■浮動小数点がらみ

これが実はあまり再現ができてなくてよくわかってないのですが、
浮動小数点の丸めモードの違いがあると、計算結果がずれるんです。

それがどうも他のアプリケーションの影響などで、突然変わることがあるらしいとか。
（不確定すぎてすいません）

で、かなーり昔から(10年くらい前から)なんですが、
浮動小数の算術関数に FINIT でコントロールワードのリセットを入れまくるっていう方法を使ってました。

例えばこんな感じです。

//**************************************** // Sinのコントロールワード初期化版 //**************************************** function O3Sin(const X: Real): Real; var ControlWord: WORD; begin // コントロールワードの退避とリセット asm FNSTCW ControlWord FINIT end; Result := System.Sin(X); // Set8087CW(ControlWord) :) asm FNCLEX // 例外抑制 FLDCW ControlWord end; end;

で、Sinは直接呼ばずにこれを通すと。

ただ、この現象については不確実なので責任が持てませんｗ

■CPUにより演算結果が変わるライブラリがある

Direct3DのサポートライブラリのD3DXとか使うと、場合わけして勝手に最適化したルーチンが呼ばれるためにCPUによって演算結果が変わるようです。
（主に浮動小数点。またか）

けっこういろいろなゲームの作者さんが「リプレイがずれる」という報告を受けているようなのですが、ほとんどが、これか、前述の浮動小数の誤差だと思います

いろいろ解決策はあるようですが、
自分の場合は、自前実装で回避でした。

というか、Direct3Dまともに使ったことねえｗｗｗ
(DirectDraw派→CPU描画派→OpenGL派（いまここ）)

■コラム：WireBattler の途中再生機能

ちなみに、対戦格闘ゲーム「WireBattler」の最も多くつなげた連続技を見られる機能、つまり、途中から再生する機能は、記録時にある地点（地面にダウンしたとき）にフラグを立てておいて、リプレイ時にそこまで描画を全部すっとばして早送りしているだけなのです。

なのでCPUが遅いとけっこう時間がかかってしまいます。

■次回に続く

長くなりすぎたので続きは次回に！

後編書きました。

■参考リンク

• WireBattler:自作2D格闘ゲーム
• GuNMeN:自作2D固定画面アクション
• Gan Gan Gan体験版:自作2Dシューティングゲーム
• GuNMeNパッケージ版:上記3つセットのパッケージ版。ソース付き

以前、自分が「はてな」で質問した以下の項目が、先日終了しました。

ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？ プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいま.. - 人力検索はてな

後半だれてきて、後に行くほど返信に熱がこもっていないのはスンマセン(´д｀)

■サックリ私感でまとめ

• なるべく正しい見積もりを伝えようということ
  3倍かかるなら、それを見越して。
  Ruby の創始者 Matz氏も、「普通に(特に悲観的でなく)見積もった時間に1.5から2.5までの係数を掛けることにしている。」と言われているくらい。
• 効率化よりも、作業そのものを減らそう
• 分担できるところは、他人に回そう。
• コードを書くことに固執しすぎているので注意がいるだろう。
  どうしても美しく仕上げたがるので、妥協が大切。
  (趣味プロが長いせいか難しい( ´д｀))
• 人間なので集中することこそが早く仕上げるコツである。
  また、具体的なその方法 と 関連書籍。
• 矛盾に陥るような負のサイクルは、断ち切る必要がある。
  あなたは効率化のために道具ばかり弄っていないか？
• 言語環境などが目的にあっていない。
  Delphiでゲーム的な面。

基本的に、自分の今の状態にあてはまるものを選んでみました。
（他にも参考なる回答はたくさんあるので、ぜひ読んでみてください）

思うに、コードはやっぱり仕事モードで書かないと難しい。
趣味で培ったモノは足かせになることが多い。

最後のDelphiに関しては、書くことがあるのでまた後日に。

■仕事場で話していたこと

スピードも大事だが、

毎日継続すればいつか終わる

ことを意識して続けようということを仕事場で話していました。

しかし、これはわかっているのですが、
残念ながら対象のプログラムに対する意欲がなかなかでないので無理でした。

早く終わらせれば、次々にこなせられれば、
やる気がでるのでは？と思って、はてなで聞いていました。

鶏が先が、卵が先か。
最近、自分のやる気が絡む物事は、これが多い。

ある種のバラドックス的な無限ルーチンに陥っている感。

■感想

いつもはてなで質問してもロクな答えがなかったので（ぉぃ）、
思わずちゃんとした答えが返ってきて、つい熱が入ってしまった。
残り2日でウォッチリスト 50userいっていたのでびっくり。
同じようなことに関心がある人はたくさんあるんだな、ということ。

速く仕上げるのに、小手先のテクニックよりも、
集中力がかなり大事という再認識。
それと、余分に時間をとって見積もる。
これらはすぐにできる。

それと、「遅れても少しづつ仕上げる」ためには、
やはりやる気がいる、という帰結になる。
（ますます、病気を治さなあかんという話にもなる）

完璧な銀の弾丸はないのだろう。
しかし、少しずつ早くするというテクニックだったり、
心構えだったり、ノウハウは確実にあると感じた。

とはいえ、結局のところ、一番心が休まったのは職場で話したことだったりする。

んで、今の意欲がなくて、現状止まっているプロジェクトに関しては、
今のことは置いておいて、
技術的欲求があることにシフトして、
それを元のプロジェクトに生かそうということになった。
英断だが、普通の会社だとこんなこと絶対無理だ。
（しかし、この技術的興味も一時的な欲求でまたイヤになるのか？と思うとかなり不安。これが負の連鎖か……これだけは避けねば）

■回答などででてきた参考になったサイト、書籍

• Joel on Software - 5つの世界
  同じプログラマーでも、分野が違いがあるということ。
• 2008-02-08 - 混沌（Chaos）なバグ
  「世の中には汚くならざるを得ないｏｒ汚くてもよいソースもあるって事も忘れてはいけない」
• amazon - ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵
  人間であることに焦点を置いた本。
• 集中力を高め、仕事に余裕を生む「70%予定管理法」 - ELECTRIC DOC.
  集中力を保つために、余分な時間を入れて予定を立てること
• はじめてのGTD - ITmedia Biz.ID
  最近、必要性を感じているGTDについて。
• あらゆることがうまく行かなければどれくらいかかるか?
• amazon - ソフトウェア見積り―人月の暗黙知を解き明かす
• amazon - ザ・ゴール ― 企業の究極の目的とは何か
• amazon - 考える技術・書く技術―問題解決力を伸ばすピラミッド原則
• あらゆることがうまく行かなければどれくらいかかるか? - Matzにっき(2007-05-23)

けっこう過去に名著と聞いたことがある書籍が一杯あるので、
暇を見つけてはよんでいきたい。

すごく楽しみです。

最後に
皆さん真剣に答えてくださり、ありがとうございました。

このままだと人生が不安で昼寝もできないので、
はてなで質問してみた。

ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？ プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいま.. - 人力検索はてな

お仕事で、
東京コンテンツマーケット2007(TCM2007)に出展のため、
東京に、出張してきますヽ( ´ー｀)ノ

徹夜で、ゲーム作ってましたが、
微妙に、自分の割り当ての、出展物が間に合ってない件(´д｀)
でも、やるだけはやったので、
少しでも、いい結果が出ることを期待。

ちなみに、前回出展時に使ったムービーが youtube に
上がってたのを、紹介するの忘れてた。

これは、去年のTCM2006に、出展したプロモムービーです。

ムービー内のL-GAUGEは、ネットには未発表のはず。
自分がプログラムを担当しているもので、
前回の出展の際に商品化の話があり、
今回の TCM2007 で、特別にリニューアル版が展示されます。

今回の出展作品の紹介ムービーも、多分、
上げてもらえると思うので、
その時も紹介しようと思います。

リハビリにて、必要なソフト作り。
正味、4時間で適当に完成。

『Internet Explorer Reloaded』(通称 IE Reloaded)
指定のフォルダ内のファイルが更新されていたら、指定のURLを更新するソフト。

HTMLをエディタで編集、デザインしている人向けです。

フォルダとURLを指定して、
エディタの横に置いておけば、

エディタでHTMLや、CSSを保存する！
　↓
勝手にブラウザ(IE Reloaded)が更新される
　↓
(ﾟДﾟ)ｳﾏー

ブラウザ部などは、全然未完成なので、
ちょっと使いにくいけど、
これだけでも、普通に使えるはず。

文字の大きさの変更などつけたいところはあるけど、
ベータレベルですが、
一応、配布しておきます。

ダウンロードは、こちらから。ver 0.0.1です。
(最新版はwikiにあるので、wikiからダウンロードした方がよいです)

最新版の提供、サポート、要望等は、wikiの方に。

■技術的な話

Delphiで、さっくりと。

GUIは、ToolBar2000 の拡張の TBX の拡張の SpTBXLib を利用してみました。

密かに大部分が、UNICODE対応になってますので、
国際版も作れるかも。

そこそこ有用だと思うので、
英語版くらいは作っておきたいところ。

ベータ版だから、さっくり作れるけど、
ブラウザだし、完成度上げるのは、大変そう。

■参考リンク

• Internet Explorer Reloaded - TOBY SOFT wiki
  IEReloadedサポートサイト
• DelWiki - コンポーネント/Toolbar2000
• jrsoftware.org // Jordan Russell's Software
  Delphiの定番コンポーネント ToolBar2000 の本家サイト
• TBX
  ToolBar2000の拡張コンポーネントTBXのサイト
• Silverpoint Development
  SpTBXLibのサイト

Lightweight Language Spirit
スクリプト言語の会合セッション。

まとめリンク

• SumiTomohikoの日記 - Lightweight Language Spirit 2007報告
• a geek - LL魂の実況中継

うわー、おもしろす……。

ラインナップがすげえ。
Rubyに、Pythonに、Luaに、話題のxtal、なでしこまであるよー。
crowbarにDiksamまで（なんというマイナー）。

どうみてもLLじゃない、Java とか Clean があるのはご愛敬

行きたかったなあ。
旅費ないけど。

こういうのはすんごく、興味あるわけだけど、
積極的に参加できないのは、
自分が、LL（スクリプト言語）で、飯食えねえと思ってるからだと思う。
Rubyのまつもとさんを始め、飯食っている人には、失礼だけど。

じゃあ、何なら飯食えるの？というのは、あることはる。
いや、Delphiで、今、飯食えてないからさー。

しかし、プレゼン資料あったら、
穴が開くくらい見るあたり、興味はある模様。

今作っているゲームの組み込みスクリプト言語どうすべきか。
主にデータの定義や宣言に使う。
今は、パラメータは、xmlで書いているけど、素のxmlだと計算ができないので痛い。

やっぱりちゃんとした、スクリプト言語を組み込みたいところ。

以下、候補。

• Lua
• Squirrel
• Xtal
• Ruby
• Python

Rubyは、Pythonは、ゲームの組み込みにはちょっとデカイ印象。

■Lua

あと、関数呼び出しで、スタックを操作するってのがなんかキモイ。
キモイというか、脳が死ぬ。

■Squirrel

Squirrelは、どうだろ。

実は、まだ試してないのだけど、
Luaの仕様にブチギレた FarCry のプログラマが作ったというので、
かなり期待をしている。
（そーいや、FarCryってLua使ってたなー）

つまり、ベターLua 的存在。

しかしながら、Squirrel の Delphiバインディングは、まだないみたいなので、
使うなら、作る必要性がでてくる。
そもそも、もし、C++依存だったり、DLL化を意識してない作りなら、
簡単に作れるかわかんないわけだけど。

Squirrelで、長いコードを書く気はさらさらないのだけれど、
一応、SQDEVなるEclipseな、開発環境兼デバッグ環境もあるらしい。

(どーでもいいけど、Squirrelって、末尾再帰対応するっぽい？そんなの組み込み言語にいるのかよ！)

困ったことに、素のSquirrelは、Lua同様スタック操作必須。
キモイヨー。

■Xtal

Xtalは、期待の新星。
たぶん日本人によって作られている、ゲーム用組み込み言語です。
Luaや、Ruby、Python なども参考にされている様子。

まだ、ver 1.0 になってないようなので、
使うには早々かもしれないですけど、
機能や、言語仕様などを見ると非常に期待できます。

ただし、C++依存のようで、Delphiへの組み込みはちとつらいだろう。
DLLにして、依存部分をラップして……と、考えるとやはりつらそう。

■参考リンク

• Lua
• Squirrel
• Squirrelの参考になりそうなページ(日本語)
• xtal-language - Google Code
• 新言語 Xtalを作る日記

前に『GBAで弾幕シュー』ってのを書いたんですが、
作者さまからコメントいただきました。

1024発弾出せるって書いてあって、
GBAってそんなにスプライト出せるんだ……と思っていたのですが、
どうやら、そのままでは、出せない様子です。
（標準だと、128個）

スプライトダブラという機構を使って増幅している模様。
（詳しいことは、本家の解説記事『GBA で学ぶ古典的プログラミング (スプライトダブラ)』をぜひ。
ようは、水平復帰(HBLANK)割り込みを使い、
仕様上のスプライト制限を回避しているようです。
同じことをやっているものは、「超連射68k」が記憶に新しい（新しくない？））

ファミコンなんかの世代だと当たり前の技術らしいけど、
今でも使うんだなーと。

BulletGBAに関しては、XMLを解析して、真面目にやっているのではなく、
事前に、PHPで、C++に直接変換して、実行しているようです。
ループなんかも、全部展開しているらっすい。
すげえ。

この辺のことは、『粉骨砕身の覚悟でがんばります[2006年03月04日] - BulletGBA の歩み』に書かれています。
涙ぐましい努力……。

あと、やっぱり、スペック的に、固定小数点なのね。

コンバーターが、当初、Rubyで遅いってのは気になった。
そうか、XMLパーサー遅いのか……。

■参考URL

• [ゲーム] GBAで弾幕シューティング (第一種臨界不測日記)
• 『GBA で学ぶ古典的プログラミング (スプライトダブラ)』
• 『粉骨砕身の覚悟でがんばります[2006年03月04日] - BulletGBA の歩み』

ちょっと、復帰してきたかもしれない（精神的に）
（というか、精神的 gdgdの状況書くころには、遅すぎて、反転間際）

さて、ソフトウェアのサポートの関係で、
Windows Vista移行するかどうかという問題。
同人とはいえ、売り物がある以上、動作確認せないかんよなあ。

Vistaに移行する長所

• ソフトウェアの動作確認ができる。

Vistaに移行する短所

• ソフトウェアの動作確認をしなくてはいけない（ぉぃ）
• 普段使っているソフトが動かなくなる可能性がある
• 昔のゲームが動かなくなる可能性がある（他人様のゲームの話です）
• キャプチャーカード(MTVX2004)が動かなくなる（痛ええええ orz）＝PS2とかの家庭用ゲームが(ry
• 『窓使いの憂鬱』がVistaだと動くとか、まともに動かないとか(2chの情報)。

短所は、致命的過ぎるところがありー。
PC98のWindowsから、AT互換機のWindowsに乗り換えたときよりは、ひどくはないけど……。

しかし、窓使いの憂鬱はないと、オイラは何もできないので、
代替手段を探すなりなんなりしないと困る。
（キャプチャーカードは、PS2とかやらなけりゃいい話（よくないよ））

しかし、今からパソコン買う人は、
自作派以外（ノートPC含む）は、
Vistaだろうし、動作確認用にはほしいところなんだが……。

とりあえず、
Delphi製アプリがそのままだと不都合ありまくり、らしいので、その辺が心配です。

まあ、メインマシンには導入せずに、仮想PCで……かな？
やっぱり。

Unixみたいに、ディスクイメージとかで配布されていればいいけど、
商用OSではそれは無理だな、それは。

とりあえず、Vistaを入手してからだな。

『[開発] シーン管理が必要だなあ』の続き。

結局、図のような感じで、

• Call(Scene) 呼び出し
• Return 呼び出し元に戻る
• GoTo(Scene) そのまま移行

をインターフェースに持つシーン管理クラスを作ってみた。
うまく動いている。

図のような決めうちならば、
GoTo(Scene)だけでよいのだけれども、
実際には、タイトル画面→面セレクト→ゲームメイン→……
以外にも、タイトル画面→ゲームメイン……
だったりすることもあるので、
Call（呼び出し）がやはり必要。

インターフェス周りだけ、適当に抜粋すると、こんな感じ。
private部は省いている。

TSceneClass = class of TScene; TScene = class protected // シーン開始時に呼ばれる procedure Start; virtual; // シーン終了時に呼ばれる // 必ずよばれるとは限らないので、 // 開放処理は、Destroy;で procedure Finish; virtual; // Returnで戻ってきたときによばれる // デフォルトは、Startを呼び出す procedure Restart; virtual; // フレーム更新処理 procedure UpdateFrame; virtual; // 描画処理 procedure Draw; virtual; property SceneManager: TSceneManager read FSceneManager; public constructor Create; virtual; destructor Destroy; override; end; TSceneManager = class public constructor Create; virtual; destructor Destroy; override; // シーンの遷移命令 // そのまま遷移(goto) procedure GoToScene( const aTargetSceneClass: TSceneClass); // 呼び出しの形で遷移(call) procedure CallScene( const aTargetSceneClass: TSceneClass); // 呼び出されたシーンに戻る(return) procedure ReturnScene; // フレーム更新処理 procedure UpdateFrame; virtual; // 描画処理 procedure Draw; virtual; end; (どうでもいいけど、このブログデザイン、横幅せまくて、ソースかきずれー)

TSceneを継承した、例えば TTitleSceneとか、TGameMainSceneとか、
TStageSelectScene を作ってやって、
SceneManagerから、GoToとか、Callとか、Returnする形。

意外にすっきり書けた。

今回は、状態遷移時に、前のTSceneを開放せずに、
スタックには、TSceneのインスタンスをつんでおくことにした。
これで、Return時には、前の状態が復元されるようになる。
（GAN GAN GANのときは、
スタックには、型情報のみ(TSceneClass)をつんで置いて、
インスタンスは、毎回生成、破棄してた）

これは、前に言っていた、Gems5のとは、違うっぽいね。
2chによると、

285 ：名前は開発中のものです。：2007/04/10(火) 00:13:19 ID:NhbAQuFj
>>277 
シーンは最初に全部確保して 
最後に全部解放してるよ。 

シーンスタックそのものが「アクティブなシーン」のスタックであって、 今アクティブじゃないシーンは別のリストに保管してる。 
でスタックに積まれてるものは一通り処理する。 

こうすることで移動画面中にメニューも表示して移動もメニュー選択も可とか 裏画面でデモ（通常ゲーム処理）回しながら上にウィンドウ表示とか 出来ますよ　って趣旨だったと思う >Gems5 

ただ、ウィンドウ関係以外には特に利点は無さそう。 

286 ：名前は開発中のものです。：2007/04/10(火) 01:08:35 ID:wXzQkwkx
マルチスレッドを実現する手段の一種ということ？ 

287 ：名前は開発中のものです。：2007/04/10(火) 01:12:58 ID:vYIHoF6r
>>285 
＞でスタックに積まれてるものは一通り処理する。 
これ、厳密にはスタックって呼べなくね？ 
LIFO≠スタック 

288 ：名前は開発中のものです。：2007/04/10(火) 01:16:37 ID:EIMh3HFt
なんだ、シーンの遷移がスタック的なのかと思ってた。 

289 ：285：2007/04/10(火) 01:26:00 ID:NhbAQuFj
>>287 
上にシーンを積んだときにサスペンド処理（シーンクラスのメソッド）を呼ぶようにして サスペンド中も実行したいシーンはその処理でサスペンド時も実行してねフラグを立てる とかそんな処理になっていたと思うから　一応一番上に積まれているのが 
現在のシーンってことになる。 
立ち読みだから細かいことは忘れたｗ 

スタック全体をなめるんだからスタックとは言わないと俺も思う。 

やはり、ちょっと違う感じ。
タスクシステムに近い？

開発でも、プログラミング言語でも、
サーバー管理でも、とにかく、逆引きが重要につきる。

リファレンスマニュアルは、必須！
だけど、そこまでたどり着くのに、逆引き辞典は要ります。

こうしたい！→ならこうしろと。

こう、トラブルが起きた！→ならこう解決！

こういうのをデータベース化しておく必要があります。
ってな具合です。

そんなわけで、wikiなんかを自前で建てているわけですが。

小さなところで、OpenBSDのディスクフォーマットは、
何コマンド？って。
しばらく使ってないから、素で忘れてて。

mkfsコマンドねーーー！！ってそれLinuxですから。

で、「フォーマット」で検索しても全然でてこない。
（BSD文化だと、フォーマットって言わないからだと思う）
やっと見つけた！
newfsか！ってな具合。

まあ、こんなトラブルがやまほどあるわけで。

あと、マニュアルには、凡例がほしい。
実際に、どうやって使うの？っていう。
Microsoftの言語リファレンスは、凡例いっぱいで助かります。
Borlandのヘルプは、凡例少ないからちょっとアレ。

お仕事で、作ってるゲームの話。

タイトル画面とか、ゲームオーバー画面とか、
いろいろ増えると、シーン管理がいるなあ。

今は、ポインタで、状態遷移しているんだけど、
1ファイルに詰め込みまくってしまって、不衛生だし。

流行は、スタックベースのシーン管理？

2chによると、

263 ：名前は開発中のものです。：2007/04/01(日) 15:15:13 ID:Sn7iJUNq
>>260 
Gemsの５巻にスタックを使ったシーン管理が載っている。 

試してみたら、なかなか使い易かったよ。 

Game Programming Gems 5 日本語版 Kim Pallister 加藤 諒 川西 裕幸 by G-Tools

『GAN GAN GAN』 の時は、確か、スタックベースでやってたけど。
使いまわすには、古いコードなんだよな……。
（GAN GAN GANのときは、タスクって名前つけてた）
つーか、かなりコードが、ごちゃごちゃだから整理しないと。

とりあえずは、『GAN GAN GAN』 のをゴニョゴニョ改良してみることにする。

続き：[開発] シーン管理その2

最近、web周りは混沌を極めておりますな……。

将来的に、Flash仕事が必要かということで、調べているのですが、
時代的には、ActionScript3 なのか？
プログラマさんは、みなそろいもそろって、
ActionScript3を使いまくってらっしゃる。

Flash8 + ActionScript2は、デザインツールって感じでしたが、
ActionScript3(Flex？)は、マ寄り（プログラマ寄り）にナットるんですかい？

おっと、ActionScript3は、Flex SDKっつーのが無料なので、
それを落とせばすぐに試せるのですかい。
なるほどー。

ナンカ、デモでも作る余裕があるといいのだが。

あと、デスクトップ環境としての、Flashはどうなん？
つまり、Apollo ってどうなんよ？

つか、Apolloってマギラワシー名前つけんな。
Apolloっつったら、RubyのDelphi(VCL)拡張だろうがよ！！

さらに、Apollo調べてたら、Flash関係なくて、
HTML+Javascriptをパッケージにできてデスクトップアプリケーションとして配布できる。
マルチプラットフォーム！フォォォォォォーー！
すばらしいが、何か空しさもある。
（Flash特有の別ドメインにアクセス不可な制限が外れると聞くと面白ことできそうだけど、
結局、オンラインでやることをデスクトップアプリにする意味は……あるか……
昔、Ruby on Rails製デスクトップアプリってあったくらいだし）

さらに、ここに、JavaScript + AJAXが入ったりすると、
（むしろ敵対技術）
まさに、混迷を極めてきますなあ。

手当たりしだいに手を突っ込まないで、見極めたいですな。

オマケ：

Flashでも、3D動くんですね。
スゲー。解像度落とすと、20FPS出てるよ。
マウス操作が、なんかWiiのFPSみたいでキモイけどｗ

custom:media ≫ SWFZ Demo 2

Microsoft TechNet: TechNet Plus サブスクリプション

開発環境抜きの MSDNサブスクリプション と、思えばよいのかな？

なんと、年間定額で、
Windows Vistaや、Office 2007が、評価用にダウンロードできる！

Office2007βを今でも評価しまくっている自分には最適なのではないのか！？

開発環境がいらないなら、MSDNサブスクリプションよりお得なわけでしょうか。

TechNet サブスクリプション FAQ
によると、

• 評価目的
  2chの関連スレによると、結構評価範囲は、広い模様
• 仕事場でも、自宅でも使用可
• 最大10台までイントール可能
  （ソフトごとなのか、全ソフトでなのかは不明？たぶんソフトごと)

あと、会社用に、
Microsoft Action Pack サブスクリプション
ってのもあるようだ。

こちらは、評価用ではないようだ。
というか、こちらの方が安い件。

2ch関連スレ: MSDN／TechNetサブスクリプション 5

先日、公開されたGoogle Code Searchが面白そう。

googleのソースコード版で、
なんと世界中のソースコードが検索できる！

ネット上では、

『Geekなぺーじ：Google Code Searchの危険な使われ方』
や、『秋元@サイボウズラボ・プログラマー・ブログ: Google Code Search のアレな活用法が続々と』
にあるように、セキュリティホールを見つけるような活用法ばかりが(´д｀;)
（2chの Google Code Search スレでもこんなの、ばっかりｗ）

他には、いくつか、ブログで見られたのは、
コードでの変数名のつけ方を見る場合など。

『いやなブログ - 学校では教えてくれないバッドノウハウ英語 #3: if need be』や、『IGINブルネイ/syasudaの日記』
などで見られる。

おー。なるほど、変数名で、みんなこう使うんだー、
という使い方。

ちなみに、「○○するかもしれない」というのは、
上記ブログでもありますが、

• MaybeHoge
• HogeIfNecessary
• HogeIfNeeded

などを使うようで。
参考になる。
今まで、CheckHogeとか、つかっててスッキリしなかったので、これからは、MayBeHogeにしよう。

RubyとかPerl的には、後置if文的な、HogeIfNecessaryも捨てがたいけど。

■Google Code Searchに自分のコードを登録する方法

自分の書いたソースはやっぱりなかったりするわけでｗ

『ひげぽん OSとか作っちゃうかMona- - Google Code Searchに自分のコードをクロールしてもらう方法』によると、

『Google Code Search - Help Google Code Search find your code』のページに、以下を自分で登録することができるようです。

tar.gz,zipなどのArchiveファイルのURL 
CVSリポジトリ 
Subversionリポジトリ 

公開しているソース、追加してみるか……。

■アレな方法以外に利用価値はあるか？

さて、Google Code Searchに、いくつか疑問点があるとしたら……

アレなセキュリティホール探す以外に、
何か革新的な使い方ってないだろうか？

変数名のつけ方に関しては、確かに確認はできるんだけど、
そもそも英語の言い回しを知らないと、
見つけることはできない罠(´д｀;)

とりあえず、ライブラリの使い方を見るのに……って普通だなー。
（頭で、覚えておいて、何かあったときに使ってみようと思う）

APIも公開されているようだし、革新的な何かは出てきてもおかしくない。

■Delphiが検索しにくい？

そういや、何故か、Delphiが検索しにくくて
"lang:Delphi"では無理。"lang:Pascal/Delphi"でも無理。

"lang:Pascal"だと、Delphiが出てくる罠。

なんでじゃー。

最近のゲーム開発は、主に、お仕事の方のを弄っております。

いや、しかし、マウス対応って難しいですね。

作っているのがカジュアルなゲームなだけに、
マウス対応が必須なのですが、
もともと、パッド前提のシステムだったため、
無理やり、マウス対応にしたら、上手く行かないのです。

結局、システム変更、別ゲーになりそうな悪寒です。

プログラミングの話で言えば、
ABAさんのソースコードとか見ながら、
面白そうな構造は取り入れたりしているのですが、
DelphiとABAさん使用のD言語がかなり違いすぎていて、
困りまくりんぐ。

テンプレートをほどよく使われているコードは、
まあ参考になるのですが、
ファイル同士が、相互参照しまくりーのなので、
DelphiだとDelphi特有のユニットの循環参照問題が解決できねー、とか、
ちょっとついていけないところが。

あと、今は、描画周りが、軽くOpenGLを使っているんですが、
DirectXを1から使うのもカッタルイナーという面もあり、
3Dエンジン使うの？とか、Delphiなら、OpenGLスキーとしては、
GLSceneあたりはどうか？
という話が、自分の脳内で展開されています。

最終的には、メガデモ系エフェクトを多用するようなゲームになりそうなので、
OpenGLでも全然大丈夫だと思うんだけど。

ただ、自分、時代に乗り遅れていて、シェーダーとか全然弄ってないからなー。
どうなるものかと言う気はする。
（そもそもOpenGLのシェーダーって動いているのを見たことがな(ry)

シェーダー周りも書いてある、
『OpenGLプログラミングガイド 原著第5版 (大型本) 』とか欲しいのですが、
￥ 13,650 （税込）って、いかんせん高すぎる。
合わせて買いたい、なんて、3万円ですぜ。
（よりによって、リアルタイムレンダーリング第二版だぜ（←ほしい）

個人的に、HDRバリバリ効かせた、メガデモーな、
時間の合間にサクッと遊べるカジュアルゲーム、なんてのは
いいなーとか思うんですが。

はてなダイアリー日記 - 入力したプログラムコードを色付けするスーパーpre記法 シンタックス・ハイライトの実装について

そういえば、しばらく使っていないはてなダイアリーが、
プログラムコードのシンタックス・ハイライトに対応していた。

これだけなら、別にすごくはない気がするが、
問題は、サポート言語の数。

a2ps a65 aap abap abaqus abc abel acedb ada aflex
ahdl alsaconf amiga aml ampl ant antlr apache apachestyle arch


art asm asm68k asmh8300 asn aspperl aspvbs asterisk asteriskvm atlas


automake ave awk ayacc b baan basic bc bdf bib


bindzone blank bst btm c calendar catalog cdl cf cfg


ch change changelog chaskell cheetah chill chordpro cl clean clipper


cmake cobol colortest conf config context cpp crm crontab cs


csc csh csp css cterm ctrlh cupl cuplsim cvs cvsrc


cweb cynlib cynpp d dcd dcl debchangelog debcontrol debsources def


desc desktop dictconf dictdconf diff dircolors diva django dns docbk


docbksgml docbkxml dosbatch dosini dot doxygen dracula dsl dtd dtml


(以下略)

数えたら、479言語あった

（ちなみに、手で数えたわけじゃないのでｗ
cygwinの wc コマンドです)

この数は、手動で対応したとは思えない。
これ、サポートの必要ないんちゃう？という言語まで
というか、ほとんど、聞いたことのない言語ばかりだし。

何かのライブラリを使っているのかなー。

何故か、D言語や django(PythonのWebフレームワーク)はあるのに、
すでに言語としては古めの Delphi をサポートしていないのが謎。
csは、C#だよね？（拡張子的に）
この辺にヒントがありそうだが……。
（あと、Brainf*ckがないとか、Cecilがないとか、どうでもいいです）

……その後、いろいろ探し回ったら、
発見！！

どうやら、Perlのライブラリ "Text::VimColor" らしい。

何故、わかったかというと、
"VimColor - source code highlight"
というサイトのサポート言語がまったく同じ(ry

でも、これ、裏でエディタの Vim を呼び出しているから、
Vimをインストールしてないと動かないな……。
あと、キャッシュしないと重いだろうし。

手軽に組み込むというわけにはいかないという、オチ。

いやー、『入門Haskell』、『ふつうのHaskellプログラミング(以下、ふつケル)』買いましたよ。
買ったのは、1ヶ月ほど前ですが。
流行には乗っとけってことでね。
いやはや、おいらもミーハーですねー。

とりあえず、『入門Haskell』はともかく(つか、ゴメン読んでないの)、
『ふつケル』の方は、すんごい読みやすいですわー。
プログラムやったことあったら、すいすい読めますね。
練習問題もついててよいです。

説明しときますと、Haskellという、
C言語とか、BasicとかDelphiとかと全く(といっていいのか)
パラダイムが異なるプログラミング言語の話です。

つか、Haskellすげーわ。

遅延評価なんか、なんだよありゃ。
必要になったら、評価する！って考えたなー。
どういう、実装になってるのか気になりすぎる。
学者さんが考えただけはあります。

どうでもいいけど、遅延評価って、量子力学のコペンハーゲン解釈みたい。
観測されてから、過去にさかのぼって、現れるみたいな。
箱を開けてから、ネコの生き死にが判定されるみたいな？

まあ、論理型言語のような匂いがするせいもあってか、
Haskellのような関数型言語パラダイムが
今後の主流になるとはちょっと思えないけれど、
C#が3.0くらいから、関数型言語に向かっているかようではあるので、
考え方は学んでおいてよいと思う。

モナドのところまではまだ読んでないので、この辺で失礼します。
つか、挫折するらしいから、読まないほうがいいかもしれないｗ

面白い言語を見つけました。
『プログラミング言語 スル』。です。

SmallTalkと、Rubyにインスパイアされた.NET向けの言語だそうです。
たぶん、スクリプト言語です。

何が面白いかって、必要最低限の言語仕様と
シンタックスシュガー(構文糖)が全てという点。

SmallTalkのように、if文やwhile文、関数定義すら組み込みじゃない。
しかし、利便性のために、Rubyのような文法で、
シンタックスシュガーにより標準で可能になっています。

シンタックスシュガーって好きなんですよ。
文法的な原則を曲げて、実用的にしようってことですから。
実用的にってのが重要。

作者のblogみると、ソフトの組み込みが目的な様子。

そういえば、実行環境をダウンロードしてみて驚いたのは、
実行環境のコアだと思われるSRUCore.dllが、たった56KByteしかないこと。
びびりました。
ゲームもあったんですが(やねう氏のゲームの移植)、
ちょっと重い。スクリプトだから仕方ないのかな。

どうやら、
boost::shared_ptr + boost::weak_ptr の組み合わせが、
自分がやってたハンドルに近い模様。

shared_ptrは、参照カウンタつきポインタで、
これで(解放の責任のある)所有者を確定。

weak_ptrは、shared_ptrから得るもので、
参照カウンタが0なら(解放されているなら)nullを返すと。
所有者じゃなくて、(解放の責任のない)利用者側はこちらを使う、と。

コード例は、こちらを参照

ちょっと、wikiのプラグイン作成にPHPを弄ってました。

少し触った感触、Perlに似ている。
(変数が $ で始まるとか。文字列の加算が "." だとか)
perl使ったことがあるなら、すぐに使えると思う。

オブジェクト指向も取り入れてはいるけど、なんだか後付な感じ。
どうみてもオブジェクト指向な Ruby を使ってると、
なんだか、中途半端なスクリプトだなー、と思ってしまう。

HTMLにスクリプトを埋め込めるのは、最大の特徴で、
思想的には好きなんだけれど、
ある程度、wikiみたいなそこそこ大きなプロジェクトになると、
HTMLの部分てほんの少しで、意味合いが薄れる。
他のスクリプトで言えば、テンプレートエンジン使えばいいんちゃうん？てなる。
埋め込める利点て、最初（とっかかり）か、小さいプロジェクトしかないと思う。

なんというか、つかっていて楽しいとは思わない（わくわくしない）スクリプト言語なのが残念。
perlと同じく実用言語であることには間違いないんだけどね。

良かった点は、日本語ドキュメントがたくさんあったことかな。
はじめて使ったけど、リファレンスとサンプルでなんとかなった。

あとは、apacheに組み込んで使うので、
スクリプトのパスとか気にしないで動かせるのはいい点かも。

とりあえず、寝る前に例のアレを置いときますね。
GPLなんで取り扱いに注意です。

なんで、お前ソースもってんの？配ってんの？については、
アクアプラスの
『弊社製品のムービー再生にxvid.orgのムービー展開ライブラリを使用していた件について。』
を参照のこと。

つか、誰かsourceforgeにでもアプってくれれば、それで終わりなんですがね。

ビルドはまだ確認してないのであしからず。

ねむいので寝ます。(最近ねすぎ)

結論。
D-Pixedで、出力されたPNGは使うな。

Delphi2006にコンパイラを変えて、GAN GAN GANをコンパイルし直したときのこと。
なぜか起動中、三回目の特定のPNGの画像読み込みで、
読み込みエラーが起きるようになりました。
Delphi6のころや、Delphi2005のころは起きませんでした。

使用しているライブラリは、GLDPNG。
デバッグすると、zlib の Decode で失敗している模様。
そっから先は、zlibの.obj ファイルなのでデバッグ不能で悩んでました。
当初は、他の部分にメモリ系のバグがあるのかと思ってました。

しかし、もしやと思って、PNGファイルを他のソフトで保存しなおすと……。
OK。問題なくいけました。
何じゃそりゃー。

元凶は、D-Pixedで保存されたPNGファイルでした。
いろいろ試しましたが、D-Pixedで保存されたファイルは、
展開できないソフトが多い模様。

危ないから、結局全て、Optpix(懐かしい減色ソフト。いまだに現役)で保存し直し。

しかし、Delphi2006になってバグりだしたのは、結局謎です。
(メモリマネージャが変わった関係？)

卒論で作ってるGB向けサウンドドライバのgbsdrvですが、
今はコンパイラ部(gbsdrvc)を作る作業。

Delphiで途中まで作ってたんですが(字句解析、構文解析までできてた)、
これだとマルチプラットフォームにならないんですよねー。
だもんで、rubyに移植しようかと考え中。

Windows向けなら、exerbでEXE生成すれば、OKだし、
Unixなら、ruby入れてないの？m9（＾Д＾）ﾌﾟｷﾞｬｰ!!ですむし(だめだろ)。

Ruby用のパーザジェネレータであるRaccを使おうとするも、
yaccを使ったことないので挫折。
とりあえず、Raccの解説書を注文してみました。
『Rubyを256倍使うための本 無道編』(すごい名前)

ついでに、ユニット・テスティング・フレームワークのRubyUnitの解説書も注文
『Rubyを256倍使うための本 極道編』(これもすごい名前)

ついでに、rubyのことをもっと知るために、これ一冊ですむらしい、
『プログラミングRuby―達人プログラマーガイド』
も注文。値段タカス！

あー、でもRubyじゃなくて、Delphi使いならFreePascalって手もあるんですな。
FreePascalは、OpenBSDでも動いたかな？(←サーバーで動かす気か)
でも、FreePascalはDelphiに比べ、あまり言語仕様上のウマミがあまりない気がします。
Delphiやってて、あえて新しく使う必要はないかな、ということです。

マルチプラットフォームで言えば、Javaもいいのですが、
やはり、Delphiに比べてウマミがライブラリくらいしかないんですよね。

rubyはその点、Delphiやってる自分には、
新しい機能に満ち溢れているように見えます。

うーーん。
他に、なにかお勧めな言語あったら教えてください。
# どこかから、Adaという声が(ry
# コンパイラ作るならOCamlだろという声も(ry

まとめると、病気のためもあって、
基本的にやる気が出なくて進まないので、
やる気がでそうな課題にしなさい、というわけで、
卒論変更の悪寒（今からかよ

で、候補としては、

• システムトレードの補助ソフトの開発
• ゲームボーイ向けサウンドドライバの開発

とか、そんなんで、卒論なるんかい、という内容ですが、
教授に確認とったところ、なるそうです。
本当にいいんですか。

で、今は、サウンドドライバの開発の方を進めてみてます。
軌道に乗ったら、これで行きます。
参考に、ファミコン用ドライバのmckのソース見てたり、
市販ゲームの解析等(好きなSaGa2あたりを)やってみてます。

しかし、逆アセしての解析は結構疲れます。
現在、何%くらい解析したとか分かるようにしているんですが、
今、サウンドドライバ部は、2%くらい。
気が遠くなってきます……。

卒論なんですが、所属している研究室(西田研)のではなく、
別の研究室(安井研)の要望があり、そちらの研究をすることになりました。

内容は、高速なネットワーク上で動かすアプリケーション(ゲーム)を作るというものです。

高速なネットワークというのは、
光スイッチング技術とやらを使ったものだそうで、
従来のインターネットとは比較にならないほど、
大容量でかつ、レスポンスが高いそうです。
具体的な技術に関しては詳しくないのですが、
電話の交換機のように直接繋ぐ技術だそうで。
(欠点としては、通信前にあらかじめパスを張っておく必要があるらしい)

とりあえずは、既存の物をネットワーク上で動かそう、ということで、
前に作ったGuNMeN -the head smaher-を載せてみる予定です。
というか、教授にゲームのプレゼンとかしたわけですが。
顔を回すのが疲れると、評判でしたｗ(改良の余地あり)

それから、余裕があれば、そのネットワーク上で動かす独自のゲームを作る、
ということになります。
顔！顔！顔！のこともあるし、時間があまり取れません。
また大変になりそうです。

まあ、それ以前に、病気のせいか、
やる気がなくて、こちらは全然進んでません。
むむむ……。

いや、それ以前に卒業単位が(ry

WinCVSがついにメインの開発マシンでも、起動直後に落ちるようになりました。
もうCVSは、つかいたくない……。

最近のプロジェクトは、全てSubversionで新規に作成していますが、
顔！顔！顔！等はCVSのままです。

なんとか移行したいところです。
cvs2svn使えばいいのでしょうか。

待望のTOBYの蒸留塔ですが、
TCC(WAZA)の方で公開してもらいました。

ゲーム風のシミュレーションです。

実験作につき、一面しかありませんが、
好評ならば、いくつか、面を作ってみたいところですね。

というわけで、グラフィックを書き換えてみました。

実写系に、手書き風フォントで。
水粒子は、加算合成でよりそれっぽくなった気がします。

あと、壁との判定を、近似的に。
すこしは、ぬるぬる動いてくれてるかな。

とりあえず、一段落には、もう一日ほど必要かなー。
公開は、後ほどになるかと思います。

いわゆる科学縁日であるダヴィンチ祭が、無事に終わりました。
うちのサークルTCCのブースは、おおむね好評。
来ていった子供たちは、けっこう喜んで、
物理シミュをプレイしていってくれたので、成功でした。

こちらで作った、分留シミュは、かなりウケてました。
大人の方でも、楽しいと言って下さったので、かなり満足。
ていうか、この辺は、元のゲーム(蒸留塔)が面白いからなんですけどね（　´∀｀）

後は、TCCの方で、作ったものをwebに公開していこうということで、公開用のバージョンを作成中。

一番直さなければならないのは、グラフィックかなー。
Ko-Taさんにもコメント欄で突っ込まれましたけれど、
粒子を、加算合成するのはアツイかもしれない。
もうちょっと写実風にするには、そういうエフェクトはほしいところです。

つーわけで、祭りが終わったあともチマチマとプログラム中です。

体に鞭打って、学校に無理やり連れて行ったら、
少し意欲が回復してきたので、そのままの調子で、
分留シミュレータを一段落着くところまで、終わらせました。
つか、ダヴィンチ祭は明日なので……。

壁にはまり込むという問題は、面倒だったので、
「壁にぶつかったら前の座標に戻る」で解決。
って、実は、こうすると、
壁にぶつかると一旦、粒子が停止するので、
変な動きになるんですよね。
もっと、壁にぶつかっても、つつーと滑っていくようにしたい。
ここは、今後の改良しどころ。

その後は、比重の違う(=色の違う)粒子を出してみたり。
比重の違いは、判定用のマップの1つ上を見て、
そこに重い粒子があれば、その粒子と位置交換という形で仮実装。
ものすごいスピードで、粒子が浮き上がりまくりますが、
まあそれはそれで。

後は、粒子の出る蛇口とか、回収口とかをとりつけたりしてました。
これで、ゲームにはなった、じゅなくて、
シミュレータっぽくなったと思うので一段落です。

後は、グラフィックを明日までに何とかしたいところ。
(まあ、そこまでやる気があれば……)

急に調子が悪くなり申した。

昼12時に起きて、
学校行って、飯食って、
学校で寝て、帰って、
飯食って、寝る。

一日、何やってんすか。

昨日は、学校やめる！とかいいだすし。
調子悪い時の自分がよくわかりません。
こういうときに何か言っても、
あまり真に受けないで下さい。

それにしても前に、新しい薬(と言っても、3年位前に飲んでた薬)を
追加してもらって、1ヶ月くらい調子よいと思ったら、
またぐずりだした模様。
どうも、薬になれるとくるっぽいなあ。
なんとかならんかなあ。

参考リンク:
はてな 仕事や人生にやる気がでない時ってありますよね。そういう時はどうしたらいいですかね。

なんとか、水粒子の判定の高速化に成功しました。

手法は、いたって古典的。
領域を格子で区切り、粒子(の四方)の座標を格子に登録、
同じ格子内にある粒子だけを判定する手法です。
知り合いが、昔、PC-98時代にやっていた手法を思い出して、実装してみました。

これだけで、なんと、判定速度は、十分の一近くになりました。
イヤッホー！素晴らしい！！
やっと、実用的速度になりました。

そういえば、はてなに移られたizariuoさんよりトラックバックをいただきました。

砂のページを見せられて、
粒の大きなパーティクルより、小さなパーティクルにしたくなったり、
目移りしまくるのが困り物です。

こちらの反発のアルゴリズムは、例の金子さんのを参考にさせていただきましたので
そちらを見ていただければわかるかと思います。

さて、ようやく、判定速度は解決したのですが、
またもや、問題が……。
なんだか知らんが、粒子がたまに壁にハマる。
ハマって抜け出せなくなる。
困った。
もっと厳密に、壁との判定をしないと……。

うおぅ。ダヴィンチ祭まで、日がねえぇ。

子供達を大学に集めて、科学展示を行うという、ダヴィンチ祭。
自分が所属するサークルTCCの出し物は、物理シミュレーション。

最初は、自然対流でもやろうかと思っていたのですが、
流体と解析学とプログラムが絡んできて、
一週間やそこらでできるものではありませんでした(泣

というわけで、締め切りギリギリですが、
対流から分留に変更。
物理シミュレーションというより、化学シミュレーションですが、まあいいや。

実は、分留は以前からやってみたかったのです。
PC-98時代に、蒸留塔という蒸留ゲームがあったのですが、
それに受けた衝撃がいまでも忘れられないためです。
# 後で調べたら、蒸留塔の作者は、HSPのオニオンソフトウェアでさらに衝撃

昔の蒸留塔は、マップチップで液体をあらわしていましたが、
CPUが有り余っている今に作り直すということで、
パーティクルでやってみてます。

ところがですね、衝突判定が以上に重い！
プロファイルをとると、描画が1msecくらいに対して、
衝突判定だけで、20msec……。
これは、なんとか高速化せなあかんなー。

そんなわけで、しこしこプログラム組んでます。

D言語にDirectXがポートされていると聞いていたので、
使ってみましたが、これ、不完全じゃないすか。

現在のコンパイラだとコンパイル不能という罠。
const DWORD HOGE = 1.0f; とか余裕であるし。
なんとか、castを現在のバージョン用になおしたり、
dig依存をはずしたり、
YTさんのwin32ポーティングに対応させたりしていましたが、
直すだけ直して、途中であきらめました。

うーん、DirectXのまともなポーティングはないんでしょうか……。
# YTさんのコンバートスクリプトにDirect3Dな文字を見て、
# 軽い期待をいだきつつ(ゴニョゴニョ

実を言うと、近日中に、大学のダヴィンチ祭という祭り向けに
作る予定のものがありまして、そっちの方で
なんとかD言語使えないかな、ともくろんでいたのでした。

というわけで、このままでは進まない(というか日がない)ので、
いったんDelphiに戻ります。

え？
SDL + OpenGLがあるって？
それは何か負けをみとめた気が(ry

また、D言語でハマってしまいました(´д｀;)

ウインドウ生成して、フルスクリーンにするという簡単な処理を書きました。
たったこれだけのことなのですが、上手くいかなかったのです。

ウインドウスタイルの変更のための SetWindowLong、
ウインドウを全画面にするための SetWindowPos を並べると
どちらかしか有効にならないという状態でした。
まったく同じコードで、Delphiでは動いていたので、
どういうことかまったく不明でした。

で、3日悩んでようやくひらめいた上での結論。

D言語(のリンカ)の吐く、実行ファイルのPEヘッダのOSのバージョンが古い。

これだけのことでした。
でも、こんなこと、普通気づきません。
昔の2chのD言語のスレッドで、ちらっとPEがどうのこうのという話題が
あったことを思い出して、ようやく気づきました。

とりあえず、PEヘッダを書き換えるソフトを作って、
Makefileに仕込んで置きました。
これで、一件落着(なのかー!!)。

しかし、今後もこういうことがあるのかと思うと先行き不安でなりません。
茨の道を一歩、一歩、踏みしめていく感覚は、
いまどきの言語ではなかなか味わえないとは思いますが……。

念のため、検証用のファイル置いときます。

• ウインドウ生成テスト for Delphi (F4でフルスクリーン化)
• ウインドウ生成テスト for D (同じくF4でフルスクリーン化)
• PEChanger (PE書き換えツール)

後記:
あきらかに同じではないところ(HWND_TOPMOST -> HWND_TOP)がありましたので、修正しますた orz

実際にWin32アプリケーションとして、
ウインドウを出すところから、D言語で書いてみてます。

以下、使ってみての雑感。

return 書き忘れたときに、コンパイルエラーくらいだしてほすぃ。
result だけ定義して return し忘れるとかよくあるし。
Delphi だと Result 初期化してないと、警告が出るので余計に……。

assertしたら、ソースの行番号くらいだしてほしい。
Win32 Exception じゃないっつーの。

関数呼び出し時に括弧 () を書き忘れても、コンパイルが通る時があってハマる。
Delphiのソースを移植してると、余計にミスる。

switch の break と case の書き忘れが怖すぎ。
case 書き忘れると、単なる ラベルになって素通りするみたいだし。
C風 の switch はホント、ガンだと思う。

集合型がないのが意外に不便。
bit配列は、なにか違う。

GUIでのデバッグは無事に、VisualStudio2003 でできた。
ポイントは、コンパイル時にもリンク時にも両方ともに -g をつけること。
片方じゃ駄目(←ハマった)。

あと、クラスのメンバに初期化子を書いても、
初期化されていないことがある。まじか。

自分のマズさを棚に上げておいても、全体的にいまいち感が強い。
まあ、version 1.0 にも達していないのに、文句つけるのもなんだけれども。

あとは、やはり、xyzzy の d-mode がいまいち。
BSキーで、たまに不必要に括弧が削除されたりする。
m_hogeという変数名だと単語選択時に hoge しか選択されないので、mHogeにしてる、とか。
うーん細かいところで、ストレスがたまるなあ。

d-mode を補強しようと xyzzy-lisp をちょっと弄っていたのですが、
lisp は、なかなか刺激的ですね。
なんというか、脳みそコネコネな感じが。
括弧の多いのは、エディタの支援があれば、むしろプラスに働くものですな。

とりあえず、なんとかして、
F9 で、Makefile を探してそのディレクトリで make all と make run を実行、
Ctrl-F9 は、make all のみ、というのを d-mode に実装できました。
これで、少しは、はかどりそう。

あとは、list-function の関数認識を正確にできればよいのだけれども。
今は、extern(C) なんかも引っかかってしまうので。

それと、GExperts よろしく、部分一致検索が
list-function のダイアログでもできれば、かなり使えるんだけれど。
さすがにこれは lisp 弄るくらいだと無理かな……。

しばらく、D言語さわってました。

Delphiとの比較がほしいということで、
D VS Delphiという記事をwikiに書いてみました。
途中で、類似記事を見つけつつ、
落胆しつつも何とか最後まで書いてみました。

感触としては、ほとんどのDelphiの言語仕様をカバーしていて、
これなら素直にコードを書けそうだな、と思いました。
Delphiにない、templateとかmixinは、
ちょっとまだ使いこなせそうにありませんが。

現在のD言語(というかDMDのコンパイラ)のちょっと気になったところ。
どこで Access Violation が出たかわからないこと。
エラーのアドレスくらいほしいなぁ。
コンパイル時に出力される、マップファイルは何のためなんだろ？

他に、ありがちな、
比較(==)と代入(=)を間違えるとか、printfに"\n"入れ忘れるとか、
" と ' を間違えるとかはどうでもよいです。
引数なし関数の後の括弧 () を忘れてもコンパイルが通ること以外は、
たぶんどうでもいいです。

あと、やっぱり、Delphiに決定的に劣る点は、
まあ、仕方がないのですが、
エディタとか開発環境周りでしょう。
xyzzy + d-modeではどうも物足りません。
長い時間コーディングするなら、開発環境のサポートがほしいです。
正直、お金払ってもいいからほしいですねー。
Elephantとか、akIDEに期待したいところです。

とりあえず、もう少し触ってみようと思います。

何とかOCaml使おうと試行錯誤してましたが、断念いたしました。

OCamlSDLをコンパイルしようとして、
SDLやら、lablglやら、SDL_imageやらを入れようとして、
DLL hellならぬコンパイル hellにおちいり、
使う前からイヤになりました orz

どうも自分は、ある程度、環境が用意されてないと
駄目な人間のようです。
というか、そういう人間がマイナー環境使おうというのが間違いなんですけどね。

というわけで、OCamlはまた次の機会に。
つーわけで、次の言語はD言語でいいや、もう(なげやり
# そのうち、Dもライブラリ少ねーとかいいだして、Delphiに戻るに 3000 Borland

最近、マンネリでDelphiに飽きてきたので、
次に使う言語を模索中……。

用途は、ゲーム開発。
# GUIアプリ作る時は、さすがにDelphiでいいです

かっこよさでいうと、OCamlとかHaskellなんだけど、
Windows.h相当とかDirectXのサポートみたいな
必要最低限なものがないようなので、その辺がちょっとキツイ。

やっぱり、実用度を考えると、D言語なんだろうなー。
でも、流行っぽいからなんだかつまんない……。
うーむ。

多関節に個別に当たり判定をつけていたんだけれど、
あまりにも面倒くさいので、
エディタにコリジョン編集機能を付加。

大英断で、1パーツにつき、1矩形にしてしまったけれど、
間に合うかなー。
エディタのインターフェスは、複数判定に対応しているので、
どうしてもという場合は、複数の矩形に対応する方向で。

あとは、実は、エディタで編集はできるけど、
本体のエンジンには判定処理を組み込んでないので、
それをやらないと。

procedure Moge(var Hoge: THoge);
begin
  FreeAndNil(Hoge);
  Hoge := THoge.Create;
  :
end;
 
procedure Xyzzy;
var 
  Hoge: THoge;
begin
  Moge(Hoge);
  :
end;

Xyzzyのローカル変数Hogeが初期化されていない(＝適当な数値)ので、
Moge呼び出し時に、FreeAndNilでどこかのメモリを破壊。
この後、関係のないところでアクセス違反が起きる、という凶悪なコード。

で、正しくは、初期化してやればいいので、こう書く。

procedure Xyzzy;
var 
  Hoge: THoge;
begin
  Hoge := nil;  // ←ここを追加した
  Moge(Hoge);
  :
end;

……コンパイラさん、参照渡しするときにローカル変数を初期化してないっつー、
エラーくらい吐いて下さいよー、だめ？
実は、最初、ちょうど、for-in-do周りでアクセス違反が起きたから、

　ま　た　、　f o r - i n - d o　か　！

とか、思ったので、もうマジで頼む。

この際、Moge自体がアレ(つまり、オイラ自身が(げふんげふん))だということは棚に上げます。
コンパイラができることは、できるだけ、コンパイラがやるべきだと思うので。

そういえば、JAVAだと、そもそも副作用が怖いのか、
参照渡し(Delphiのvar引数)がないんだよねー。
そういう割り切り方もありだと思う。

固定小数点の罠

var MinValue: TFixed;

MinValue := Double2Fixed(Low(Integer));

これで、MinValue が適当に最小値になると思いきや……。

Double2Fixedの実装が、

function Double2Fixed(const Value: Double): TFixed;
begin
  Result.Value := Round(Value * 65536);
end;

Value * 65536 ……

Ｖａｌｕｅ * ６ ５ ５ ３ ６ ・ ・ ・ ・ ・ ・

Ｖ　ａ　ｌ　ｕ　ｅ　＊　６　５　５　３　６　・　・　・　・　・　・
(もういい)

Round(Low(Integer) * 65536) = 明らかにアンダーフローなわけですね。

もう固定小数点(古い遺産)いやだー。
浮動小数点に全書き換えしようかな……。

※このバグは、Delphi2006では修正済みのようです

腹が立ったので、その後、調査してました。
再起動しまくりながら、ようやく、
バグらせる最小限のコードを見出せました。

肝は、Enumeratorのコード。
下記にバグらせるコード出しときます。

TTestEnumerator = class
private
  FCurrentItem: Integer;
public
  constructor Create(list: TTest);
  function MoveNext: Boolean;
  property Current: Integer read FCurrentItem;
end;

↓だとOK。

TTestEnumerator = class
public
  function GetCurrent: Integer;
  constructor Create(list: TTest);
  function MoveNext: Boolean;
  property Current: Integer read GetCurrent;
end;

こんだけかよ！

こんだけです。
ヘルプには、

GetEnumerator() が返すクラス，インターフェース，レコードには Current というパブリックインスタンス読み出し専用プロパティが含まれている必要があります。Current プロパティの型は，コレクションに含まれる型である必要があります。

とあるので、仕様的には、propertyに関数じゃなくて、
フィールドを入れても問題ないはず。
とりあえず、回避策はわかったのでよしとします。
ちなみに、入力不能になるのは、何故か、
for-in-do呼び出し側が「書込み禁止」になるからです。謎。

Delphi2005の新機能 for-in-do。
使ってなかったけど、これってすんごい便利じゃないのだろうか。

前は、

for i := Low(ArrayData) to High(ArrayData) do 
  Writeln(ArrayData[i]);

とかやってたけど、

for i in ArrayData do 
  Writeln(i);

で、いいのか！
他の言語で言えば、foreach構文ですな。

自分で作ったクラスにも特定のメソッドを追加すれば、for-in-do対応にできるし、
こりゃ、地味に便利だ。
ていうか、今頃気づくなっつーの。

この調子で次期バージョンに新機能をバンバン追加してくれたら、
他の言語に目移りしないですむのになー。
(なんか、最近、C#とかD言語に誘惑されまくり)
次は、無名関数くれくれ。

とりあえずは、自前コンテナクラスを for-in-do 対応にしとこう。

……と思ったら！
自前のクラスだと、IDEでアクセス違反がでて、
コンパイルすらできないじゃないか！！
(2つの環境で確認。.NET切り離した環境だと、エディタに入力すらできなくなって再起動必須)
どないせいちゅーんじゃー。

今日は、3面の背景周りの話し合い他。

プログラムの方は、アニメーションデータのバイナリ化を。
普段は利便性の高いXMLを編集しつつ、
実行時に、日付が新しかったらバイナリに変換。
実際のデータは読み込みは、バイナリから読むように。
これで、アニメーションデータが増えても、高速で読みこめる。
XMLだと、このままデータを増やし続けた場合、秒単位で遅くなるところだった。

この辺の新しかったら更新みたいな処理は、他にも応用が効きそうなので、
共通部分はクラスにしてライブラリ化しておいた。

ここ何日間はXML読み書き周りの整理。

OpenXML for Delphi用の簡単にXMLを扱うクラスを作ってみた。
こんな風に使える。

書き込み例:

<moge>
  <hage>1234</hage>
  <hoge>ha-ge</hoge>
  <hoge>True</hoge>
</moge>

上記データを書き込む場合。

uses O3EasyXMLUnit;
:
XML := TO3EasyXMLWriter;
try
  XML.BeginElement('moge');
  try
    XML.Write('hage', 1234);
    XML.Write('hoge, 'ha-ge');'
    XML.Write('hoge, True);
  finally
    XML.EndElement;
  end;
   XML.WriteToFile('hoge.xml');
finally
  FreeAndNil(XML)
end;

読み込み例:

<moge>
  <hage>1234</hage>
  <hoge>ha-ge</hoge>
  <hoge>xyzzy</hoge>
</moge>

上記データを読み込む場合。

uses D3UtilsUnit;
  
procedure THoge.FogeMoge;
var XML: TO3EasyXMLReader;
  
  procedure DoEnumFunction(const index: Integer); cdecl;
  begin
    FList.Add(XML.Read());
  end;
begin
  XML := TO3EasyXMLReader;
  try
    XML.LoadFromFile('hoge.xml');
    XML.BeginElement('moge');
  
    try
      IntValue := XML.Read('hage');
      Enum('hoge', TDoEnumFunction(@DoEnumFunction), D3GetContext);
    finally
      XML.EndElement;
    end;
  finally
    FreeAndNil(XML);
  end;
end;

Enumら辺は高階関数を利用。
気持ち悪い人用に、一応、メソッドポインタもサポート。
普通の関数呼び出しもできるので、宣言が面倒なメソッドポインタはサポートしない方向で。

サポートは、例のごとくwikiの方で。

開発中のデータの変更に柔軟に対応するために、
多関節アニメーション用のデータフォーマットにXMLを採用しているのだが、
これの読み込みがすこぶる遅い。
そこだけで、数秒掛かる。

なんとか高速化できないかと、検索してみると、バイナリXMLなんてのが策定中っぽい。
さすがに、Delphiでの実装はないみたい。
まーとりあえずは、XMLからストリームへの吐き出し時に
バイナリ化してみるかな。

Flashをちょっと触って思ったこと。
このオブジェクト指向(厳密にはプロトタイプ指向)をGUIで操る感覚は、
依然触った豆乳システムに近い。

双方の共通点を見ると、
なんだか、ゲームを作るツールみたいなもの形が見えてくる気がする……。

これらは、2Dゲームに向いているが、
3D対応にしたらどうなるんだろうか。
洋ゲーのゲームエンジンみたいになるんだろうか？
想像が膨らむ。

オレ流Flashゲーム作成術―実践ActionScriptゲームテクニック

posted with amazlet at 05.04.15

ババラ
技術評論社 (2005/03)
売り上げランキング: 12,010
通常24時間以内に発送

Amazon.co.jp で詳細を見る

ちょっとFlashをさわるかもしれないので、
一部で評判の『オレ流Flashゲーム作成術』を購入してみた。

Flash的にはどうかわからないけど、
ゲームに必須な『状態遷移』から入っていることが重要かな。
後は、ムービークリップを用いた『タスク処理』が必見。
この2つをマスターすれば、基本的なゲームは作れるはず。
この著者(というか、ババラさんなんだけど)、わかってるなー。

あとなにがすごいって、
これ、読んだとおりやるとゲームが作れてしまうこと。
Basicマガジン感覚でいいね。

ちょっと誤植なのか、ミスっぽいところもあるけれど、
それらを差し引いても良い本だ。

バトルガレッガのマゾゲーっぽさとC++の複雑さの類似性の話。

自分の場合、
Effective C++や、Modern C++ Designやら、
More Effective C++やらを読まないと、
まともに使えない言語というイメージが強かった。

そうか、シューティングを普通に遊ぶように、
普通にC言語の延長で使えばいいのか！
って、C言語もキライなんだが(どうしたら

参考リンク: C++はなぜ人気がないのか

BrainFu*kの亜種、NekoMimiF*ckの実装が公開されている。
# BrainF*ckは、いわゆる難解(変態)言語の一つ
# 詳細はこちら@google

以下、HelloWorldの引用

おにいさまおにいさまおにいさまおにいさまキスキス…ネコミミ！おにいさまおにいさま
おにいさまおにいさまキスキス…ネコミミ！おにいさまおにいさまおにいさまおにいさま
ネコミミ！おにいさまおにいさまおにいさまおにいさまおにいさまおにいさまネコミミ！
おにいさまおにいさまネコミミモードネコミミモードネコミミモード私のしもべー
キス…したくなっちゃった…ネコミミ！おにいさまおにいさまネコミミ！おにいさま
ネコミミモードネコミミモードネコミミモード私のしもべーキス…したくなっちゃった…
ネコミミ！ネコミミ！や・く・そ・く・よネコミミ！おにいさまや・く・そ・く・よ
おにいさまおにいさまおにいさまおにいさまおにいさまおにいさまおにいさま
や・く・そ・く・よや・く・そ・く・よおにいさまおにいさまおにいさまや・く・そ・く・よ
ネコミミ！や・く・そ・く・よネコミミモードネコミミモード私のしもべーネコミミモード
おにいさまおにいさまおにいさまおにいさまキスキス…ネコミミ！おにいさまおにいさま
おにいさまおにいさまネコミミモード私のしもべーキス…したくなっちゃった…ネコミミ！
や・く・そ・く・よネコミミ！や・く・そ・く・よおにいさまおにいさまおにいさま
や・く・そ・く・よ私のしもべー私のしもべー私のしもべー私のしもべー私のしもべー
私のしもべーや・く・そ・く・よ私のしもべー私のしもべー私のしもべー私のしもべー
私のしもべー私のしもべー私のしもべー私のしもべーや・く・そ・く・よネコミミ！
おにいさまや・く・そ・く・よ

ワロタ。
違う意味でFu*kされてる気がする。

つーか、配布されているソース使ってなんでも亜種つくれそうだ。

GameBoyのPocket Cameraのセーブデータから、
画像を取り出すソフトが出来た！

それ以前に、Pocket Cameraって何よって人はこちらを参照のこと。

大分前から、画像を取り出すくらいの解析は行っていたのだけれど、
ソフトを作るのが遅れ遅れになっていた。

とりあえず、ためしに付属のセーブデータ test.sav を
ウインドウにドラッグアンドドロップしてみれば、
どんな感じかわかってもらえるはず。

保存形式は、png、gif、jpeg、bmpに対応しとりまふ。

Delphi2005 for win32 で初完成ソフトがこれかよ！
しかも、まあ、はっきり言って需要はほぼ自分のみ、のソフトなわけだが。

何かあったら、例のごとくwikiに書いていくのでよろしく。

今頃かよ！って感じだけど、
「顔!顔!顔!」にようやくヒットフラッシュを実装。
敵にダメージを与えた時に光るアレです。

ヒットした感触が伝わるので、実装前と天と地の差がある。
やっと普通のゲームになった。

でもこれ、塗りつぶし画像用意しているだけだから、VRAMをやたら喰う……。
まあ今の時代、VRAM 32MBytesくらい要求しても別にいいよね？

大学のプアマシン(Cerelon 1.2GHz, 512MB)にインストールしたら、
インストールだけで4時間かかった。
起動には4分。

さらにいざプログラム組もうとすると、エディタが張り付く。
property と入力しようとして、
pを入れた瞬間に1分待たされ、
proの時点で1分待たされ、
propで1分待たされ、
proprと間違えて入力してBS押すと1分待たされ
(以下略)

もうだめぽ。
タスクマネージャで見たらメモリ400MB以上食ってるし……。

　　　 マシンを買い換える
にア　Delphi6にもどす

というわけで、しばらくはDelphi6(学校)と2005(家)の両方を使うことになりそう。

と、思っていたら、YT先生が.NETパッケージをはずしたり、つけたりするツールを作ってくださいました。

やったー、起動4分が、3分30秒になったよー(←ここ、＿|￣|○するところ)
で、実は、エディタの張り付きがなくなり、
Delphi6使わなくてもよくなったという。
よしよし。

あと、感想の追加。

良い点追加。

• IDEのアイコンがアレキサンダー(?)


• 地味に、エディタの色設定で自由に色が変更可能
  前は、限られた色だけだった


• オープン配列を持つ関数の引数内で、コード補間が効く

悪い点追加。

• Ctrl+F12のユニットの表示が改悪された
  例えば、普通の.pasファイルは選択できるが、
  テキストファイルのようなものは候補に入らず選択できない


• フリーカーソルなのだが、動作が変。
  日本語が入った行で、行末以降にカーソルを持って行き、
  上下移動するとカーソルが左右にぶれる


• 家の環境で、2005インストール当初Delphi6が起動しなくなったいた
  今はなんとか大丈夫。何故、起動するようになったかは謎。


• やっぱりたまにコード補間が効かなくなる

全体的にVisualStudioっぽくなっている。
コンポーネントパレットはなくなっているし。

しかし、どうももっさりしている。
まず、前にも書いたが、起動が遅い。
ページを切り替えるたびに数秒待たされる。
コードを入力するたびに、数秒またされる。
リファクタリングの前準備に、スワップ→数分経過とか……。

これは、明らかにスペックが足りていない。
使用メモリは、余裕で250MBytes近くいく。
足りないのはメモリー容量(ギガは欲しい……)と、後はHDDの速度だなー。
メモリー増設決定じゃー。

いい所

• リファクタリング機能が便利


• ヘルプが新型になっている(.hlpじゃない)


• Win32も.NETでも開発できる


• さらに、C#で開発できる(!)


• 地味にショートカットがしっかり割り当ててあって、拡張ツールのGExpertsでほとんど再割り当てしなくてすむ。
  「全保存」や「再構築」、「ファイルの検索」とか。


• デバッグなしで実行できるモードがある。
  今までは、デバッグオプションで一々切り替えていた。
  Ctrl+Shift+Dに表示を割り当ててはいたが。

不満点

• メモリを食いすぎ


• 簡単にコンポーネントを追加できない

パッケージ作ってからやるしかない？

• バージョン管理は自前でやるから、中途半端なヒストリ機能などいらない。
  つか、.historyフォルダ勝手に作るのウザイ。


• エラー箇所をエディタ上で表示するErrorInsightは、誤爆しすぎて全く使えない


• Undoが Ctrl+Z を2回押さないと働かない時がある


• 同様に、Redoが効いたり効かなくなったり


• ヘルプに若干不備がある
  ていうか、キーボードショートカット見ようとしたらいきなり見れねえし


• genericまだぁ？


• 関数内関数のポインタはいつになったら利用できるのか？もっと楽にlambdaりたい。

で、パッチはいつでる？(ぉぃ

開発中のゲーム「顔!顔!顔!」のコンパイルは、
最初、通らなくてひどくあせった。
単に引数のカンマが抜けていただけだったが、
コンパイルドユニットのせいで
たまたま以前の環境ではエラーをすり抜けていたと言うオチ。
# 再構築すると発覚するわけ

さあ！待望のDelphi2005が到着いたしました！！

何故か、シンガポールより国際郵便にて直送であります。
海外で作った方が安上がるからでありますか。
徹底したコスト削減でありますね。

どうでもいいけど、郵便の名前がものすごい出鱈目であります。
いや、珍しい名前だから慣れてはいますが、これはちょっと。

さて、いよいよ開封した後、まずはパッケージにプチ感動。
カッコイイ！
折りたたみ式の内装も生かす！

で、いよいよ、インストール！

そして、ファーストインプレッション。

　起　動　が　遅　い　…　…　。

Delphi6と比べ、当社比、2倍。
# 2.6GHz, 512MBで約1分
起動しておいて、裏でネットうろついて、気が付いたら起動。

もうこれだけで、ご飯、3杯食えるくらい。

そうそう、いきなりイースターエッグ発見、バージョン情報ダイアログで、
ALT押しながら、TEAMと入力すると……。
くだらね。いや別にやらんでいい。

肝心の新しくなったIDE、新機能等は、
おって報告いたす。

実は自分は、大のヘジルスバーグファンである。
え？誰かって？
では簡単に説明しよう。

アンダース・ヘジルスバーグ(Anders Hejlsberg)とは、
Borland TurboPascalの開発者であり、Delphiの生みの親。
Delphi for Javaを設計するも世には出なかった。
1996年にBorladをやめ、MSに引き抜かれ、VJ++を設計。
その後、今流行のC#を設計した。
Borlandを離れた今でも、根強い信者が少なくない人である。
ちなみに、MSからの報酬として300万$(約3億3千万円)のボーナスをもらったという。
# 流行のストックオプションというやつらしい

写真は、Delphi1のバージョン情報表示から見られる写真である。

標準化などいざしらず、独自仕様万歳主義、実用優先主義は、
自分も影響を受けていないとはいえない(ホントかよ)。

そうそう、C#はよくJavaのパクりだ、と言われるがそうじゃない。
彼の経歴を見るに、Delphi + J++ なのだ。

『スモールコンパイラの制作で学ぶプログラムのしくみ』を読み始めた。

コンパイラの本で有名な中田育男氏監修のコンパイラ本。
対象としては、

• コンパイラの本は読んだが、難しくてよくわからなかった
• インタプリンタ等の実装はソースを読んでいて、 実装はある程度わかるが、理論がよくわかっていない
• もちろん理論だけじゃなくて、実装もカバーしてほしい
• 綾たん(著者)ハァハァ

という、すんごい自分向けの本（　´∀｀）

人によっては、ちょっと多用される例えがつっかかるかも。
例えばこんなの。

次にコン・パイラ君がaのリンゴをマシンに入れると、また状態3に遷移しました.さらにmのリンゴと入れていきますが、英数字以外を読むまでここで遷移し続けます.eのリンゴの次にスペースのリンゴを入れると(以下略)

例えはともかく、説明はわかりやすいんでまあ問題はないけれど。
内容はやさしいし、コンパイラ本としては異様に値段も安いし、
初学者にはお勧めなんじゃないかな。

ところで、どうやら作者は文系の人らしい。
前書きによると、1年でコンパイラ作るところまで来たというからスゴイ話だ。
この頑張りはみならいたい。

一部で有名な乱数生成手法のMersenne Twister、
Delphi版実装できたよ！

クラス化したものとサンプル、置いときます。

詳しくはwikiの方で。

今回は、映画上映会とミニゲーム展示。
それにしても人来ません。
# そもそもだな、大学祭だというのに、
# 展示がうちの部(TCC)だけというのはどういうことだ!!
# やる気あんのかゴラァ!!

映画の上映会は、新作が間に合わなかったので、過去作品上映会。
内容が濃いためか、おじいちゃんが途中で出て行ったりしたらしい。

ミニゲームは、新作3作品を展示。
自分がプログラム担当のパズルアクション?「l-gauge」、
M.I.G.氏プログラム担当のアミダRTS?「War of bridge」、
yama氏オーサリング(Flashゲーなので)担当アクションシューティング「(名前失念)」。
なんで、プログラム担当とか書いてるかと言うと、
ほとんどのディレクションとグラフィック、BGMにacshow氏が絡んでるから(笑)
詳細はソフトが公開されてから紹介することにする。

自作の「l-gauge」の方の技術情報だけは書いておくと、
Delphi + OpenGL + DirectDraw(画面最大化だけ) + DirectSound + XML + BulletMLって感じ。
効果音はParagon 5 Trackerで、BGMはnanoloop(acshow氏作曲)で製作のChipTune風味。

とりあえず展示物はよかっただけに、人がこないのは残念。
宣伝とかもっとすべきだと思うんだけどなー。

今、がくさい(←なぜか変換できない)用のミニゲーを作っています。
それにBulletMLを使おうと思ったので、
Delphi用にlibBulletMLのヘッダーをコンバートしました。
コンバートしたヘッダーはこれです。
なお、派手なサンプルも一応用意しました。
# サンプルはほとんどABAさんのTSUMIKI Fightersからの流用なり

ちなみに、BulletMLはABAさんが提唱されている弾幕記述言語です。

詳しくはwikiの方に書いておきます。

Psycleのソースより。

function ToInt(const aValue: Single): Integer;
const
  d2i: Double = 1.5 * (1 shl 26) * (1 shl 26);
begin
  res := aValue + d2i;
  Result := PInteger(@res)^;
end;
  
var
  i: Integer;
begin
  for i := 0 to 20 do begin
    Writeln(
      Format('%f, %d', [i / 10, ToInt(i / 10)]))
  end;
end.

出力結果

0.00, 0
0.10, 0
0.20, 0
0.30, 0
0.40, 0
0.50, 0
0.60, 1
0.70, 1
0.80, 1
0.90, 1
1.00, 1
1.10, 1
1.20, 1
1.30, 1
1.40, 1
1.50, 2
1.60, 2
1.70, 2
1.80, 2
1.90, 2
2.00, 2

ポインタ使うところがアツイ。
0.50が0になったり結構適当だけどこれは使える。

追記。
0.50が0になるは、Bankers Rounding(IEEE 754(浮動小数点表現)のデフォルトの丸めモード)に沿ってるっつーことで正しいのだ。

開発中のシューティングゲーム「顔！顔！顔！」の開発経過も定期的に書いていきます。

ようやく3面ボス出現の演出が終わりそう。
要塞大爆発→ボス出現の流れ。
爆発にやたらてこずりました。
加算合成使えれば楽なんだろうな、と思う今日日頃。
# 今回のウリは、加算やαブレンド、さらには拡大縮小を使わないことなので(マジで)

そういえば、コミックマーケット67に参加の応募をしました。
あまり日がありません！
正直、後、3ヶ月で終わるんだろうか。ウヒョー！！
頑張ります。