1155kis00283ひゅう 1996/10/19 19:02:21 前へ 後へ 上へ

Re:次世代KISSについて

1151へのコメント

どうも、ひゅうです。

MIO.Hさんの発言の引用です。
| ・セルファイル等で小さなファイルが数多くできるのは良くないので、まとめた形の

|  データ構造をザポートする。
| ・上記とも関連して、CNF はバイナリ化する。

ををを、CNFバイナリ化!!
噂には聞いてましたが、
MIO.Hさんがこの考え方を示した意義はかなり大きいと思います。


データのアーカイブはどんなふうにやるのがいいのでしょうね。
CNFバイナリ化も含めるということですので、
単に、tarしただけのものではなさそうですね。

じつは、わたしは、セルファイルなどをまとめる場合でも、
CNFは別ファイルでテキストファイルのままにしておくことを考えていました。
理由は、3点。
(1)バイナリ化すると、周辺ツールがないと何もできなくなってしまう。
(2)気軽に修正ができない。
(3)差分データはどうするの?

しかし、今のように、KISSを大きく拡張しようとしているのであれば、
(1)に関しては、どうせ必要になるのだし、特に問題ではないかもしれません。
逆に、やるなら、今です。
(2)は、ツールさえ準備できれば、問題無しです。
これを踏まえてですが、規格の制定に当たっては、
まだ議論中だあったり、草稿であってもできるだけ早い段階で、
その内容をKISSin'などのネット上で公開して、
情報をK.O.S.以外のローダー・ツール作者に与えて頂きたいです。
私もできる範囲内で協力します。
(3)ですが、KISSの特性上、差分をサポートすることは
必要だと考えています。
なんらかの考慮が必要です。
たとえば、新規格のKISSファイルに含まれているセルを、
新規格の他のKISSファイルから呼び出せるようにする機構を
つけるとかね。

ただ、これを付けると、私が前々からやりたいと思ってる、
セルファイル名を無くす!
ってことと両立が難しいんだよなぁ。
せっかく、セル・パレット・ CNFを1つにまとめるんだから、
セル名・パレットのファイル名情報は捨てちゃってもいいんだけど、
そうすると、差分から呼び出すときに、
差分KISS側から、セルを番号で指定する必要が出てきちゃう。

あと、一つにまとめたものを、
また個々のCELファイルとかに分けることができるようにするかどうか
ってのも難しいところですね。

さらに、簡単な圧縮をかけるかどうかも問題。
圧縮をかけないのなら、
どうせLZHのまま管理することになって、
現LZH直視と大して変わらない…って言われちゃうかも。

複数CNFの切り替えも、サポートして欲しいところ。
特に、そのデータのスペックによって、自動的にCNFを
選ぶ機能があったらスゴイかも!
#例えば、ローダーが動画対応かどうかでCNFを分けるとかね。

…と、思い付く意見や・問題点をいろいろ書きましたが、
メリットは大きいです。

CNFバイナリ化及びファイルのアーカイブ、賛成です。


-----------

ちょっと話はそれますが、

EWIGKEITさんの発言とそれに対するMARSさんのレスの引用です。
| で、まず私の勘違いの暴露
| fkissって実験中だからって、FKISSデータ創るの控えなきゃいけない、
| アップロードは、あまり目立つとこでやっちゃいけないって思ってた
| のは、もしかして私の勘違いなのね(^^;;;ナンデ コンナ カンチガイ シタンダロ

データを作るのは、絶対に自由だし、
それを広めるのも自由だと思います、私は。
だだ、fkissが正式なKISS/GS仕様ではないこと、
将来のKISS/GSではこのままサポートされない可能性があることが、
伝わるようにしたほうが良いと思う…ってくらいかなぁ。

でも、将来サポートされなくなるというリスクはありますから、
データ作者は、それを覚悟の上で、公開してるんだと考えています。

MIO.Hさんの発言の引用です。
| ・fkissはどうしよう?
|  (機能的な拡張はfkissで実験されてることのようです。fkissの
|  上位拡張にはならないとは思いますが、既に多くのデータが出回ってるよう
|  ですし・・・。う〜ん、どうしよう・・・。)

万一、新KISS/GS仕様が現fkiss仕様によって
良くない方向へ引きずられることがあったらそれは本末転倒です。
現在のfkissの素晴らしい機能(たくさんあります!)を吸収し、
必要でない部分は捨てて、
まったく新しい形で作り上げて欲しいと希望します。
#↑CNFをバイナリ化するのであれば…の話です。

そのまま上位互換は、有り得ないと思いますが、
出来る範囲でのfkiss→新仕様コンバーターは作られると思いますしね。
#yavさんがソース付きで作ってくださると、勝手に期待してます ^^;
#お忙しいようでしたら、私が作りますし。

極論ですが、現fkiss拡張対応のローダーも、
新仕様対応後は、現fkiss拡張対応をやめるくらいのつもりであったほうが、
新仕様への移行が、よりスムーズになるのではないかと思います。
#これは、 fkissの作者であるyavさん、対応ローダーを作られている方々、
#fkiss対応データを作られている方々、及びそのユーザーの方々に対して、
#大変失礼な言い草です。お気に障りましたらごめんなさい。


新仕様の動画、音声等は、
CNFをバイナリ化するなら、かなり凝ったことまで出来そうですね!!
これは、超期待してます〜!

----------

MIO.Hさんの発言の引用です。
| ・取り残されるマシンはあるだろうが、フォロー出来るところはしたい。

これは是非お願いします。


これに関して、ちょっと思うのですが、
現在のGSランクのような記述では、
データのスペックをあらわすのは難しいように思います。
この作品は、この環境(ローダー)で遊べるのか?
ということを判断する、新しい方法が必要になりますね。

今までの、色数、画面サイズ、セル数に加えて、
動画サポート、音声サポート、
さらには、もっとあたらしい機能が追加されていくかもしれません。
これらも含めて、データのスペックの表記を定めないといけませんね。

それと、私からは、特に、
半透明やフルカラーのサポートもお願いしておきます。

現在のckissの仕様は、まったく無視してくださってかまいません。
要は、半透明なセルや、フルカラーなセルで遊べるようになったら
それでいいのです。

特に、セル全体を半透明にする機能 (ckissでいうところの ;%t) は
個人的に欲しいんです〜。

あと、フルカラーセルは、
素晴らしいフルカラーCG描きさんをKISSに取り込むという意味で、
重要だと考えています。
#最近、Photoshopとかをいじる機会があったんですが、
#お絵かきがすごく楽な感じがしました。
#もちろん、16/256色で素晴らしい作品は多いです!
#が、そればお絵かきとは別に、
#ドットやタイルを操る特殊技術が必要となります。
#フルカラーだとそんなことを考えなくてもいいし、
#それなりのツールを使えばお絵かきがメチャ楽なので、
#セミプロ級の素晴らしい技術をもったCG作家さんの多くが、
#フルカラー環境になっているように思います。

yavさんが言われた、サーバー・クライアント方式での問題
に関しては、よくわかりません。
もし、宜しければ、お時間のあるときで結構ですから、
解説していだだけると嬉しいです  > yavさん

------------

最後に、新仕様に対して、一番強くお願いしたいことは、
ぜひ拡張性を最重要視してください
ってことです。

新仕様を追加するたびに、いちいち混乱が起きていては
面倒くさいですからね。

具体的には、

旧仕様に基づいたローダーで、新仕様対応のデータをロードしても、
出来るだけ不具合が起きないように考慮して欲しいとか。
#今のfkissで動画をやろうとします。すると、動きのセルを
#全部用意しておいて、それをまずunmapして隠しておいて、
#タイマーで順に1つずつ見せていくわけですが、
#fkissに対応していない、ローダーで見ると、
#その動きのセルがすべて同時に表示されて、カッコワルイのです。
#なんか、ネタがばれちゃった…って感じでね。

未知のコマンドや処理できないコマンドの場合、
(例えば、ローダーが、動画、音声などに非対応であった場合)
それをどう処理すべきかも定めて欲しいです。
さらに将来、新機能を追加するときにもこれがあると便利です。
これは、fkissを例に出すなら、新しいイベントを追加したら、
そのイベントを認識していないローダーは、そのイベントにぶら下がっている
コマンドを含めてすべてを無視する…というふうに
インプリメントされるべきであり、それがちゃんと仕様に入っていて欲しい
ってことです。
#バイナリ化された場合どうなるのかちょっと見当が付きませんが。

今の、KISS/GSでも、
GSヘッダーは、将来への拡張として、予約領域が設けられていますが、
さらに一歩進んで、バイナリ化されたCNFヘッダー部を可変長にして欲しい。
将来追加されるであろう項目について予想するのは不可能ですし、
どういう場合でも対応できるように、多少冗長でも良いと思っています。
さらに進んで、各データフィールドに名前を付けられるようにして、
将来、拡張実験などをしやすくなってるともっといいなぁと思います。
#…けど独自拡張が乱立しちゃって困ったりして ^^;

拡張性に関しては、他にも考えられると思いますが、
まぁ、KISS/GSなどをみても、いろいろ考えてくださってますし、
K.O.S.はきっといいものを考えてくださるに違いない!
と、期待してます。

あ、正式発表前に、途中段階でも結構ですから、
どんな感じなのかアナウンスとかもお願いしますね!

どっちかというと、もっと気軽に、
ここはこんな仕様でどうかなぁ…って感じで、
KISSin'に書いてもらえると嬉しいなぁ。


以上、また勝手なことを書かせて頂きました。
長文失礼しました。

 HYuu

No Java Java

前へ 後へ 上へ