ホムラ

前にチラッと書いた炎シミュレータが大分改善された。
一寸うれしいので、備忘録的に書きます。


最初はこんな感じ。
色つきのポリゴンを拡大しながらフェイドアウトさせているだけ。


次にこんな感じ。
細かいポリゴン一枚ごとに別個のテクスチャを貼ったら、
グラフィックボードが悲鳴を上げた。
（耳で聞こえるほどの音がしていた）
こわれそうなのでこれは没。


ネットで調べた結果を応用して見たのがこれ。
一枚のビットマップにソフトから直接からドットを打って、
色を時間とともに拡散させるようにしたのがこれ。
大分炎らしくなった。ろうそくの火みたいだ。
しかしまだ下のほうがなんとなくおかしい。


これがさっき作ったもの。前のバージョンより大分良くなった。
ドットを打つのではなく、配列を使って大きな粒を、
ビットマップに加算合成した。
われながら良い出来だ。

燃え上がれ(備忘録)

最近ブログを余り書いていないので、回数を増やそう。
とりあえず備忘録的なもの。

この間からちまちまと新しいプログラムなぞを作っている。
その名も「炎シミュレータ」。

実物の炎にいかに近く見せるかが問題なのだが、
定石のようなものがあって、それをまねたつくりにしてみた。
しかし、作ってみたら、一寸リアルすぎて困った。
動きとしては大体満足できるものだった。

しかしだ。
炎が上にしか広がらない。
多少横にも広がって欲しいのだが、
どうしたら出来るか分からない。

基本的にはビットマップを、
プログラムから直接書き換えるようになっている。
知っている人も多いと思いますが、
コンピューター上の色というのは、
「Ｒ」ed 「Ｇ」reen 「Ｂ」lueの三色を混ぜて表現されている。
たとえば16*16pixelのビットマップ画像だったら、

GAZOU[16][16][3]という感じの三次元配列で表すことが出来る。
予想される最大の数値は255(=1byte)であり、
それが16*16*3だから768byteになる。
要するに一秒間に60回画面を書き換えるのであれば、
最低でも768*60=46080回の計算をすることになる。
なんだか効率が悪いようだが、
最近のコンピュータならこれぐらいは、なんてことの無い回数だ。

(最近のコンピュータは、
最大で32bit=232byteのメモリを一度に演算できる。
しかもCPUが二つつんであればそれの倍だ!
因みに、1ギガのCPUだったら、一秒間に十億回の演算が可能である。
だから四万回なんてたいしたことは無いはずだよな。)

こうかんがえてみたら、
もう少し手間の掛かるプログラムにしてもよいような気がしてきた。

今現在は「左・右・下」のピクセルのRGB情報と、
自分のRGB情報の平均を出すというシンプルな方法をとっているのだが、
左右との平均を出すときに多少割合を変えてみるとうまくいくのかな？
しかし下手に左右の割合をおおくすると、
際限なく左右に広がってしまうことになるから油断は出来ない。
物が火の画像だけに一寸怖い。

とりあえず後で試してみよう。

ショボイ

パソコンの中でも、ほとんどその存在を意識されない部品がある。

グラフィックボードがそれだ。

しかしながら、動画の再生から、３DCGまで、
グラフィックボードのお世話にならないことは無い。
普通にブラウザを使うだけでも多少お世話になる。

実は、グラフィックボードには、専用のCPUが搭載してあり、
メモリも画像専用の物が付いている。
おかげで最近のパソコンで、画面がかくかく表示される、
などという現象はほぼ起こりえない。

しかしだ。

一昔前のパソコンを後生大事に使っていたりすると、
最新技術やマイナー技術には対応していなかったりする。
DirectXという、マイクロソフトが開発した、
マルチメディア専用のシステムが現在は一般的である。
しかし、OpenGLというものもある。

DirectXが、あくまでマイクロソフトの所有物であるのに対して、
OpenGLは無償供与されている。

無償ということもあり、プログラミングではOpenGLを使っているのだが、
古いグラフィックボードとは相性が悪い。
2000年のボードではほとんど動かない。
2002年ぐらいになると、動くものがつんであるのだが,,,
新しいパソコンがほしいような、いらないような、
そんな複雑な気分。