![]() |
||
![]() |
7/31 もうひとつの拡大法 なんと、またしても隔月更新になってしまいました。 隔週更新ペースになってしまった…と嘆いた矢先に、隔月更新ッ(泣)
夏コミ参加します! 告知遅ッ、いや相変わらずですね。 一日目である、8月10日は金曜日、東地区”テ”60bにて、お待ちします。 ブツは、ねこにっきときっちんの在庫(^^;)と、新作である、ねこにっきtwinです。 けど、ねこtwinはまだまだ出来上がってないので、体験版を配布する事になると思います。価格はまだ決まってないです。多分無料か、お金取ってもCD-Rのメディア代くらいだと思いますので m(__)m 本当に引っ張ってるなぁ… ねこtwinのスナップショットとかはなるべく早いうちに公開したいです。夏コミ前にULしないと意味が無いので、次回のひとりごちはなんとか夏コミ前までに最低一回ULしたいです(^^;;;;)
…ともあれ 画像の拡大方法について、いまだに時折考えていたりします。 現在のCbWallの方法では、まだレンズにはかなわない。レンズによって拡大された画像を見るたびに、僕は涙が止まらない(大袈裟 しかし、アナログな物体の持っている情報量とはほぼ無限。よって、アナログをアナログに拡大する手法をそのままそっくり実装しようとすると無限の時間がかかるのは自明です。しかし、それに漸近しようとする意思こそ僕に必要なエネルギーなのです! まず、CbWallの現状がいかにマズいかといいますと、音声を伸縮するアルゴリズムを実装している点です。音声を標本化パルス列によってサンプリングして符号化し、それを理想的ローパスフィルタを通して音声に復元する。その過程を模倣しているに過ぎません。しかし、それは画像にそのまま当てはまるかというと決してそうではない。 …まず、輝度情報がどうやって僕らの目に見える形になるのか、という事から考え直します。かいつまんで言うと、VRAMに書かれた輝度情報は、RAMDACを通ってD/A変換され、電子銃によって発射された電子が蛍光体に衝突することでRGBいずれかの蛍光を発するわけです。さて、ここで、蛍光はどんな風に広がって、僕らの視細胞に突き刺さるんでしょうか? 「そんなのモニタによるし、そもそもLCDとかだったら原理からして違うよ」と仰ることでしょう。そう、そうなんです。それなのに僕らは蛍光の広がりを無視して、単なる点とか、単なる四角形で表現していましたよね。けれど、蛍光が広がらずに、大きさの無い単なる点状であるとしたら、VRAMにどんなに明るい輝度値を書き込んでも画面は真っ暗のはずですね。画素の大きさと一致する完全な四角形に広がるんだとしたら、にじみは全く起こらないし、ドットの隙間も全く見えないはずです。けれど、実際僕らの見ている画面ではそうじゃない。 というわけで、輝度 i のピクセルを座標 P(px,py) に対して映そうとしたときの、座標(x,y)の実際の輝度 I (x,y)について、
なる、関数Sを考えます。ここで、Sは画素の広がりをシミュレートする関数という事になります。音声信号の場合では、これがSinc関数だったんですね。 尚、γというのはγカーブのための関数です。ここで、「ちょっと待って、蛍光体から発する光は立体的に出るんだから、視点と画素の位置関係を踏まえた3次元的な計算が要るんじゃない?」と思うかもしれませんが、視点は十分遠くにあると考えます。つまり、視点はどの画素に対しても真正面にあると考える事とします。さもないと、ユーザの視点の位置を検知してリアルタイムで画像を拡大・縮小する必要が出てきますからね(^^;) 次に、画像全体を幅w,高さh個からなる画素の集合と考えると、画像を構成する各画素の輝度値を Ix,yとすると、座標(x,y)における実際の輝度 I(x,y) は以下のようになりますね。
はい、上式において、xとyは小数でも整数でも構いません。つまり、座標が整数値の場所(格子点)の輝度だけでなく、画面上のどこの輝度もムラなく取り出せます。すなわち、拡大・縮小し放題。 けれど、そうやって取り出した輝度を単純にメモリ上に貼り付けるだけで、果たして縮小・拡大後のイメージを正確に再生してくれるのでしょうか? してくれませんね(^^;) そう、縮小・拡大された画像のために生成した輝度情報を実際に画面に映すとして、その画像と、拡大・縮小前の画像を「そのまま」引き伸ばし/縮めた画像の誤差が最小になるような輝度情報を生成してこそ、真の拡大・縮小なのです。 というわけで、縦横に(u,v)倍に拡大/縮小後の輝度情報をi '(x,y) として、
で、誤差eの評価が出来ます。 この誤差が最小になるi ' を生成すれば良いんですねッ …m(__ 誤差に関与するパラメータが多すぎる(全画素がそのままパラメータ)ので、いささか大変ですが、高速化の指針としては、遺伝的アルゴリズムとかそんなのを使って準最適な状態に落とし込む、くらいしかないかなぁ、と思います。 それでも、随分処理時間が掛かりそうですね。なにしろ式の中の積分をどう実装するかというと、オーバーサンプリングによるしか無いわけで、4x4で大雑把にオーバーサンプリングしても、全画素数の16倍の計算回数が必要になります。それを遺伝的アルゴリズムによって調整…1000世代くらい行うとして、はて、どれだけ時間が掛かるでしょうか(^^;) そもそも、関数Sの設計を誤ると台無しですし。
最近のDiablo2事情… (^^;) 何の事は無い、いまだにDia2やってる事が甚だしかったり。いや、小倉に居る間、空いた時間はDia2ばっかりやってるかというとそうでもなくて、人を呼んで食事をしてたりいろいろだったんですが。拡張パックが出てしまってからはもう大変。 しかし、 拡張パック登場で、なんだかゲーム的に怪しくなってしまったという感が否めません。なんと言っても、物理攻撃を無効にするPhysical Immune (PIと略)属性を持った怪物や、各種属性や魔法を無効にする怪物が出現するようになってしまいました。このため、全クラスの勢力図は完全に塗り替えられました。育てなおしになってしまうキャラも多々。これは皆覚悟したことかもしれませんが…槍アマゾンが完全に使えないキャラになってしまったのがイヤ過ぎますね(^^;) PI相手には槍はほぼ役立たずなのに槍しか攻撃手段が無く、その槍の攻撃速度も物凄い低下のしようです。一方で、新キャラのドルイドは狼に変身すると槍アマゾンと完全にカブる戦闘方法が出来る上に、狼ドルイドの方が明らかに戦闘能力が高いというのもいたたまれません。 そして、物理攻撃を減少するユニークアイテムを幾つも装備することで、ほぼ物理攻撃無効なキャラを育成することが出来るようになってしまいました。無論、そういう装備で固めるとキャラクターはまず死にません。で、それらはユニークアイテムな物だから見た目上の差別化が全く出来なくなるため、なんだか画面を見てて面白くありません。確かに、新しいアイテムやクラスが追加されたけど、アイテム稼ぎの過程において唯一絶対強い武器・防具があって、それをコンプリートしちゃえば終わり、というのは個人的に受け入れられない。ユニークアイテムがあまり強くなくて、無限の組み合わせを持つレアアイテムが至高の物であった拡張セット導入前の方がかえって面白かったかもしれません。 ああ、面白かったのに、なにか変なことになってしまった。いや、このくらいで終止符を打ってくれないと僕も困ってたんですが。丁度良かったという事にしておきましょう。とっととDiablo2のゲームディスクは中古屋に持っていきたい。けど、パッケージを小倉に置いてきてしまった。 あう〜(遠吠え |
|
![]() |