■ 予定とは言い難い
実現するかどうかは別にして、書いてみたいこと等、いろいろ。
頭の中のごちゃごちゃをそのまま個条書きで吐き出したりしているので、読んでもわけが判らないかも（＾＾；。
■ 走矢灯ドット店…ドット絵のページ (98/10/9)
・バナー(200*40)
・CGサーチエンジンTINAMIのプレビュー(80*80)
プレビューを差し替えようとすると再登録が要るのがちょっと面倒。
<META NAME="chieri-preview" CONTENT="http://www.provider.ne.jp/~homepage/preview.jpg">
…みたいにプレビュー画像の変更が出来れば面白いんですが。
・ARTCLOCK(110*110)…Win用。背景画差し替え可能な時計ソフト。
好きな絵の付いた時計がほしいと思っても、現実に時計を特注したりするのは大変です。でもこれだと110*110のBMPを登録するだけで出来てしまいます。パソコンならではの利点を生かしたソフトと言えるでしょう。最初から付属してくる絵もきれいです。
【ARTCLOCK/あっぷるCANDY】 【フレーム無し】
・小さな壁紙（繰り返し表示用）
・MSXCGコーナーと統合するかも
■ フリーソフトウェアでＣＧを描こう（仮称） (98/10/9)
・ネーミングが難しい…「普段は市販ソフトで描いてるのにわざわざＦＳＷで描く」コーナーとは思われたくないから。
・動機
・「CGはまず高いツール買わないと話にならない」風潮
・Photoshop等、機能で売れている以外に、ブランド信仰で売れている部分も
・ユーザーの負担だけでなく、グラフィックツールの開発意欲を削いでないか？
・芸術家が金に糸目を付けないのは勝手。
・しかし趣味としてのＣＧ文化はどうなる。
・ＣＧ入門者にとって大きな敷居に。
・金にものを言わせたＣＧ（失礼）に負けたくないという気持ちも正直強い（そりゃ高いツール使えばいい絵が描けると言うものではないと言うことは百も承知）。
・何が必要か。方向性は
・フリーのＣＧツール紹介＆リンク集
・入門者にとってのガイドラインとして使えるようにするには？
・単に紹介を書いてると、ついツールへの不満や要望が中心になってしまう。
・確かにＣＧツールに対する提言はしたいのだが…
・それが描く人にとって役に立つかが問題
・こういうのが描けるというサンプルも要る
・自分で描いたものだけでは数不足（画力もか）。
・ので、フリーのツールで描かれたＣＧへのリンク集も。
・しかしそれでも数が少ない
・対象をＣＧ入門者にしぼるのか？
■ プログラム開発関係（主にアセンブラ） (98/10/9)
・PGBRK(開発中の自動見出し解析ぺージャー)を早く公開したい。
・完成度が低いうちに公開すると印象を悪くする
・急がば回れ
・とは言え遠回りにも限度がある
・期日を決めてしまうか？
・PGBRKの制作はちょっと行き詰まっている
・表示ルーチンに手こずっている
・解析ルーチンは10日あればそれなりに出来そう
・開発を楽にしたい
・エディタ(JED)のコメント一覧（自作マクロによる）がやたら遅くなってきた
・モバの最高速モードなら少しは速くなる
・が、電池を食う
・マクロを組み直す
・Elisに乗り換える手も
・プログラムソースがすっきりしない
・新しいアセンブラかプリプロセッサを作りたい
・特にレジスタを２つつなげたのを見掛け上32bitレジスタのように書きたい
・プリプロセッサの場合
・現在Perlでif文もどきだけ作っている
・疑似32bitルーチンも組み入れればさらに遅くなりそう
・現在既に３秒ほど掛かっている
・出来ればアセンブラで書いて高速化したい
・が、ややこしい。
・構文解析の必要があるのでは
・だとしたらいっそのことアセンブラ作ってしまうほうがいい？
・アセンブラの場合
・アセンブルがいい加減遅くなってきているので速くしたい
・COMファイル専用にすれば結構速くなりそう
・開発言語を同梱出来るのは魅力
・しかし作るのが大変そう
・どうやってデバッグする？
・逆アセンブラを使う
・callの後にdbくっつけの場合、逆アセンブルが効きにくい
・@readlineをマルチセグメント化する必要もある
・もっと簡単に出来そうなものから手がけたくなる
・MGのカーソル形状補正TSR（とりあえず出来たが不具合あり）
・MGの簡易省電力TSR
・ホームページのモバイルギアコーナーの足しにもなる
・でもTSRの作り方はよく判ってない
・常駐パレットが参考になりそう
・汎用の常駐確認ルーチンがあったら便利かも（一応出来た）
・UMBに常駐している場合のチェック方法は判らない
・【VFAT BIOS】が参考になる？
（DOSからVFATを扱うルーチンを含んだ常駐ソフト）
・@printルーチンの強化
・文字列表示、レジスタ10進/16進表示が別々になっているのを統合したい
・現在標準出力しか出来ない
・メモリ出力も出来るようにしたい
・プリプロセッサ作成のためにも必要
・出来ればVRAM出力もサポートしたい
・１文字出力毎に判定分岐すればスピードが落ちる
・別々に組むとコードサイズが増える
・とりあえずメモリに出力して後で転送だとバッファが要る
・出来るだけ手軽に使えるルーチンにしたい
・セグメント切り換えは避けたい
■ アマチュアソフト普及戦略会議 (98/10/9)
オンラインソフト、中でもツールの類は自分で使うのが主目的なことが多いでしょう。とは言え使って初めて意味があるのがソフトですから、公開する以上は沢山の人に使ってほしいというのも人情だと思います。また、アーカイバのように、普及しないと存在意義自体薄らいでしまうものもあります。オンラインソフトの作者にとって、ソフトの普及戦略は興味のあるところではないでしょうか。
勿論大切なのはまず内容です。内容も伴わないのに普及させてしまうのは戦略でなく詐欺です。しかし、アマチュア制作ソフトと言うのは、内容相応の普及でさえ結構難しいものです。ＦＳＷが、それより出来の悪く値段も高い市販ソフトに勝てないこともざらなのですから。
今までの普及したオンラインソフトの例を参考にしながら普及戦略を考えていくページです。
・掲示板が要る
・ソフトの普及だけでなく、規格（画像フォーマットなど）の普及も考える。
・それによるソフトの使用環境/開発環境の改善
・DOSに常駐クリップボードがあって沢山対応ソフトが出てたら便利だったはず…
■ Webの掲示板を考える (98/10/9)
・Web掲示板はnewsやメーリングリストに比べ、参加も運営も手軽
・しかし、オートパイロットやログ管理、オフ書き環境が整ってない
・そのためのソフトを考える
・バッチファイル＋wgetのオートパイロットを使用中。
・Perlのsocketでオートパイロットや自動書き込みは出来るはず。
・ログカッターもPerlで作れるはず。
・ヘッダ形式がまちまちだが、大抵<HR>が区切りなので解析は出来そう
・Perlで作るとユーザーインターフェース部分は弱くなる
・メール受信もまとめて自動化したい（ついチェックさぼりがちになる）
・掲示板側で考えられる点も
・パソ通との互換性のある形にすれば便利
・HTMLとしても読め、そのままプレーンテキストとしても、パソ通のオフ書きツールでもそれなりに読めるように
・<PRE>ではさめばある程度は可能
・ペースト記号の>は書き込み時に全角変換しまえば何とか読める
・NETCOCKのようにヘッダに<や>を含む形式の出力は出来ない
・<XMP>を使えば一番簡単だが、最近のHTML仕様からは外れる。
・オフ書きツールのUP/PADファイルをたたき込めば、連続書き等が出来る送信フォーム。
・掲示板を自作して、実践的に提言したい
・うちのページも一方通行でなく双方向化したい
・反面、何書かれるか不安(^^;;;
・オンライン派とオフライン派の相互理解の難しさ
・思考回路の違い
・文章書くのに試行錯誤が要るか
・カット＆ペーストがないと文章書けない人、平気な人
・Webの送信フォームはカット＆ペーストは出来るが…
・読む←→書く、の切り換えやそのタイムラグに頭がついて行けるか
・姿勢の違い
・書き込みは会話か文章か？
・ログを取る人、取らない人（会話なら毎回録音しようとは思わない）
・反オートパイロット感情
・確かにサーバーの負担を考えずファイルリクエスト出しまくるなど、行儀の悪いオートパイロットソフトも多いが…
・オンライン/オフラインの適性とは別に、電話料金や回線の制約という要素が
パソ通時代、オンライン派がオンラインアクセスし、オフライン派がオフラインでアクセスしていたならまだ話は簡単だったのです。
が、現実には「オフラインアクセスしたいが、オフ書きツールやマクロの設定がよく判らないので、仕方なくオンラインで使っている」人や、「オンラインアクセスしたいが、電話料金や回線占有への配慮のため、泣く泣くオフラインで使っている」人がかなり居たようで、これが話をややこしくしている一因な気がします。
走矢灯 今後の展望 （PROSPECT.HTM） 設置:98/10/9
【戻る】