アニメーション処理 [コメントする]

アニメーション処理


スレッド作成 : Saieyさん
 (1998/2/20 21:09:34)

パソコン等で使われたアニメーション処理についてのお話をお願いします。

アニメーションといえばこのゲーム!とか、このソフトではこんな変わった処理が!とかとか・・・。


スライド辞書

Saiey さんのコメント
 (1998/2/20 21:12:52)

スライド辞書??初めて聞きました。どんなふうにするんですか?

話題の元


WILL - The death trap ][ -

あきよし さんのコメント
 (1998/2/23 10:05:51)

アニメ処理で最初に話題になったゲームではないでしょうか?
コマンド入力アドベンチャーゲームですけど、すべての画面で、どこかしらアニメーションしていました。

・・・パレットチェンジアニメーションとか、目パチ、口パクの類ですけど。


スライド辞書

あきよし さんのコメント
 (1998/2/23 10:10:38)

圧縮方法としては、「すでに読み込んだデータの中に、同じデータがあるかどうかを探す」です。
そして、そのデータの位置と、何文字同じなのかを記述します。

たとえば、アルファベットの並びを圧縮するとします。数字は、圧縮符号とします。

連長圧縮なら
aaabcccdaaabccd は a3bc3da3bc2d となりますが、
スライド辞書では a12bc12d8473 と表せます。

#数字は2個一組で、「何個前」「何文字」の順

連長のように同じ記号が並んでいない場合でも、繰り返しがあれば圧縮できるので、圧縮効率が良くなります。


スライド辞書

Saiey さんのコメント
 (1998/2/23 12:18:28)

なるほどねー。勉強になります。
でもこの方法はやっぱり、圧縮時の処理に結構時間がかかりそうですねぇ。

まぁ、普通デコードよりもエンコードの方が時間がかかるものですけどね。なんでも。(^^)


Will

Saiey さんのコメント
 (1998/2/23 12:21:51)

スクウェアですねー。
ヒロインが振り向くアニメーションが一番の売りだったと思います。

アルファも同じようなレベルのアニメーションだったかな?
エレベーターの操作盤がパレットチラチラで派手に輝いていたのを覚えています。


アルファ

あきよし さんのコメント
 (1998/2/23 17:59:23)

そんなのもありましたねぇ。
ほぼ同時期・・・アルファの方が少し遅かったかな?

ブラスティーとか、ライーザとかもこのころでしたよね。

「アニメーション処理!」が、それだけで売り文句になった時代です。


・・・・5年立ったら、今の「3Dポリゴン」も同じ感覚なんだろうなぁ・・・・


アニメ技術の影に

あきよし さんのコメント
 (1998/2/23 18:03:34)

「ミコとアケミのジャングルアドベンチャー」とか、「アステカ」とか、高速画面描画を売りにするアドベンチャーゲームがありました。

画面描画0.2秒! とか、高速性を売りにしていたのですが、これらは画面を「Line & Paint」ではなく、「べたデータを圧縮したもの」として持っていました。

フロッピーディスクが当たり前になり、大きなデータを持てるようになったので出来た技でした。

#圧縮の意味では、Line&Paint はすごい効率である。
 ただし、展開には非常に時間がかかる。


高速表示

Saiey さんのコメント
 (1998/2/24 09:48:31)

Willよりアルファのが後ですね。

5年待たなくても、そろそろ3Dポリゴンも当たり前な技術になっているような気が・・・。(^^;

それに、昔を知ってるから「すごい」と思えますけど、きっと最近のユーザーさんは3Dポリゴンだって言われても、「なにがすごいのか」っていうのがわからないんじゃないかと・・・。

以前、X68kで回転拡大縮小ばりばりなゲームを友達とやっていて、それを「すごいよねー」って私が言ったら、「知識がないから何がすごくて何が当たり前なのかわからない」って言われたことがありますから。(^^;

----

画面の高速描画、ではちょっとないですけど、昔見たPC-88のアドベンチャーゲームで、プレーンごと(?)に描いてるのがありました。つまり、最初に青だけを書いて、次に赤・・・って感じで。Line&Paintよりは速い感じでしたけど、すぐに出る、というほど速くもなかったです。

これは、なるべく高速に表示するためなのか、データの圧縮の都合なのかっていうのが、いまだにちょっとわからないんですけど。


プレーン別・・・

あきよし さんのコメント
 (1998/2/24 14:27:48)

プレーン別に持って、たいした圧縮を行っていない場合は、そんな感じになりますね。

88 とか 98 では、プレーンごとに別のバンク、別のセグメントにあるもので、絵を直接セーブするにはそういう方式しかなかったのです。

「道化師殺人事件」とかでは、同じような方法ながら、連長圧縮を行っていたそうです。(雑誌の技術紹介に書いていた)

このとき、絵によって「縦の構図」と「横の構図」があるため、連長を取る方向を切り替えるビットを持って、圧縮率を上げていたそうです。

「圧縮しようと思ったら、絵を描く段階から圧縮アルゴリズムのことを考えて描かなくてはならない」
ということが描かれていて、感心したものですが、今は圧縮技術の進歩でそんな苦労はなくなりましたね :-)


プレーンごと

mio さんのコメント
 (1998/4/2 14:09:45 -
E-Mail)

 拡大縮小といえば、「シーナ」とか…違うか(^^;

 「シルフィード」の敵キャラの攻撃とかはとてもすごいと思ったし、
グロアールの出現シーンには失神しそうになりました。

 さて、プレーンごとという話ですが、これにはいろいろあります。
画面1枚1枚のデータをそのまま持つ(アセンブラをちょっと使えば
BASICでもできる)と、上から下までべた〜と描かないとだめです
けど、ちょっと工夫して(その分遅くなる)ラインごとに持つように
すれば、青ライン、赤ライン、緑ラインと描くことで、さほど
目立つことなく三画面を描くことができるでしょう。

 ALUが普及すると、このラインごとのデータをまず画面に見えない
VRAMへ転送しておいて(あるいは圧縮されたデータを解凍して)、
3画面同時に転送することによって、完全な同時描画を可能にした
わけです。

 「ソーサリアン」なんかはこの「見えない部分」を増やすために
画面の最下段を黒い■文字で隠して(画面の一部を隠すのに使う
テク)、ここにキャラのデータを置いたりしていました。

 非圧縮だと、展開は高速だけどディスクから読み出すのが遅くなる、
という欠点もあります。このあたりは試行錯誤なのでしょうね。

 そういえば「シルフィード」はキャラクタには2プレーンしか
使っていなかった…。


コメントする


なまえメール
WWW
タイトル
コメント
参考
リンク
ページ名
URL


[HOME] [TOP] [HELP] [FIND]

Mie-BBS v2.14 by Saiey