nika管理人nikaへのメッセージなどは上記Twitter等へどうぞ。GTFとCVT(3549)(AT)RTC(2368)BIOS(1675)PlayStation2/VP2(1089)RecentDeleted(818)PV3アーカイブこのページの元はKAODUNのhikiの掲示板(2008年1月ドメイン死亡確認)です。wiki形式に変換して使用しているものです。コメントを投稿する場合、wikiとhikiとの形式の違いに注意してください。自動的にwikiの形式へ変換されたりしません。スパムがうざったいので、一時的に掲示板機能を殺しておきます。掲示板機能をとりあえず復活させておきます。一時的に停止しておきます。画像ファイルを投稿できる場所を作りました。http://com-nika.osask.jp/imgup.phpから投稿できます。管理人しかページに添付ファイルをUploadできない制限を解除しました。添付ファイルリストが表示されない低負荷設計(w)。「思うところがあって、汎用のグラフィックドライバを作ることに。完成したら、今の画面回りをそいつに置き換える予定。」との事ですが、ある程度お手伝い等できるかと思います。良かったらお返事頂ければと思います。概要を乗っけてみますので、ツッコめるところがあったらバシバシツッコんでやってください。自分だけの力でこれをまともに実装しようとすると、とても使い物にならない速度になりそうな気がします...。構想大きいですね、すごいです。力になれないかも(ぉぃ)。着想理由について少し聞きたいです。「パターン」制なのはなぜでしょうか、キャラクタをメモリ転送するのが16(色)種類までだからでしょうか。BG画面はある意味バッファみたいに使うのでしょうか、裏画面がいきなり表になったりするのですか?いまのkaodunのルーチンでかなり出来ているのではないでしょうか。自分は全体の見通しをたてたり分かりやすく書いたりは大変苦手なので、枠組みがあると助かります。バグを除けば実装作業は難しくなさそうですが(自分の技量から見てではなく、感じとして。見通しはたたないんです)。構想としては、bpp24.libと似ている気もします。ありがとうございます。着想理由は、今のkaodun内部での描画処理が「ゲーム処理側から見て」あまり使いやすいものではないと思ったからです。現在kaodunではアイテムの処理を追加しているところなのですが、アイテムを画面に反映させようと考えたときに、各画面(マップ、キャラクタ、暗い部分、ステータス・ウィンドウ)間の関係が把握しづらく面倒になってきたので、もっとゲームを作りやすい画面周りのライブラリを作ってしまおうと思い、作り始めました。一応、上の仕様はスーファミやらX68kやらの画面構成を参考にして決めてみました。パターン制なのは、RPG等ではこの方が扱いやすいと思ったからです。今考え直すと、ゲームによっては直接BG画面を弄れた方が便利かもしれません(格闘ゲームの背景など)。グラフィック画面を廃止して、BG画面を4枚にし、BG画面に「ピクセルモード」と「タイルモード」を設けます。タイルモードでは上のBG画面相当のモードで、ピクセルモードでは、上のグラフィック画面相当の事に加えビットマップ等の転送も加えようかと思います。一括描画関数を呼び出すことによりグラフィックボックスに反映されるようにする予定です。各種情報はアプリ側が用意する変数に保持するようにする予定なので、アプリ側は画面を構成するために変数を弄った後、一括描画関数を呼び出すだけです。裏画面のような存在はありませんし、構成中の画面が表に現れることも無いはずです。実際に画面に反映させるルーチンはkaodunのものを流用する予定です。それをゲームで扱いやすいようにBG画面やスプライトとして提供するのがこのライブラリの趣旨なので。いうか自分の技量ではあの最適化でいっぱいいっぱいです(しかもkタンに高速な半透明処理も書いていただいたし)。(長くなりすぎたので途中で分けた)とりあえず、実際に描画する関数群は揃っているので、確かに実装するのは難しくなさそうです。そのあとに控える高速化が大変かもしれません。構想としては、確かにbpp24と近いものがありそうです。こちらは一応ゲームのためのものという扱いで作りたいと思っています。今のところ、勢いで作った構造体の一部が完成してるので、それと関数の枠が決まったらまたここに載せます。文字描画関数と矩形描画関数はメモリへの転送命令にする。骨組みを完成させました。仕様の変更を上のリストに反映させました。BG画面のパレットはパターン単位ではなく画面単位で設定するようにしました。*/、というのと、予定仕様の(タイル)1パターンのサイズは画面単位で設定可能はぶつかると思うんですが、ここも変更されたのでしょうか、BG画面ごとにループをまわすのと、基本タイルサイズごとにループをまわすのと2通り組んでおこうと思います。(手間はあまり増えないと思う)高速化のときどっちか良さそうな方がありそうです。それから、GSL_BGSCREENの中に使うパレットの設定があるのは、例えば春夏秋冬をパレットを変えるだけで簡単に変えられるから...かな、それならBGごとにパレット持った方がいいかも、あと、パターン毎にパレット持たせるように構造体持つとか...(でも肥大化しますね)少しその辺りの理由がしりたいです。コードは気にせず組んでおきます。分岐がかなり増えそうです。あと、drawptrnに、t,m,tmの種類があるみたいなんですが、最新のkdunとは違うような...指定がないやつと、tは自前描画用なのかな?gsl_drawptrnを使ってグラフィックボックスにすぐに書いてしまう気だったのですが...グラフィックシステム分室欲しいです、中途のソースupしたりとか。勝手に作っていいですか?長文すいません。続きはそちらに書きます。遊んでいただいてどうもです。これからも気の向くままに作っていきたいと思います。スローペースになると思いますが気長に応援してやって下さい。ver.4.7にバンドルさせていただきます。sarアーカイブにして、32.4KBになりました。stk5圧縮したファイルの合計よりもさらに小さくなりましたね。640x480の16bitカラーモードでプレイすると最高に楽しいです。代わりに右斜め上を向くパターンが出ます。遅いマシンでお試しあれ。私はTOWNSでやりました。報告ありがとうございます。そのバグは制作中に遭遇してたので直したと思い込んでたのですが、直ってませんでしたか。次のバージョンで修正しますので、しばしお待ちくださいませ。面白いし、技術的にもすごそう!!あるいてたら落ちてしまったので(なぜか)ここで報告します。OsaskWiki:OSASK_Faultsに原因が載っているみたいですが、もしかするとqemuのタイマー問題かもしれません。んすごい!しかしEPIA-VE5000上のqemuではかなり遅いので(当然なんですが)なんかもっと速くならないものかと思案中。利きそうな関数部分だけをASKAにしようと思っています。効果があるかどうかは分かりませんが。>あるいてたら落ちてしまった。うちではQEMUが上手く動いてくれないので、確認できません...。dung_grp.cは全体的に負担が高い関数が多いです。今は、GOのコンパイルオプションで-O2を指定して最適化しているのですが、それでもTOWNSでコマ送りが限界なので...。先ほどK6-2(450Mhz)マシンでテストしてみましたが、滑らかに動いていました。...ということはうちの環境が貧弱すぎるのかなぁ。qemuが原因っぽいですか...。余裕のある環境でない限り、実機で遊んでほしいです。デバッグも実機でしたもので...。gg00libcのdefsghdl.nasにバグ発見。聖人さんはきっと苦労なさったことでしょう。putbox_transをちょこっといじって、劇的に速くなりました(通路に入っても遅くならない感じ)。ちなみにまだASKAを使っていません。Cレベルでかなり改善できそうなので、まずはそれからやっています。感動したので記念に書き込みを。小柳さんが配布されているVmware用4.4イメージで試してみたところ起動はしましたが矢印キーで何も反応しませんでした。役に立たない情報ですいません。ほんのちょっとだけいじって結構高速化した(と思う)バージョン。良かったら参考にしてください。make済みバイナリも入れておきました。Celeron733でもフルスピードが出るかもしれません。ひげぽんさんこんばんは。キー入力ですが、長く押しつづける必要があるので、その関係でキーが反応しないように思われたのかもしれません。ちなみにこれは斜め移動に対応するための仕様だと思われます。それと、qemuでは動くのでqemuでプレイするのをお勧めいたします(もちろん実機が最高ですが)。Kさんありがとうございます。(高速版)ありがとうございます。試してみた所、Duron機ではLOADFACでわかるほど高速になりました。Celelon733では残念ながらあまり変わりませんでした...。グラフィックカードがネックになっているのかなぁ......。それから、下に降りる時に0007:0003FC1で一般保護違反になってしまったのですが...。STACKSIZEが足らないのでしょうか...(以前、32768Kにしていた時にも似たような事があった)。遊んでいただいてどうもありがとうございます。33MHz)でも確認しているので、多分Kさんの言う通り、キー入力を拾いきれていないのだと思います。QEMUを動かせられないのでQEMUがどういう感じかはわからないのですが、もし時間があるのでしたら実機で遊んでみてほしいです。スタックサイズのせいではなく、もっと深刻な原因だろうと思われます(ざっと見たところスタックを大量に使いそうな理由がないので)。ポインタが狂っているとかそういう可能性を全てつぶしてから、スタックを広げるようにしてください。今日はちょっとできないので、明日原因を探ってみます。私もqemuで自作アプリを動かしてたら遭遇しました。タイマーをstartする前にstopして回避してます。なんか悔しい解決ですが。実は聖人さんのRPGの場合、まさにタイマをstartする直前に念のためにstopするコードが入っているのです。それなのにエラーになるんです。qemu側の問題である可能性が濃厚ですが、OSASK側のバグの可能性もあります。少なくともアプリ側のバグではないと思います。ナオミさんが動くのかぁ。