mieki256's diary

メモ。

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

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

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

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

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

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

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

◎ 逆に言うと。 :

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

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

---

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

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