mieki256's diary



2008/09/03(水) [n年前の日記]

#1 [iappli] また透明色指定のない画像群が送られてきたのだけど

こうまで透明色指定がされてない画像ばかり送られてくるということは、デザイナーさんのほうに「gifの透明色指定をしておいてください。それがアプリ上でも透明色になります」という指示連絡が行ってないまま作業してもらってる状態なのではないかという不安が。

あるいは、デザイナーさんの使用ツールの問題で、「こちらでは透明色を指定するのが極めて難しいです。受け取った側で透明色指定してください」という返事が来ているけれど、そのあたりの話が自分には一言も伝わってきていない、ということかもしれず。

いやまあ、ツールの問題等があるのであれば、こっちでそのへん作業してもいいんだけど。ただ、プログラムを作るのはプログラマーしかできないけれど、透明色指定はプログラマーじゃなくてもできる作業なわけだから、プログラムを作る作業を中断してまで透明色指定をプログラマーがしてるのはどうなんだろうという気もする。えてして最後のほうでアタフタすることになるのはプログラマーだったりもするし。 *1

というか、「ここは透明色にする」ということを意識しないとそもそもドット打ちができわないわけだから、デザイナー側で指定できたほうが・指定作業が可能な環境を整えることに注力したほうが話が早いのではないか。という気もしているんだけどどうなんだろうなあ。

それとも、昨今のその手のアプリの開発現場では、デザイナーさんとプログラマーの間に、画像の透明色やマスク作成をする専門の作業員が居るのが当たり前、だったりするのだろうか。ポリゴンゲーなどは、「俺はテクスチャしか描かない」「俺はモデリングしかしない」「俺はモーション付けしかしない」等々分業が進んでそうな印象もあるし。あるいは、携帯電話向けのアプリなんてのは、企画の大きさ的にプログラマーがアレもコレもやるのが当たり前で、本来なら自分が企画書もドット打ちもサウンドデータ作成もするぐらいじゃないとあかんかったりするのだろうか。そのへん全然実状を知らないんだけど。

今回の画像群のクオリティでお前もドット打ちせよ、と要求されても自分には無理だな…。やっぱりプロは上手い。全然歯が立たない。画像が届くたびに感嘆のため息が漏れてしまう自分。や、透明色は指定されてないけど。

よくわからないアニメ画像が送られてきて悩む。 :

先ほどの透明色指定の話とも関係するのだけど。一枚の大きな画像の上に、細かいパーツ画像を置くことで、アニメさせるつもりなのであろう画像群が届いたが、それを見て首を捻る。

一枚の画像の上に、細かいパーツ画像を置いていく場合、そのパーツ画像を「透明色ナシ」で置くのか、「透明色アリ」で置くのか、という問題があるわけで。

たとえばの話。
  • 下地になる大きな画像が、「透明色ナシ」の画像で。その上に置くパーツ画像が矩形状にビッシリとドットを打ってあれば。これは「透明色ナシ」で置くのだろうと想像がつくし。
  • 逆に、下時になる大きな画像が、「透明色アリ」の画像で。その上に置くパーツ画像も「透明色アリ」っぽい画像=下時と同じ透明色の色で背景部分が塗りつぶされていれば。これは「透明色アリ」で置くのだろうと想像がつく。

しかし、今回届いた画像はそのあたりが判らない。
  • 下地になる大きな画像は「透明色アリ」の画像として扱わねばならない画像。
  • 上に置くパーツ画像も、一見すると、背景が透明色扱いの色で塗られている。
  • であれば、「透明色アリ」で重ねるのか…。
  • …と思って並べてみたがどうも形状が不自然。まだ「透明色ナシ」で重ねたほうが形はしっくりくる。
  • ということは、透明色扱いの色で下地画像が塗りつぶされることが前提 ―― 「透明色ナシ」で置くことを想定したパーツ画像群なのだろうか。gifの透明色指定もされてないあたり、その可能性も高い。
  • と思ったが、一通り「透明色ナシ」で置いてみると、今度は、一部で、下地の画像のドットが変なところに残ってしまっている。
なんだこりゃ、一体どっちなんだよ。みたいな。

そもそも、「透明色ナシ」で重ねることを考えて作られた画像だとすると、下地画像を虫食い状態にして表示して、その虫食いのところにパーツ画像群を表示しないといけない。しかし、矩形画像を「虫食い状態」で表示するなんてことは、プログラム的にはそう簡単にできることではないわけで。そうなると、自分が、下地画像を細かく分割して、別途「下地画像群」を作り直し、かつ、「下時画像群の表示位置座標テーブル」を作成するという作業が入ってくる。まあ、今回だけの、1回きりの作業であれば、「めんどくせえなあ」と言いつつも、まだやれなくもないけれど。この画像群については、この後、修正された画像が上がってくるという話もあって。また同じ作業をさせられるのでは正直たまったもんじゃない。

これがもしPC用のゲームだったら、画像の数ドットが変わっただけでも、640x480とか800x600とかで全部一枚画像として持ってしまえ、ということになって話は簡単だろうけど。 *2 携帯電話向けアプリの場合は、まだ容量との戦いがちょっぴり残ってなくもない世界なので、なかなかそういうわけにもいかない。

とりあえずこのへんは、修正画像が届いてから作業するか…。

*1: 逆にデザイナーさんは前半にプレッシャーかけられる感が。プログラマーから「画像はまだですか?」「早く上げてよ」みたいな。や、画像サイズや画像構成等さえある程度決まってれば、仮画像さえあればどんどん作業が進められる場面も多いんだけど。
*2: 現代のエロゲーの吸い出し画像を眺めたりすれば、PC98時代のエロゲを作ってた人ならかなりゲンナリするであろう予感。「こんな画像の持ち方したらフロッピーディスク何枚組になるんだよ!パーツで持てよ!」みたいな。

#2 [prog] 画像の差分を取り出すツールが必要になりそうな予感

2枚の画像の異なるドットを調べて、元画像、変化画像1、変化画像2、に分けて出力するツールがあれば作業が楽かもしれないなと。

さらに、変化画像1、変化画像2の中にあるドットを検索して、イイ感じの複数の矩形画像にして出力、かつ、その表示位置座標のテーブルも出力、てなことができるとさらにグッドかもしれず。…イイ感じの複数の矩形をどうやって作ればいいのか、その処理がちょっと想像できないけど。

背景色以外のドットが出現するまで横方向にドットを眺めていって、ドットが出現したら、そのドットから上下左右斜めにドットがあるかどうかを調べ、もしドットがあれば矩形領域を1ドット広げて、ドットがなければそこでその矩形の作成は終了、という感じではどうか。と思ったが問題がありそうか。

以上、1 日分です。

過去ログ表示

Prev - 2008/09 - 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

カテゴリで表示

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


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

Powered by hns-2.19.6, HyperNikkiSystem Project