■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ ■　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　■ ■　　ＧＲＡＰＨ．ＬＩＢパワーアップ計画　どりゃ！！！！　　　　　　■ ■　　ついに発動！？　『　Ｓ−ＯＳ　ＣＧＡ　ＳＹＳＴＥＭ　』　　　　■ ■　　 改め『　S-OS　こてこて　ｱﾆﾒｰｼｮﾝ・ﾛｸﾞ・ｱｳﾄﾌﾟｯﾄ・ｼｽﾃﾑ　』　　　■ ■　　　Ｓ−ＫＡＬＧＯ　system　ｖｅｒ　０．００　完成！！！　　　　■ ■　　　　　　　　　　　　Ｓ−ＯＳ　Ｕ.Ｃ.　＃１５６　黒木　淳一　　■ ■　　　　　　　　　　　　　　　　　　　　　１９９４／０２／２３　　■ ■　　　　　　　　　　　　　　　　　　改め　１９９４／０９／１０　　■ ■　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　■ ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ ●　それはある１月の１１日・・・ 　　私は「ぷうたろう」になった。ひまだ。ひまだ。ひまひまひまひまひまだ。 　面接を受けた会社は面接の会社側の反応からしてまず不採用だろう。そんな 　気がしてた。実際には不採用だった。やはり今の小さなゲーム会社は技術力 　がかなりないと苦しい様だ。今のゲーム業界には私のはいる隙間はないのや 　ろか？うーん、入りたいな。入りたいな。え？　普通免許？　もってへん。 　何！？　普通免許ないとどこの会社もはいられへんの？　うーん、とうとう 　チャリンカーを卒業せなあかんのかー。うーん、私の「世間知らず」「勉強 　不足」であった。でも「不採用」の原因は「技術力不足」やな。しゃーない 　なー。まあ、いま「ぷうたろう」やし普通免許をとるチャンスは今しか無い 　がやろね（お前、どこの出身やねん）。え？　今から申し込むと４月か５月 　ぐらいに回される！？　げげげんちょ！　 　　では、そろそろ本番いきましょう。２月１１日。その日私は森さんと東京 　で行われた「Ｓ−ＯＳ　ＵＣ　関東ミーティング」　へ出席してたのでした。 　うう。森さんに交通費を出していただいてなんといってよいのやら、うるう 　る。残念ながらＸ平研の深谷さんには会えませんでした。とりあえず、いま 　まで私が考えていた　ＭＡＧＩＣ　と　Ｓ−ＯＳ　を核にして構築しようと 　している『　Ｓ−ＯＳ　ＣＧＡ　ＳＹＳＴＥＭ　』の概要を発表したのでし 　た。いい出した以上、言いだしっぺには逃避権は無い。もう前に進むしかな 　い。そうだそうだ、以前『ＭＡＧＩＣ開発キット』の受け付けを始めたが、 　申し込み者は一人しかいなかった。うるうる。うるうる。待っても誰も応募 　してくれん。しかたがない。このままつっぱしろう。とりあえず『　第５回 　ＣＧＡ　コンテスト　』　では１カット部門で選外だったが、試写会にきた 　人達の目にいれる作戦（その頃は全然そんなこと考えてなかった。なんてい 　いかげんな）は成功した（なんだかなあ）。今年の『　第６回　・・・　』 　では４カット部門に応募した。が、「これは選外になると思いますよ。」と、 　スタッフの人に言われてしまった。うるうる。だあれえかあ、手伝ってよお。 　暇無いんだもん。うるうる。ええい！！！　鳴くな！！！　 　と、ここらへんで亞保な話はやめてそろそろ概要の説明をします。尚、この 　仕様は、この会議で色々話し合った結果、まとめられたものです　Ｓ−ＯＳ 　ＵＣ　の皆様に感謝します。 ●　なに？これ 　さて、上の文章は、いまから約数ヶ月前のものです。うぅ、時の流れがつい 　にアニメ−ション・システムの第１バ−ジョンを可能にしました。結構バグ 　りますが、なんとか、アニメ−ションをやるには必要最低限の物ができまし 　た。と、いうわけで、これからの文章は約数ヶ月前の物になりますが、内容 には全然変更が無いので、このままつづけます。 注意）　※マ−クのつく部分は、まだサポ−トされていません。 ●　概要 　　さて、一体どうやって、アニメーション・データの編集をするのかという 　と、実は今までと全く変わり有りません。鳥さんをくるくる回したプログラ 　ム（ＧＲＡＰＨ．ＬＩＢ　使用）がありましたよね。あのプログラムにおよ 　そ２行ほどの付け加えをするだけでいいのです。具体的にいうと、 　１：ＳＬＡＮＧと、ＧＲＡＰＨ．ＬＩＢを使用し、アニメーションソフトを 　　　を作る。Ｏ−ＥＤＩＴで作ったデータをＭＯＤＣＮＶでＳＬＡＮＧのソ 　　　ースリストに変換して、そのキャラクタが画面の奥から手前へ向かって 　　　飛んでくるデモ等をつくっても、ただのラインが画面内をくるくる飛び 　　　回るデモだって、かまいません。ＧＲＡＰＨ．ＬＩＢを必ず介してグラ 　　　フィックのデモを作ればいいのです。そして、納得がいくまで何度も動 　　　きを直してソースを書き直します。この辺は、ＳＬＡＮＧでゲームを作 　　　り慣れてる方には割となじみやすいと思います。 　２：気に入ったカットができれば、今度は定数　＿ＳＯＳＣＧＡ　に１をセ 　　　ットし、再コンパイルします。次に実行する時は、ＧＲＡＰＨ．ＬＩＢ 　　　がＭＡＧＩＣに転送するコマンドを常に監視し、随時ＭＡＧＩＣへのデ 　　　ータをファイルへ書き出してくれます。そして、そのデータは、Ｃ言語 　　　の様なＭＡＧＩＣ言語への変換が可能（※）で、ＬＩＮＥを引く命令は 　　　そのまま’ＬＩＮＥ’と記述されます。そして、エディタでの修正が可 　　　能になります。修正が終われば又ＭＡＧＩＣだけが理解出来るＧＭＬ 　　　（グラフィック・マクロ・ランゲージ）へと再コンパイルされていくの 　　　です（※）。 　３：アニメーションデータは、そのままでは膨大な量になるので、圧縮がか 　　　けられます。どんな圧縮かといいますと・・・ 　　　１）２本の線を引いたとき、偶然つながって一本の線にみえる時（折れ 　　　　　曲がっててもＭＡＧＩＣは折れ曲がっている時の指定ができるから 　　　　　問題無し）、本当に一本の線にする（※）。 　　　　　［　圧縮前　］ 　　　　　　　例　ＭＡＧＩＣ言語 　　　　　　　　　　ＬＩＮＥ（０，０，１００，１００） 　　　　　　　　　　ＬＩＮＥ（１００，１００，２００，１００） 　　　　　　　　　グラフィック・マクロ・ランゲージ 　　　　　　　　　　００　０２　００　００　００　００　６４　００ 　　　　　　　　　　６４　００　０Ｆ　００　０２　６４　００　６４ 　　　　　　　　　　００　Ｃ８　００　６４　００　０Ｆ 　　　　　［　圧縮後　］ 　　　　　　　例　ＭＡＧＩＣ言語 　　　　　　　　　　ＬＩＮＥ（０，０，１００，１００，２００，１００） 　　　　　　　　　グラフィック・マクロ・ランゲージ 　　　　　　　　　　００　０３　００　００　００　００　６４　００ 　　　　　　　　　　６４　００　Ｃ８　００　６４　００　０Ｆ 　　　　　上の例では、たった一本線が減っただけだが、７バイト減った事に 　　　　　なる。７バイト減っただけで処理速度の差はでかい。あと、線がつ 　　　　　ながってなくてもだいたいの目安でつながったとみなす係数を設定 　　　　　できればかなりの高速化につながる筈、ただ、心配なのは、圧縮時 　　　　　の処理速度とメモリ空間の問題である。そもそもポリゴンでは処理 　　　　　が遅いと私が勝手に決めつけてワイヤーフレームオンリーなのだが、 　　　　　この圧縮処理だけで時間を食いすぎると、結局ポリゴンの描画速度 　　　　　と変わらなくなる。これではポリゴンにくらべて速度が早いという 　　　　　メリットが消えてしまう（AYANYさんはポリゴンだって十分アニメで 　　　　　きるといっている。うーむ、やはり、私の技術力が足らんのか）。 　　　　　ここは、どこらへんまで圧縮をかけるか、と言うところがポイント 　　　　　であると私は睨んでいる。 　　　２）トライアングル、ボックスの裏に描画されたデータは削除する。こ 　　　　　の圧縮も、やはりユーザーが指定できる様にするべきだろう。何故 　　　　　なら、ボックスの陰に隠れたラインをユーザーがふんふんふん。と、 　　　　　鼻歌まじりにボックスの前にもってこようと、ＭＡＧＩＣ言語で編 　　　　　集する恐れがあるからだ。さあ、どうする？てなもんだ（※）。 　　　３）一定領域外のデータを消去する。これもやはりユーザー指定なのか 　　　　　もしれない。上の様な事を考えていると、どのデータもユーザーが 　　　　　使うかも知れないデータデあり、私の一存では勝手に決定できない 　　　　　のだ。ここまでユーザー指定なら、もはや環境ファイルを設定しな 　　　　　いと、ある一定レベルで勝手に圧縮をかけちゃうよなのだ。いわゆ 　　　　　る「デフォルト」ってやつですか。当然デフォルトであるからには 　　　　　圧縮率も一番妥当な数値を割り出す必要がありそうだ。それにして 　　　　　もこの一定領域外データの消去というのは結構強力な圧縮になりそ 　　　　　うだ、人の目は、ある場所に釘付けになったらそれ以外の場所がき 　　　　　えててもなんとも思わない筈だからだ（デンパソフトが移植したキ 　　　　　ャメルトライが良い例だと思う。あのゲームは、ボールが下に落ち 　　　　　ていくから画面真ん中と下に釘付けだもん）。 　４：いよいよ再生だが、オンメモリ＋ディスクドライブから随時読みだし形 　　　式でいこうと思う（ＭＡＧＩＣ言語とか、ディスク入力形式は、HARIMA 　　　WOさん、Ｏｈ！石さんからの助言です。ありがとうございます。ちなみ 　　　にこのあと、この二人がどんどん話をすすめて盛り上げて行き、私が全 　　　然話についていけなくなった。うー、勉強不足だ）。６４０Ｋメモリボ 　　　ードをラムドライブにすると、速度が全然落ちない。と思う。とりあえ 　　　ず今はＦＤから入力する様に作ればいづれ後々楽でしょう。 　　というわけで、以上が概要です。簡単な図で、作業を表現してみました。 第１段階　［　動画像の作成（ＧＲＡＰＨ．ＬＩＢでアニメ・デモを 　　　　　　　作る）　］ 第二段階　［　気に入らない（第一段階に戻る）　］ 第三段階　［　気に入る（そのまま）　］ 第四段階　［　もっとかっこよくする（第一段階へ戻る）　］ 第五段階　［　＿ＳＯＳＣＧＡ　に　１をセットして再コンパイル　］ 第六段階　［　実行（ファイルへ自動的に画像データが出力される。 　　　　　　　勿論、コマの切り替わり等、全て再現できる様になる 　　　　　　　筈。但し、ＧＲＡＰＨ．ＬＩＢを介して表示された画 　　　　　　　像に限る。）　］ 第七段階　［　オブジェクト→テキスト変換　（ＭＡＧＩＣ言語への 　　　　　　　変換）　］（まだ出来ません。） 第八段階　［　編集（画像データを手動で編集）　］（出来ません） 第九段階　［　テキスト→オブジェクト変換　（ＭＡＧＩＣ言語から 　　　　　　　ＧＭＬ（グラフィック・マクロ・ランゲージ（ＭＡＧ 　　　　　　　ＩＣが直接解釈できる言語である。基本的にバイナリ 　　　　　　　ファイルである）））　］（出来ません） 第十段階　［　再生（ＧＭＬを読み込みながら、画面へ足れ流しする。 　　　　　　　しかし、裏画面切り替え情報等全てＧＭＬに変換でき 　　　　　　　ている筈なので、なんら問題は無い筈だ、いずれ、タ 　　　　　　　イムチャート等を使ってもっとメモリ活用を有効にし 　　　　　　　たいが、基本的にＱＵＥ（キュー）方式（キュー方式 　　　　　　　とは、入力されてきたデータはバッファに入力されて 　　　　　　　きた順番にすてられていくので面倒くさい。ＱＵＥ方 　　　　　　　式以外に良い方法無いもんでしょうか？）なので、今 　　　　　　　の所未対応です。いずれにしてもＳＬＡＮＧ上でルー 　　　　　　　プによる時間稼ぎは無意味なので、これは早急に対応 　　　　　　　すべきだろう。それと、ＭＡＧＩＣ言語コンパチの処 　　　　　　　理系は恐ろしく簡単なので、ＭＡＧＩＣの無い機種で 　　　　　　　も簡単に再生できる筈。あ、そうそう。ＭＡＧＩＣの 　　　　　　　ある機種といえば、６８のＭＡＧＩＣとコンパチだっ 　　　　　　　たよな。う〜ん、素晴らしい。６８でも再生できるぞ。） 　　以上が概要のまとめです。現在試験的に第十段階までいってます。しかし、 　いかんせん突貫工事の為、その間の所々がぬけてます。さあ、みんな、今の 　内にＧＲＡＰＨ．ＬＩＢを使ったアニメーション・デモを作ろう。このシス 　テムのバージョン１では、上の機能を網羅できている筈なので、２、３行の 　変更で　ＣＧＡ　ＳＹＳＴＥＭ　上でのアニメが可能になる！！！　さあ、 　「　ＤＯＧＡ　アマチュア　ＣＧＡ　コンテスト　」をワイアーフレームで 　騒がせようぜ！！！　（ポリゴンでもいいけど） ●　速報！！！ 　　早い！！速い！！ポリゴンが早い！！！以前のＧＲＡＰＨ．ＬＩＢと比べ 　て４倍以上動く！！　誰だ！！改造したのは！！！　あの強者集団Ｌｏｖ− 　−ｅｒ′ｓのAYANYさんだ！！　奴ぁやるぜ！！！　これから要チェックだ。 　というわけで、ＧＲＡＰＨ．ＬＩＢス−パ−ライトを次号で掲載予定。 　内容盛り沢山のポリゴン三昧。飛ぶスタ−クル−◎−、うなるレ−ザ−、 　超かっこいい巨大戦闘機がところ狭しと高速に跳ね回る（予定）。 　あくまでも予定。でも早いのだけは本当。これまでのライブラリと比べて 　完全上位互換。しかも、浮動小数点演算パッケ−ジがいらない。凄いぜ。 ●　終わりに 　　しかし、最初上野駅から降りて一言。「おおおぉぉーーー。これが東京か 　あぁぁーー。」お前は田舎物か！！！！　お後がよろしいようで。 (EOF)