DELPHIER

日本の方が作られているソフトウェアに、単語を抽出できるソフトウェアがあります。
MeCab、ChaSen、kakasiなどです。

これを使えば、Webページに含まれている単語を列挙することができそうです。
単語を列挙すれば、頻度、総単語数が分かります。
・・・思いつきませんが、いろいろと面白い使い方が出来るんじゃないか、と考えています。
[続きを読む．．]

一年も時間が空きましたが、再考してみます。
前回はFlash中心で考えてましたが、もうそれは忘れます。

まずは、ゲーム中で行うアクションの書き出し。

[続きを読む．．]

Flashでパースつき無限平面、パースなしテクスチャマッピングが出来る、
ということは、実物を見て知っていたのですが、サンプルなどを見て
確実に実装できるという確信を持ったので、取り組んでいきます。

参考になるページを列挙しておきます。

■国内
vas animation
Flashで興味深い実験をいろいろとなされています。
実際に動くものを公開されており、参考になるリンクも多いです。

■海外
実際に動くもの
マリオカート的なサンプル。
http://www.nlc.net.au/~oceana/games/rc.htm
http://www.nlc.net.au/~oceana/games/rc.zip
ソースつきの無限平面サンプル。

3d texture mapper and OOP engine
テクスチャマッピングのサンプル。ただし、テクスチャの形が正三角形で作られていたため、
四角形のテクスチャを張るためなら即戦力にはならない。

3D rotating cube (large version with pictures as texture)
こちらは四角形テクスチャマッピングが簡単。
画像を変えるだけですぐに使える。

Flash kit
上記のような参考になるものが数多く集まっている。
[続きを読む．．]

なんか新しいゲームが作りたいので考えていたら、
スケボーのチックタックでレースをするものを作ろう！と思いました。
というわけで、チックタックでなぜスケボーが進むのかをまず考えてみました。

チックタックは、スケボーに体重をのせて
軸足を固定し、左右に振るという、
なんとも不思議な運動によって前に進みます。
まず、どうやって力が発生していくかを追ってみます。

1.軸足を固定し、ボードを少し浮かせて回転させる
　ここでトルクが発生している？
2.適当に回転させたボードを地面に着ける
3.1の動作を反対方向に行う
4.2を行う
5.これを繰り返す

1と3でトルクを発生された覚えはあるのですが、
それが前に進む力にどうやってなるかがわからない・・・。
でも、回転の力が前に進む力に変換されているのは確かです。
ということは、トルクと力の関係を思い出せば、わかりそうです。
トルクと力の関係に確かこんな関係があります。

トルクをτ、位置ベクトルをｒ、力をFとすると、

τ ＝ ｒ × Ｆ

なんとか、トルクから力を求めることができそうです。
力がもとまれば、物理の偉大な公式「F=ma」で加速度が求まり、
加速度から速度が求まり、位置が決定できます。

じゃぁトルクは何かっていうと、角運動量と関係があります。
ちなみに角運動量Ｌは、角速度ωと関係があります。
慣性モーメントをＩとすると、

Ｌ ＝ Ｉ・dω/dt

角運動量とトルクの関係は次式で表されます。

τ ＝ dL/dt

ここまでをまとめると、

Ｉ・d/dt・（dω/dt）=ｒ ×Ｆ

になるのかな？
目的は、回転の力がどうやって前に進む力になるかでした。
なので、ゴールは力を求めるということです。
上式を展開すると、三つの連立方程式に未知数が三つなので、
方程式を解くことができます。
そして、力Ｆが求まります。

あとは、F=maに従い、スケボーの質量を代入してやればＯＫですね。
わかりきっていたことですが、
体重ができるだけ軽い人で、強い回転力を生める人が
高速チックタックレースを制することになりそうです。

今日はこんなところで。
[続きを読む．．]

給料、というか「何かをしてお金を得る」とはどういうことなんだろう。

僕も今、給料をもらっています。
給料は安いですが、不自由なく一人暮らししていける分はもらっています。
おそらくこれは、労働基準法とか最低賃金法あたりで定められているのでしょう。

給料がどうやって決定されるかは知りませんが、
単純に考えると、

（給料）=（その人があげた利益）-（会社への所属料金）

みたいな感じになると思います。
会社への所属料金というのは、会社に働ける環境を提供してもらってるので、
払わないといけません。

もし、一人で働ける環境を用意して、仕事もとってこれる、
というのであれば、会社に属する必要はないでしょう。
それがSOHOとかでやってるフリーのプログラマとかになるんだと思います。

[続きを読む．．]

なぁんだ、コマンド判定ってもっと簡単にできるのかよ・・・。
コマンド判定とは何か？
キー入力の状態遷移を見て、それを登録されたコマンドに該当するかをチェックし、
「これならこのコマンドだ」と判定を下すことです。
正規表現を使うことで、すごく簡単にできる、ってことに気がつきました。
キー入力をLIFOで記憶していき、それを正規表現でマッチさせる、そんだけ。
[続きを読む．．]

キーワード： 燃焼 発火 炎 火

---

考えれば考えるほどに，リアルな炎を得るためには，ものが燃える仕組みを知らなければならないと思います．
というわけで，少し調べてみました．僕は化学が超がつくほど苦手ですが，
量子力学とかを見てると，化学も物理的に見れるようになってきたので，少々親しみを覚えた，ってこともあります．
「発火」というキーワードでググると，「人体発火」ってのが多くひっかかるので，びびりましたｗ

• 燃焼の化学


• 熱化学

うーん，勉強になりますね．しかし，仕組みがわかりやすく説明されていますが，
具体的な式などがないのがちょっと．エネルギー，波長，色・・・波長と色は関係があります．
波長とエネルギーも関係があります．ということで，発熱現象から色を決定できるはずです．
さて，どうやればいいのだろうか・・・．

まとめ．

1. 化学反応の前後では発熱・吸熱がおこる


2. 熱化学方程式で表される熱量は，1molあたりの熱量である


3. 燃焼とは，酸素と反応することである

ここで，いくつか疑問があります．
炎が見える，ということは，燃焼している物質から炎の色に応じた光が出ているということだと思いますが，

• この光の波長はどのように決定されるのか？


• どの物質が光を発しているのか？

ということです．

まず，一つ目の疑問については，エネルギーと光の振動数の関係式から，光の波長を決定できそうです．
エネルギーと光の振動数には，次のような関係があります．

E がエネルギー，h(=6.62608×10 -34 J･s)がプランク定数，νが振動数です．
また，光の波長，振動数，速度には次のような関係があります．


λが波長，c (= 3 × 10^8)が光の速度です．これを常識に代入して，光の波長を求めると，


となります．

ためしに，

という反応を考えて見ます．
これで波長を求めてみたら，929.6 × 10^-33[m]というありえない波長が出ました・・・．
波長が小さすぎて，可視光にもなりません・・・．そんなはずはない．
と思ったら，ここでのエネルギーの単位は[J]じゃなくて，[J/mol]のようです．
つまり，さっき求めた値の単位は[m･mol]という何を表しているのやらさっぱりな単位なわけです．
そこで，これにアボガドロ定数( = 6.02 × 10^23[1/mol])をかけてみると，
めでたく単位が[m]になり，波長は560[nm]くらいになりました．
多分，これは一つ一つの原子が放つ波です．
この波長だと色は黄緑ですね．ようやく可視光の世界突入です，
ちなみに可視光は400[nm] 〜 800[nm]くらいです．

これで燃焼させる物質から炎の色を求めることができそうですが，
ほとんどの物質では炎の色が既知ですし，そういえば
僕が求めていたのは，「炎の形状」がどうやって決定されるかだった・・・．
まぁ，微妙に勉強になったからいいんですけど・・・．はぁ．
形状ってどうやって決まるんだろうか？（続くかも）

キーワード： アルゴリズム データ構造 ソート Merge Insertion

---

眠気も吹っ飛ぶような感動を授業で受けたのは久々ですね．

「ソート」，並び替えは，プログラマなら使ったことがあるアルゴリズムのひとつだと思います．

I think 'sorting' is one of algorithms that programmers had used.

僕がソートに出会ったのはナグールを作っていたときで，「プログラムでデータを並び替える」

という感覚がなかったころ，「キャラクタを奥から順番に描くにはどうすればいいんですか？」と

先輩に逆引き検索をかけたところ（ぉ，「選択ソート」を教えてもらいました．

（ちなみにしばらくはこれをバブルソートだと思ってました）

それが僕のソートとの出会いです（ってなんか変な文章になってきた・・・

ソートには，バブルソート，選択ソート，挿入ソート，マージソート，シェルソート，

クイックソート，ヒープソート，基数ソート，など数多くのアルゴリズムが存在します．

使う側の立場としては「どれが一番効率いいか」とか「組み込みやすいか」とか，

いろいろと気になります．僕なんかは「どれが一番速いか」に重点を置いています．

余談ですが，SQLなどではソートは「手段」として用意されているため，

使う側はアルゴリズムがどうだとかを気にしなくても済んでしまいます．

SQLが最適なアルゴリズムを選んでくれていればいいですが，

内部の仕組みをしらずに何十万，何百万・・・というデータ（しかも重要なデータ）を

並び替えるのは考えるだけでも恐ろしいですね・・・．

ソートが簡単にできる，複雑なアルゴリズムを知らなくてもそれなりにソートできる，

というのはメリットでもあるわけですが・・・．

話を戻します．

このように，僕たちはいろいろな観点からアルゴリズムを性能評価しますが，

ソートにおいては，特に比較回数が性能評価の基準として重要視されます．

クイックソートがよく使われるのは，バブルソートや挿入ソートに比べて比較回数が少ないからです．

（そんだけじゃないけど）

並べ替え方にもいろいろあるので，比較回数を減らせば速くなるというわけではありません．

んで，そんなことは気にせずに，比較回数をとにかく小さくしたアルゴリズムが今回紹介する

Merge Insertionというやつです．

あぁ，やっとここまでいえた．

ソートの比較回数の限界は，要素がn個の場合，log2(n!)を切り上げた値になるそうです．

証明は，WEBで伝えるのには限界があります（というか僕の理解力に問題があります）．

このMerge Insertionは比較回数がこの値にかなり近く，

現在のアルゴリズムでは比較回数最小を誇るアルゴリズムらしいです．

簡単にググってみましたが，日本語ページは見つからなかったので説得力がないかもしれません．

なんか書いてるうちに興奮が冷めてきた感じがありますが，後には引けないので続けます，

このアルゴリズムは・・・WEBで伝えるのには限界がありますｗ

仕方ないので，授業でとったノートをアップします．

しかし，授業でとったノートを，WEB上で公開してもいいのかという疑問が浮かんだのでいったん保留です．

教科書などの文献は全てWEB上で公開してしまえばいいのに・・・．

それにしても，xyzzy，いまさらながらいいですね．

最近までメインでEmEditor v3，日記にJmEditor，その他にもTeraPad，

秀丸，gvimなどいろいろ使いましたが，これが一番しっくりきます．

起動が抜群に遅いのが難点ですが，高機能なので仕方ないのかのしれませんね．

それでは，また・・・．

キーワード：マップエディタ ハイトマップ
やっぱり，ゲームを作るには必要な気もします．
2Dマップエディタもそろそろ飽きてきたので（改良の余地はありすぎますが）， 思い切って3Dマップエディタを考えます．
[続きを読む．．]

キーワード：Metasequoia Mikoto DelMiko ボーン IK 3D

Opera起動はえー！

Delphi + Quadruple D にはついに，3Dモーションを簡単に再生することができるようになるんですね・・・．

これで，2Dゲームで起こりがちな「モーションの増加によるテクスチャ（容量）の爆発」を防ぐことができます．

キャラクタをワンスキンモデルで用意して，それにモーションを与える，という感じで．

そこで，アクションゲームにおけるモーションの動的変化とめりこみ，とかについて考えてみました．

歩く，走る，飛ぶ・・・殴るけ，蹴るなどのモーションの再生は，Ko-Ta氏が開発中に「DelMiko」でなんとかなりそうです．

しかし，「高さが変化する地表にあわせて歩く」となると，とたんに難しくなります．

地表の法線によって歩かせるとおかしいので，「地表全体」の法線と体の頭の向きをあわせて歩かせないといけませんが，

モーションを再生するだけだと，ここで地表への「めりこみ」が発生してしまいます．

普通人間は，坂道を歩いたりするときは坂道に足が合うように足を動かします（変な日本語です）．

これをどうしようか？ということが今回のテーマです．

他のプログラムでどう実装されているかとかは見てないんで，変なことをいうと思いますが，突っ走ります．

---

2003/05/21 炎

キーワード：炎 火 パーティクル 物理 重力 浮力 クーロン力

突発的に，何かひらめくことがあるよなぁ，授業中って．

「昔わからなかったけど，今みてみると分かる」的なひらめき．

昔から「きれいな炎をプログラムで作る」というのは僕の永遠のテーマ（大げさだし言いすぎ）だけど，

今日また少し思いついたので，日記にそれを残しておこう．

まず，現在僕が作ることのできる炎で何が不満かというと，メラメラ，パチパチ感がないということだ．

なんかモワーって感じ．

これだとどうもやる気がないように見えてしまうので，なんとかしたいというのがコンセプト．

今日思いついたのは，炎をパーティクルで作るものだけど，

そのパーティクルの動かし方，パーティクル同士の影響を，

物理的なアプローチからシミュレートしてみましょう．

炎を織り成すパーティクルの基本的を性質を次のように勝手に定義して，やってみる（正しいかどうかは不明）．

1. パーティクルは空気の浮力によって上に上がっていく
   
2. 重力を受けるけど，質量が小さいので浮力の方が大きい
   
3. 酸素が多いところにいく
   
4. 風による影響を受けやすい（質量が小さいから）
   
5. そのうち燃え尽きてなくなる
   

これらの性質から，パーティクルが受ける力を求めて，そこから位置をはじきだします．

問題なのが，3番目の「酸素が多いところにいく」ということですが，

これは逆に「パーティクルがあることころは酸素が薄くなってるはずだから，近づかない」と考え，

もう思い切って「パーティクル同士は互いの距離に反比例して反発しあう」とやってしまいます．

クーロン力みたいなものですね．

パーティクルを同符号の電荷とみなすわけです．

キーワード：TiMidity++ CreateProcess TerminateProcess CUI

CUIでTiMidity++を再生すると，GUI版よりも軽くて音質がいいように思えます．

むしろ軽いから音質がいいというか・・・．結構こういう意見は多いみたいですね．
情報ソース：TiMidity++だけを語り尽くすスレ

で，このCUI版でBGMを鳴らしておくとなると，どうもコンソールウィンドウが邪魔でしょうがない．

• intrオプションでトレーサーみたいなのが出るけど，やっぱりどこかにしまっておきたい．
  

なんとかコンソールを消すにはどうするか？ぱっと思いついたのが，CreateProcessを使ってコンソール非表示で実行させる．

という方法です．

ただ，ひとつ問題があって，実行は問題なくできるのですが，終了させる方法が・・・．

TerminateProcessというAPIを使うんですが，あまり推奨されない関数みたいです．

閉じるプロセスが子プロセスをもつ場合，その子プロセスは閉じられないとか，DLLがどうとか・・・
情報ソース：MSDN

どれも，CUI版TiMidityには関係ないっぽいのでこの方法を使うことにしました．

メモリもちゃんと開放されてるみたいですし．

というわけで，昨日いっていたやつをつくるはずが，なぜかTiMidity++のフロントエンドらしきものを作ってしまいました．

• TiMidity++のCUI版のファイル名
  
• オプション
  
• プレイリストのファイル名
  

を指定してやると，タスクトレイに入って
おとなしく再生をはじめます．

ただし，一度再生をはじめたが最後，曲送りとかはできないのでご注意ください・・・．

後は，乱数に身をゆだねるだけです．BGMながしっぱなしの人にはオススメ（まだ非公開だけど）

なんとか，ならないかなぁ・・・．

• intrオプションをつけて起動すると，キーボードで再生制御できるのですが，
  

このオプションをつけて起動すると，CreateProcessで起動できなくなるんですよね・・・．

つけないと，キーボードからの再生制御もできないので，
パイプとかを使って再生制御もできないし・・・．こまったもんです．

introduction（イントロダクシュン）

[続きを読む．．]

introduction（イントロダクシュン）

first of all（ファストヴォール）

development（ディヴェロプメント）