まどかの 日記

[2001/10/13〜2001/10/21の日記]

0016
2001/10/28 ()
 盲点でした 
 はい、名古屋に帰ってきて、そのまま仕事に行った、日曜日のお話です。
 昨日の日記にも書きましたが、今日はほんとにちょっとだけやって、動きを確認して帰るつもりでした。

 しかし、そんなところにバグは潜んでいるものです(笑)
 展示会用に使う私が担当の、あるプログラムで、音声を大量に再生させると落ちるというバグを発見してしまいました。
 まあ、バグを発見できたのは良い事なので、バグが見つかったこと自体は別にいいのですが、問題は修正に思ったより時間がかかり、結局上手くいかないまま、次の日の朝になってしまったことです(^^;

 一番重要な落ちてしまうという現象はすぐに解決できたのですが、修正したらまた別の問題が発生しまして、そりゃもう大変ですよ。
 ソース見ても今となってはわけのわからないものになってしまっているので、とてもじゃないけど、明日までに解決しそうもありません。

 というわけで、最終的になんとかごまかした形で展示会に出していますが、時間を見つけて徹底的に修正しなければなりません。というか、一から作り直してぇー。でもそんな時間ねぇー。

 でも、朝までかかっちゃったとはいえ、今日仕事にいって良かったと思いました。明日このバグが発見されたらどうしようもありませんでした。不幸中の幸いとはこのことですね(−−;

 まだ、眠いので、頭がちゃんと動いてくれてません。

 でも、とりあえずはちゃんと日記を書かないとね。

 では、次の日までさよーならぁー。

0015
2001/10/27 ()
 楽しみました 
 今日は、地元に帰って、高校のブラスバンド部同期と久しぶりに遊びました。同期の男全部が集まってわいわいやりました。全部って言っても私を合わせて6人だけどね。

 で、今回は特別ゲストとして私の彼女を一緒に連れて行きました。友達の一人だけが会ったことが無いので、会わせてあげるために連れて行きました。
 彼女も結構楽しんでくれていたようなので良かったです。

 みんなでココイチのカレー食いに行ったり、トランプ2セットで「大富豪」や「罰ゲーム付きポーカー」やったり楽しかったです。

 午前2時半まで遊びました。で、次の日はのんびり名古屋に帰りました。
 そう、そして仕事に行きました。明日(29日)が展示会の設置日なので、それまでに仕上げないといけません。ほんとはもうほとんどできているので、ちょっとやって通しの確認して帰るつもりでした。
 しかし、思いもよらぬバグが待ち受けていました。
 しかも、アニメーションとは別のプログラムで……

 徹夜明けでなので、頭があんまり上手く働かないので、ちゃんとした文章が書けません。その点、ご了承ください。

 睡魔がやってきたので、またちょっと睡魔に襲われてから続きを書きます。

 それでは、おやすみなさい。ちなみに、これ書いてるのは月曜日(29日)です(^^;

0014
2001/10/26 (金)
 結局徹夜でした(^^; 
 思ったより開発の進み具合が悪く、結局次の日の9時半まで仕事してたまどかですぅ。
 24時間以上会社で働きつづけたわけなのね。
 で、家に帰ったあとお風呂に入って、そのまま実家に向かったのでありました。

 んで、今日は何をしたかというと、ずーっと展示会用のアニメーションプログラムです。
 それしかやってないので、ネタがないです(^^;

 でもね、開発は楽しいんですよ。楽しいことやらせてもらって、気づいたら銀行にお金が入ってくる。うーむ不思議だ。これを昔みたいに給料袋とかでもらうシステムだったら、現実にお金を目の前にするので、「お金もらうためにやってる」という意識が結構前に出てくると思うんだよね。
 でも、今は銀行振込だから、どんなにがんばっても「はい、ご褒美」って直接手渡されることは無いわけで、知らない間に通帳の数値だけが増えていきます。すると、なんかお金もらうためにがんばるって意識がほとんどなくなるんだよね。

 だから残業だって、言われなくても「やらないと気が済まない」のでやっちゃうんだよね。
 これはいいことなのか悪いことなのかは私にはわからないが、嫌ではない。
 
 常に完成させたという達成感を求めてがんばっているわけで、結果的に会社に貢献していることにはなるが、開発に夢中になると、そんなことはほとんど考えないで「創りたいから創る」という意識で開発してます。

 というところで眠くなったので続きは次に起きたときということで。

 おやすみなさい。

0013
2001/10/25 (木)
 時間が足りません 
 どうも、日付が変わるまで会社にいたまどかですぅ。
 今日は展示会用のインタラクティブアニメーションシステムの開発の続きをしてました。
 これは、学生の頃、アルバイトで作ったアニメーションのシステムで、他のパソコンとUDP通信によりアニメーションの内容がインタラクティブに変化するものです。で、今は、今回の展示用に内容を新しくしているところです。
 でも、思ってたよりも変更の内容が増えてしまったので、時間が足りません。ひぃー。
 見た目をおもしろくするために処理を増やして、自分の首をしめている部分もありますが(^^;

 このアニメーションシステムは、2年前に作ったものなので、プログラムの技術力も低く、アニメーション内容の変更もちょっと面倒ですが、結構キレイに動くので、なかなかいい感じです。外部からアニメーションのコマンドを送ると、キューにたまって、自動的にアニメーションが変化する様は見ていておもしろいです。

 コマンドで変化するアニメーションはゲームにも使えますね。Sinテーブルを使って、キャラクターをふわふわ動かしたり、増分値をちょっとずつずらして複数のキャラクターにウェーブをさせてみたり、楽しんで作ってます。
 このアニメーションは展示会用のものなので、たいした仕様もなく、比較的自由に作らせてもらっているので、ゲームを作っている感じで楽しいです。
 キャラクターをこんな風に動かしてみたらおもしろいだろうなとか考えながら作るのは良いですね。
 なんか楽しんでばっかりだなぁ(^^; まあ良いことだけど。
 
 ってなことをやりながら、気分転換に昔のCマガジンを調べて補間拡大の良い方法を探してみました。
 ちなみに私は会社のプログラム関連書籍の管理を任されているので、会社にあるCマガジンやWindowsプログラム関連の書籍は全て私の後ろにある本棚に並べてあります。
 今日も、立ち読み感覚でCマガジンを漁っていると、1998年の7月号に特集で「グラフィックエフェクト」というのがあったではありませんか。
 「あったではありませんか」というより、あったのを憶えていたからこれを探してたんだけどね。

 で、内容を見てみると案の定載っていました。「ラグランジュ補間での拡大縮小」。まぁラグランジュ補間まで使わないにしても、浮動小数点を使わない補間拡大の方法が載っていたので、今度試してみることにします。

 2次元補間をすると十字の筋ができてしまう問題も解決した方法も載っていたので、結構使えそうです。
 
 これが上手くいけば、減色教室に高速な通常拡大と補間拡大の機能が実装できます。また、拡大ルーペのルーチンもブレゼンハムを使った高速な拡大ルーチンに置き換えて、さらに速くするぞ。ちなみに現在拡大ルーペの処理にはStretchDIBitsを使っています。これだと拡大領域は狭くても元画像の大きさによって処理速度が全然違ってくるので、問題があるんですよ。転送量は少ないはずなのに、画像全部を走査してる感じで。

 明日はこのアニメーションシステムをなんとか完成させて、土日は三重の実家に帰る予定です。
 なので、土曜日の日記は日曜の夜に書くことになるかな。
 とかなんとか書いているうちに、もう午前3時になってしまったので、今日はこの辺で。
 
 おやすみなさい。

0012
2001/10/24 (水)
 補間が上手くいかないっス 
 今日は、昨日書いたとおり、ブレゼンハムを利用した拡大ルーチンを実装しました。
 で、速度はというと…… 速いです。StretchDIBitsより速いです。StretchDIBitsと違って、転送する領域しか走査しないので、元画像の大きさに関係なく転送速度は転送領域のサイズにおいてそんなに差は無いと思います。

 通常の拡大はこれでよしとして、今度は補間拡大なんですが、ちょうどバイリニアフィルタ(2次元線形補間)での拡大縮小を解説してくれているページがあったので、それを参考に実装してみました。
 実装が終わって実行してみると、キレイに補間されて拡大されるのは良いのですが、遅い!!
 そりゃ描画する全ての点において浮動小数点での掛け算を行っているんだから遅いはず。それもRGBそれぞれについてやってるからモノクロ画像の3倍は遅い!!<当たり前

 これに比べてHALFTONEでのStretchDIBitsはめちゃ速いです。線形補間に加えて誤差拡散までやっててこの速さか!! って程(^^; まぁ、ハードウェアアクセラレーションが効いてるんだろうけどね。くぅ。

 で、速いんだから素直にStretchDIBitsを使えばいいじゃんと思われたと思いますが、StretchDIBitsは使えない理由があるんです。
 それは、拡大したときの描画先の位置が自力で拡大した描画位置と比べて微妙にずれるということと、ある拡大率を超えると補間されないという現象が発生するからです。
 今回のプログラムでは補間拡大した画像と通常拡大した画像をレイヤーのように重ねて表示する必要がありまして、上に重ねる通常拡大の画像と位置が合わないと困るんですよ。
 
 この位置がずれるってのは、恐らく小数点以下を四捨五入しているかいないかの違いのような感じなので、なんとかなるかもしれませんが、問題はある拡大率を超えると補間されない現象です。
 これはおそらく拡大計算した値が桁あふれみたいなのを起こしているからじゃないでしょうか。
 っていうか補間拡大の限界なんでしょうね。どうやら、6倍くらいまでが限界のようです。

 とりあえず今は画質を優先して、遅いけど自前のバイリニア補間拡大を使っています。
 でも浮動小数点演算はとても遅いので、固定少数に変換してやってみましたが、誤差が出てしまいちょっと使えません。
 どこかに整数演算でする補間拡大のサンプルってないかなぁ。
 
 あ、いまちょっと試してみたんだけど、StretchDIBitsと自前の拡大ルーチンとの位置が合わないのは、どうやら拡大の方法が少し違うからのようです。
 
 というところで、今日はおやすみなさい。

0011
2001/10/23 (火)
 妙に眠いッス 
 うーむ、眠い。そりゃあ、昨日は遅く帰ってきて、それからもちょっといろいろ調べ物とか社長にメール書いたりしてたので、就寝時間は遅かったけど、それにしても眠い。
 今日は出向先でのプログラムの見直しをしていたのだが、なんかとんでもない勘違いをしていたみたいで、そりゃ突然落ちるわなぁってなもんでした(^^; 普通にやって落ちないのが不思議なほどパラメータの計算が間違っていました。
 で、それを直していたら、上の人からさらに要望が来たので、それと一緒に修正していたのですが、どうもStertchDIBitsはよくわからない。BMPのデータの先頭が画尾図の左下から始まるということも重なって、何度やっても思うように描画してくれない。

 結局今日は正常に描画させられないまま時間が来てしまいました。
 なんかとっても悔しいので、帰りの電車の中で自前の拡大描画ルーチンを考えました。拡大のアルゴリズムの解説なんかいっぱいあるので、私が考えたというわけではありませんね(^^; しいて言うなら今の状況に最適化したルーチンを考えたということかな。

 有名なことですが、拡大縮小ルーチンにも直線描画アルゴリズムである”ブレゼンハム”が利用できます。
 以前紹介したダブルステップブレゼンハムではなく、普通のブレゼンハムを使います。

 詳しいことはfussyさんのページを参考にして下さい。

 んで、明日は早速自前の拡大縮小ルーチンを作ることにします。今回作るのは補間をしない普通の拡大です。というのも、補間をしないで拡大ということが条件なので、練習がてら簡単でしかも高速なのを実装します。

 また、高速な補間拡大もいずれは必要になってくるので、そのうちそれも作ります。
 
 それにしてもちゃくちゃくと自分の趣味のためになる技術を身に付けていっています。仕事が仕事だけで終わらないのって良いよね。せっかく憶えた技術は使わないともったいないよね。もちろん趣味で身に付けたノウハウを仕事で活かすのも大事だよね。そのための趣味であり、そのための仕事である。って感じ。私の場合。

 この前、ふと私からパソコンを取ったら、何をするのかなぁって考えてみました。
 パソコンが無いので、当然プログラムもできないし、文章も手で書かないといけないし、絵だってやり直しは簡単にできません。
 さあ困った。ここに来てパソコンってなんでもできる魔法の機械だなぁって感心しちゃいました。
 
 初めて買ってもらったMSXというパソコンは、今ほど便利ではありませんでしたが、私にプログラムの楽しさを教えてくれた大切な恩師です。今でも箱にしまってちゃんと保管しています。もうさわることは多分無いでしょうけど…… MSX時代の経験は今でも役立つことがあるし、半年に一回くらいは昔のことを思い出します。
 
 中学1年生の頃にMSXを買ってもらって、すぐにプログラムにハマって今までずーっと走ってきました。誰にも教わることなく独学でやってきましたが、今思えばこの独学スタイルが一番の勉強法だと確信しています。
 自然に問題解決能力が身についたとでも言いましょうか、ちょっとやそっとじゃあきらめません(^^;
 今でもまれにありますが、ひとつのバグに3ヶ月以上も悩んでいたこともありました。そんなバグに限ってたいていイージーミスなのですが(^^; 悩んだら、絶対間違うはずが無いって自信があるところをまず疑いましょう。人間ですもの、たまには失敗しますよ。

 う、プログラムの話になったら、長くなってしまうので、今日はこれくらいで。
 それでは、おやすみなさい。

0010
2001/10/22 (月)
 今日はお買い物 
 今日から、1週間ごとにページを分けることにしました。1週間でも私の日記は書く量が多いので、結構なボリュームになるね。

 で、なんだかんだいって、もう10日も日記が続いている。我ながらたいしたもんだ。
 以前卒研のゲームを作るときにも毎日開発日記を書いたが、それと同じように、量は多いし、書くのは意外と楽しい。
 日記をはじめると書かなくてはいけない義務感を感じてしまう。まぁ義務感を感じていないと続けられないというのが本音ですが(^^;

 で、今日は出向先ではなく、所属の会社のほうで仕事をしたのですが、10月30・31日に開かれる展示会へ向けての作業を、私は少ない日数でこなさないといけないので結構大変。少ないといっても、なんか早く準備をはじめなかった自分に対しての自業自得ですが(^^; ふぅ。

 で、なんとか間に合わすためにがんばってます。
 しかし、明日から3日間は出向先での仕事のなので、また気持ちを切り替えないとね。昨日見つかったActiveXのバグ解決法も実装しないといけないし、今日試しに自分のパソコンで出向先で作ったプログラムをめちゃくちゃに動かしてたら、突然マシンの電源が落ちるといった致命的なバグも見つけちゃったし…… 
 やることいっぱいだぁ。

 特にマシンごと落ちちゃうバグはなんとかしないとね。恐らく読んじゃいけない領域に、何かのタイミングでアクセスしちゃって、お亡くなりになったって感じだなぁ。
 描画部分でStretchDIBitsなどのDIBits系APIを使用しているので、ここらへんかなぁ。
 最近画像が大きいとStertchDIBitsの転送速度が遅くなることがわかったので、これに代わって自力拡大縮小関数を用意しようと考えているのだが、これで落ちるのが直ったらいいなぁ。
 まだそんなにデバッグしていないので、DIBits系のAPIが悪いとも言い切れないけどね(^^;
 GdiFlushとか使わないといけないのかな。

 それでは明日も早いので今日はこの辺で。

 おやすみなさい。