mieki256's diary



2006/05/22(月) [n年前の日記]

#1 [cg_tools] _Inkscape tutorial: 基本

メモ。

#2 [game][iappli] BGを高速スクロールさせたいのだけど

3D表示が当たり前になった今のゲームではどうでもいいことかもしれんのだけど、それはさておき。たまたま妹にこのへん説明していて、どうも図があったほうがわかりやすいなと思ったので作ってみたり。

例えば、2Dゲームで、128dotでループするBGがあって。キャラクターが右に進む ―― BGは左に向かってスクロールするとして。どのくらいまでスクロール速度を上げることができるか。

「128dotでループしてんなら、ざっくりと96dotぐらいで動かしちゃえばいいんじゃね?」とか言ってると、こうなる。
128dotのループBGを96dotで左へスクロール。
逆にスクロールしてるように見える。お前はグラ2か! なんちて。 *1

「じゃあ、半分のドット数 ―― 64dotぐらいだったらいけるんじゃねーの?」とか言ってると、こうなる。
128dotのループBGを1/2の64dotで左へスクロール。
スクロールしてるように見えない。なんかパカパカしてるだけ。…いや、見る側がかなり頑張って、好意的に見てやれば、もしかしてスクロールしてるつもり? と思えないこともないけど。右に進んでるのか、左に進んでるのか、わからんのはたしか。

…やはり、最初の画像と終わりの画像の間に、いくらなんでも2コマぐらいは入れて、動く方向を示さないといかん気がするわけですよ。1コマしか入ってない状態では、方向がわからん。ということで、つまりループ幅の1/3ぐらいが最高速度じゃないかなと。

下は、128dot の1/3 、42dot前後で動かした例。
128dotのループBGを1/3の42dot前後で左へスクロール。
これならなんとか高速スクロールしてるように見える。かな。ちょっと厳しい感じもするけど。

ループ幅の1/4ぐらいなら、かなり真っ当なスクロールに見えてくる。下は、128dot の 1/4、32dotで動かした例。
128dotのループBGを1/4の32dot前後で左へスクロール。
でも、ちょっと高速スクロールという感じから離れ始めてるような。いや、まだ大丈夫かな。

逆に言うと。 :

BGのループ幅が決まってたら、スクロールの最高速度も自ずと決まってしまうわけですよ。たぶん、おそらく、大体は 1/3 近辺で頭打ちになる。のじゃないかと予想するわけで。

仮に、32dot幅でループするBGがあったら…32dotの1/3だったら、10〜11dotぐらいかしら。こんな状態。
32dotのループBGを1/3の11dot前後で左へスクロール。
どうですか。高速スクロール! って感じですか?

上記のアニメGIFは10fpsだけど。 *2 一般的な家庭用ゲーム機のように、60fpsで表示できるハードなら、実際はこれの6倍の速度でスクロールしていく。であれば。まだ高速スクロールと呼べるかもしれん。

でも。10fpsしか出ないハードで、32dotでループするBGが渡されたら、この程度のスクロール速度にしかならない。どう見ても、もはや高速スクロールと呼べる状態ではないよな…。

で。iアプリってのは、おそらく 10fps ぐらいしか出ない。 *3 さらに、「自機が高速で移動してるように見せるゲーム」てな感じの企画をやろうとしてるなら…。16dot幅とか、32dot幅とかでループしちゃうBGチップ「だけ」描かれても困る事態に。描く前に気づいてよぅ…。>グラフィッカーさん。もっとも、画像容量削減という課題もあるから、対応は難しいだろうと予想するのでありますが。

なんとか見栄えを誤魔化す方法はいくつかありそう。 :

  • BGチップは32dotでも、チップの配置の仕方でループしてる幅を広げる。<個人的にはそれが当たり前だと思ってたんだけど…。
  • 手前に、そのスクロール速度で流れていく物体を表示する。
  • 奥行きのある画面・多重スクロールができるなら、遠景は、スクロール方向がちゃんとわかるスクロール量にする。
  • 高速スクロール時は、事前にブラーをかけた画像を別途用意しておいて、それに切り替えてしまう。
他にも手はあるだろうけど。たぶんこのへん、アニメの各種技法が流用できそう。ということでアニメをコマ送りして日々研究する自分なのです。<自分の趣味(?)を正当化するためにコレを書いたのか、君は!

いっそ自分で描くか。でも、後から画像が届くと整合性を取るのが大変で。それ以前に、自分如きの画力では描けるものじゃないし。なかなか難しい。

高速スクロールをやめちゃうか。そうすれば、背景に障害物を色々置いても問題ない状態になるから、もっとゲームっぽくなるかもしれん。企画を根底からひっくり返すことに繋がりそうでもあるけど。

このへん、ツールの不在に起因してるところもありそうな。 :

マップエディタにしろ、スプライト配置エディタにしろ、グラフィック担当の人が入手しにくい・活用しにくい状況があるが故に、こういう状況を招くのかもしれん。マップエディタがなければ、ループ幅を広く取ったチップの配置、てのをイメージしながら作業するのも難しそうな。

更に、マップエディタにスクロール表示確認機能なんてのがついてたら…。って、こうやってアニメGIF作れば説明できることを、わざわざツールに盛り込まんでもいいか。

そもそも、2Dゲーム作る人なんて少数派になりつつあるんだろうし。ツールの存在意義自体、あまり無いわな。と、いつもの結論に。

*1: MSX版グラディウス2、通称「グラ2」は、反対側に逆スクロールしていくと聞いた記憶が。プレイしたことないので本当かどうかは知らない。ちなみに、「グラ2」と「グラII」は違うらしい。後者はアーケード版。らしい。よく知らないけど。
*2: アニメGIFは、1/100s 単位でwaitを指定できる。これらは 10を指定してるので、10fps程度のはず。
*3: タイマ分解能が100msしかない端末が存在するので、100ms毎にしか処理ができない = 10fpsになってしまう上に、描画処理の速度が遅いので。タイム分解能が細かくて、尚且つ、描画処理が速い特定機種に合わせてチューンナップしない限りは、大体は10fps程度になるんだろう。と思う。

#3 [iappli] アウトオブメモリ

224x224の Image を createImage して、そこに色んなBGチップを drawImage して、その Image を使って BG表示用のImageに drawImage すれば、BGチップ配置データの量については激減させることができるかもしれない。と閃いて作業してみたものの。createImage したところで「Out Of Memory」と表示されてしまった。…名案だと思ったんだけどなぁ。

そもそも、複数の画像になってるBGチップ群を一つの画像にまとめたら、どのくらいのファイルサイズになるだろう。と疑問が湧いたので試してみたり。16色のgifばかりなのだけど、まとめると、さすがに16色では入らない。が、全部で180色前後しか使ってないので、間違いなく256色で収まることは判った。で、ファイルサイズを確認してビックリ。バラバラな状態より少ない。やったー。と思ったら。作業用に変換保存してたフルカラーpng群と比較してた。何をやってるのだ、俺は。元々のgif群と比較したら、グーンとファイルサイズが増えてた。…そりゃそうだよな。世の中、いや、コンピュータの世界は甘くないであります。甘いどころかシリコンの味がする。嘘ですが。ていうかどんな味だ。>シリコン味。いや、シリコンの味が判ったからといって何がどうなるわけでもないのですが。

以上、1 日分です。

過去ログ表示

Prev - 2006/05 - Next
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project