(過ぎたことは忘れちまえ)つらつら書くなり
カレンダー
カテゴリー
プロフィール
HN:
lenguasydialectos
性別:
男性
ブログ内検索
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
最近ブログを余り書いていないので、回数を増やそう。
とりあえず備忘録的なもの。
この間からちまちまと新しいプログラムなぞを作っている。
その名も「炎シミュレータ」。
実物の炎にいかに近く見せるかが問題なのだが、
定石のようなものがあって、それをまねたつくりにしてみた。
しかし、作ってみたら、一寸リアルすぎて困った。
動きとしては大体満足できるものだった。
しかしだ。
炎が上にしか広がらない。
多少横にも広がって欲しいのだが、
どうしたら出来るか分からない。
基本的にはビットマップを、
プログラムから直接書き換えるようになっている。
知っている人も多いと思いますが、
コンピューター上の色というのは、
「R」ed 「G」reen 「B」lueの三色を混ぜて表現されている。
たとえば16*16pixelのビットマップ画像だったら、
GAZOU[16][16][3]という感じの三次元配列で表すことが出来る。
予想される最大の数値は255(=1byte)であり、
それが16*16*3だから768byteになる。
要するに一秒間に60回画面を書き換えるのであれば、
最低でも768*60=46080回の計算をすることになる。
なんだか効率が悪いようだが、
最近のコンピュータならこれぐらいは、なんてことの無い回数だ。
(最近のコンピュータは、
最大で32bit=232byteのメモリを一度に演算できる。
しかもCPUが二つつんであればそれの倍だ!
因みに、1ギガのCPUだったら、一秒間に十億回の演算が可能である。
だから四万回なんてたいしたことは無いはずだよな。)
こうかんがえてみたら、
もう少し手間の掛かるプログラムにしてもよいような気がしてきた。
今現在は「左・右・下」のピクセルのRGB情報と、
自分のRGB情報の平均を出すというシンプルな方法をとっているのだが、
左右との平均を出すときに多少割合を変えてみるとうまくいくのかな?
しかし下手に左右の割合をおおくすると、
際限なく左右に広がってしまうことになるから油断は出来ない。
物が火の画像だけに一寸怖い。
とりあえず後で試してみよう。
とりあえず備忘録的なもの。
この間からちまちまと新しいプログラムなぞを作っている。
その名も「炎シミュレータ」。
実物の炎にいかに近く見せるかが問題なのだが、
定石のようなものがあって、それをまねたつくりにしてみた。
しかし、作ってみたら、一寸リアルすぎて困った。
動きとしては大体満足できるものだった。
しかしだ。
炎が上にしか広がらない。
多少横にも広がって欲しいのだが、
どうしたら出来るか分からない。
基本的にはビットマップを、
プログラムから直接書き換えるようになっている。
知っている人も多いと思いますが、
コンピューター上の色というのは、
「R」ed 「G」reen 「B」lueの三色を混ぜて表現されている。
たとえば16*16pixelのビットマップ画像だったら、
GAZOU[16][16][3]という感じの三次元配列で表すことが出来る。
予想される最大の数値は255(=1byte)であり、
それが16*16*3だから768byteになる。
要するに一秒間に60回画面を書き換えるのであれば、
最低でも768*60=46080回の計算をすることになる。
なんだか効率が悪いようだが、
最近のコンピュータならこれぐらいは、なんてことの無い回数だ。
(最近のコンピュータは、
最大で32bit=232byteのメモリを一度に演算できる。
しかもCPUが二つつんであればそれの倍だ!
因みに、1ギガのCPUだったら、一秒間に十億回の演算が可能である。
だから四万回なんてたいしたことは無いはずだよな。)
こうかんがえてみたら、
もう少し手間の掛かるプログラムにしてもよいような気がしてきた。
今現在は「左・右・下」のピクセルのRGB情報と、
自分のRGB情報の平均を出すというシンプルな方法をとっているのだが、
左右との平均を出すときに多少割合を変えてみるとうまくいくのかな?
しかし下手に左右の割合をおおくすると、
際限なく左右に広がってしまうことになるから油断は出来ない。
物が火の画像だけに一寸怖い。
とりあえず後で試してみよう。
PR
この記事にコメントする