[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[WitchTech 00640] ご返事ありがとうございました。
先日フレームレート関連で投稿した DAINO^P です。
うえけん様、田中様、おおくぼ様、森光様、ラターシュ様、ＫＯＨ様、
貴重なご意見ありがとうございました。
ワンダースワンの、ソフトウェア・ハードウェアの問題を、色々と考えることができ、
また、このメーリングリスト参加者の実力も確認できましたので、
自分では、収穫は大きかったと思っています。
私は、ワンダーウィッチのプログラムを３日程度の初心者ですので、
今後も何かと質問をすると思いますが、よろしくお願いします。
=========================================================================================
これまでのメールに対しての具体的な返事です。
うえけん様：
>そもそもダブルバッファを前提としたハードではないので、
>ダブルバッファをする必要はありません。やろうとしても
>マシンパワー不足で遅くなるだけです。
>
>どうもスワンのハードウェアを勘違い＆思い込みで使っている
>ような表現だと、元の投稿を読んで感じただけです。私は昔の
>マシンでソフトを作ったことがあるので、ラインバッファ形式
>のマシンでフレームバッファをやりたいとか言われると、
>
>「なんでそんな無駄なことするの？」
>
>と思わずにはいられないのです。
>
>ラインバッファであることをわかっていて、あえて違う方法を
>試してみようとかいうのならわかるんですが、どうもそれすら
>わかっておられないようでしたので。
一応、ワンダースワンのハードは、
マニュアルを見た限りですが、理解しているつもりです。
ただ、果たしてフレームバッファ方式が出来るかどうかを探ることは、
無駄なことなのでしょうか？
私は、どんなことでも無駄だとは思えません。
可能性があればどんなことでも一度は試し、
その結果で、無駄かどうかを判断したいと思っています。
納期など無いホビーですから。
>ついでに書くと、「ＯＯフレームも必要ありません。ＸＸでも
>十分です」とかいう部分は「それはあなたの基準でしょ」とか
>思ってしまうわけです。ゲームを作っていると３０フレームと
>６０フレームの違いがかなりあるもので。
誤解を与えてしまう文章を記載してしまい、申し訳有りません。
もちろん、私の基準です。
今回、フレームバッファの可能性を探ったのは、
リフレッシュレート７５Ｈｚ、クロック３ＭＨｚというスペックに
不安があったからです（＜自分の技術力に不安がある、ということです）。
確かに、バックグラウンドを全て書き換えるのには時間がかかりますが、
フレームレートを下げれば、チィアリングの無い画面切り替えが
可能ではないかと思ったのです。
最も、それが可能だとしても、それを何に使うかは今は考えていません。
あくまで可能性を探っただけです。
重要なことは、ワンダーウィッチはホビーだということだと思います。
定石のある市販ソフト開発ではありません。
何をしようがユーザーの勝手だと思います。
それが最も楽しく重要なことだと思っています。
>まあ、走査線の位置をチェックして、それ以外のキャラを書き換えると
>いう手もありますが、説明が面倒なのでリクエストがあれば。
ＨＳＹＮＣを使用し、スプライトをＹ座標でソートして、
そのスプライトの表示範囲より、走査線が下であれば表示する、
という方法でしょうか？
田中様：
マイコンＢＡＳＩＣマガジンで、ワンダーウィッチのプログラムも
掲載するようになっていますね。
もう５年以上もマイコンＢＡＳＩＣマガジンは読んでいませんでしたが、
最近、また読むようになりました。
バックナンバー等を見ていないのでなんともいえませんが、
DirectX + VB や ワンダーウィッチで一番問題になるのが、
セットアップの煩雑さだと思います。
昔は、電源ＯＮでＲＯＭ−ＢＡＳＩＣが立ち上がったので、
特に説明は不要だったと思いますが。
そのあたりは、定期的に記事を掲載したりして、
初心者もちゃんとフォローしているのでしょうか？
正直、Windows環境が一般化した時、
マイコンＢＡＳＩＣマガジンは廃刊になるのでは？、
と心配したものです。
ワンダーウィッチの記事は期待していますので、がんばって下さい。
おおくぼ様：
>libwwc.h って何? って思ってしまった。カラーライブラリですか。
># せっかくなんで make もマスターしません?
本当に申し訳有りません。
ワンダーウィッチのヘッダファイル・ライブラリも含め、
コンパイルに必要なファイルは、一つのディレクトリに納めるつもりでした。
Make を使わなかった理由は、
自分の環境のみで最低限コンパイル出来る程度の知識しか無い、ということもありますが、
その前に、ワンダーウィッチのセットアップの難しさがあります。
（メーリングリストに参加されている方々には不要のことでした。
．．．しかし、私のように、そうでない人間も参加しているかも）
私自身、ＤＯＳ環境から離れて５年始以上経ち、config.sys Autoexec.bat の書き方は、
きれいさっぱり忘れてしまいました。
実際、マニュアル通りに設定を行っても、
コンベンショナルメモリが 560KB 確保出来ないことや、
ユーザーごとの設定の食い違いで、コンパイルできないことは多々あります。
ですので、TurboC2.0 のパスさえ通っていればコンパイルできるように、
と考えた次第です。
（LSI-C を使えば、誰でもセットアップさえきちんとしていればコンパイルできますが、
一部のソースで、Out of Memory のエラーが発生するため、
やむなく TurboC2.0 にしました。）
ただ、”初心者はワンダーウィッチをすんな”って意見には、
（そういう意見があるとすれば）、全面的に反対です。
>つまり元質問は「どうせ液晶なんだし、垂直同期を 25fps にできないか?」
>という意味? (違うか)
フレームレートが落とせれば、
３ＭＨｚのＣＰＵでも割と無茶な処理もできないか、
という考えからです。
もっとも、フレームレートを落とす為に、
それ以上のリスク（重い処理）を払うのでは、
何にもなりませんけども。
森光様：
>ワンダーウィッチの場合、描画まわりがすべて BIOS に
>ラップされていますので、高速化するポイントが難しいとは
>思います。
そうですね。
だた、私のソース自体が無駄なものばかりなので、
Ｃレベルでの最適化、及びアセンブラ化による最適化を行えば、
現在のプログラムなら、多少は効果はあると思います。
>そういえば、ワンダースワンカラーでは、DMA機能が追加されたと
>記憶しているのですが、ウィッチからは利用できないんですかね?
こういう情報を是非知りたいですね。
メーリングリストに参加するのは、
マニュアルには無い情報を得るのが目的ですから。
ラターシュ様・ＫＯＨ様：
>私はtick_countを見て一定速度にして、
>重い描き換え処理の前に強引にsys_wait(1)を入れていますが、
>他に良い方法ってあるんでしょうか。
これは、書き換えの前の処理が重いということなのでしょうか？
それとも、書き換え処理自体（スプライト１２８個全て書き換えなど）が
重いということなのでしょうか？
>フレームループごとに、今回は敵の移動だけ、
>次回は自機の移動だけって感じで、ゲームループを作ればいいと思います。
自己完結してしまって申し訳有りませんが、
スプライト等はテーブル化して一気に流し込めば、
そうそう重い処理にはならないでしょうから、
これは、書き換えの前の処理が重い場合ですね。
例えば、書き換えの前の処理を２フレームかけて処理し、
その後のＶＢＬＡＮＫで一気に表示を行う、という感じでしょうか？
最後に：
今月のＣ−ＭＡＧＡＺＩＮＥに、ＱＵＴＥの方の記事がのっていました。
紙面で述べられていることは、私も以前から感じていたことでした。
それは、”ホビープログラマを育てる環境が失われている”というものです。
実際は違うのかもしれません。
VisualC++ や VisuaBasic など、お金はかかりますが、
昔に比べ、遙かにホビープログラムも開発しやすくなっています。
よく昔から、勝負に勝つにはハングリー精神が必要、と言われていますが、
優秀な（ゲーム）プログラマが育つには貧相な開発環境が必要、
というのも、１つの回答なのかもしれない、と思いました。
ML Archives