このページの元はKAODUNのhikiの掲示板(2008年1月ドメイン死亡確認)です。wiki形式に変換して使用しているものです。
コメントを投稿する場合、wikiとhikiとの形式の違いに注意してください。自動的にwikiの形式へ変換されたりしません。
スパムがうざったいので、一時的に掲示板機能を殺しておきます。
by 聖人
- 掲示板機能をとりあえず復活させておきます。 by nika
- 2012/01/03 追記: 一時的に停止しておきます。 by nika
KAODUN Ver0.2の感想スレ - nika (2006-10-10 (火) 01:04:45) †
Ver0.2の動作報告・感想・要望はここに書くべ!
このwikiへの要望とか用スレ - nika (2006-10-10 (火) 01:07:03) †
wikiやプラグインとかに関する要望とかはここへ!
- 2006-11-09 (木) 13:13:00 nika : 画像ファイルを投稿できる場所を作りました。http://com-nika.osask.jp/imgup.phpから投稿できます。
- 2006-11-09 (木) 16:57:57 nika : 管理人しかページに添付ファイルをUploadできない制限を解除しました。しかも添付ファイルリストが表示されない低負荷設計(w)。
グラフィックドライバ - くーみん (2005-03-15 (火) 19:35:37) †
「思うところがあって、汎用のグラフィックドライバを作ることに。完成したら、今の画面回りをそいつに置き換える予定。」
との事ですが、ある程度お手伝い等できるかと思います。
良かったらお返事頂ければと思います。
- 2005-03-16 (水) 19:10:48 聖人 : どうもありがとうございます! とりあえず概要を乗っけてみますので、ツッコめるところがあったらバシバシツッコんでやってください。
グラフィックシステムライブラリ予定仕様
16bit(15bit)カラー専用
グラフィックボックスに描画
実画面/仮想画面サイズ可変(但し8dot単位)
BG/SP共通で1パターンのサイズを設定可能(8*8,16*16,32*32のいずれか)
登録可能なパターン数は可変
1パターンで利用可能な色数は任意の16色
登録可能なパレット数は可変
パレットの中の#0は透過色扱い
パターン/パレットはBG/SP共通
BG画面最大4枚
2つのモード(タイルモードとピクセルモード)
(タイル)1パターンのサイズは画面単位で設定可能
(タイル)画面単位にパレット設定可能
(ピクセル)各種描画命令(日本語16dot文字描画、8*8or16*16or32*32ブロック転送)
(ピクセル)このモードでは真っ黒(0,0,0)が透明色扱い
スクロール可能
画面単位で属性設定(半透明、任意の画面とのマスク)
SP画面1枚
スプライト毎に表示/非表示を設定可能
画面単位でプライオリティ設定可能
パターン単位にパレット設定可能
画面全体にモザイク,フェード可能(0~31の範囲)
目標
比較的扱いやすい
目指せスーファミ!
TOWNSでも快適
- 2005-03-16 (水) 19:15:09 聖人 : 自分だけの力でこれをまともに実装しようとすると、とても使い物にならない速度になりそうな気がします…。
- 2005-03-16 (水) 21:20:43 くーみん : 構想大きいですね、すごいです。力になれないかも(ぉぃ)。2,3質問等。まず、着想理由について少し聞きたいです。また、「パターン」制なのはなぜでしょうか、キャラクタをメモリ転送するのが16(色)種類までだからでしょうか。BG画面はある意味バッファみたいに使うのでしょうか、裏画面がいきなり表になったりするのですか?いまのkaodunのルーチンでかなり出来ているのではないでしょうか。ということです。自分は全体の見通しをたてたり分かりやすく書いたりは大変苦手なので、枠組みがあると助かります。バグを除けば実装作業は難しくなさそうですが(自分の技量から見てではなく、感じとして。見通しはたたないんです)。どうでしょうか。構想としては、bpp24.libと似ている気もします。
- 2005-03-17 (木) 15:22:00 聖人 : どうもありがとうございます。着想理由は、今のkaodun内部での描画処理が「ゲーム処理側から見て」あまり使いやすいものではないと思ったからです。現在kaodunではアイテムの処理を追加しているところなのですが、アイテムを画面に反映させようと考えたときに、各画面(マップ、キャラクタ、暗い部分、ステータス・ウィンドウ)間の関係が把握しづらく面倒になってきたので、もっとゲームを作りやすい画面周りのライブラリを作ってしまおうと思い、作り始めました。一応、上の仕様はスーファミやらX68kやらの画面構成を参考にして決めてみました。パターン制なのは、RPG等ではこの方が扱いやすいと思ったからです。ただ今考え直すと、ゲームによっては直接BG画面を弄れた方が便利かもしれません(格闘ゲームの背景など)。なので仕様を変更します。グラフィック画面を廃止して、BG画面を4枚にし、BG画面に「ピクセルモード」と「タイルモード」を設けます。タイルモードでは上のBG画面相当のモードで、ピクセルモードでは、上のグラフィック画面相当の事に加えビットマップ等の転送も加えようかと思います。BG画面はバッファとしてではなくそれぞれ独立した画面で、 一括描画関数を呼び出すことによりグラフィックボックスに反映されるようにする予定です。各種情報はアプリ側が用意する変数に保持するようにする予定なので、アプリ側は画面を構成するために変数を弄った後、一括描画関数を呼び出すだけです。なので、裏画面のような存在はありませんし、構成中の画面が表に現れることも無いはずです。実際に画面に反映させるルーチンはkaodunのものを流用する予定です。それをゲームで扱いやすいようにBG画面やスプライトとして提供するのがこのライブラリの趣旨なので。というか自分の技量ではあの最適化でいっぱいいっぱいです(しかもkタンに高速な半透明処理も書いていただいたし)。
- 2005-03-17 (木) 15:35:08 聖人 : (長くなりすぎたので途中で分けた)とりあえず、実際に描画する関数群は揃っているので、確かに実装するのは難しくなさそうです。むしろそのあとに控える高速化が大変かもしれません。構想としては、確かにbpp24と近いものがありそうです。ただ、こちらは一応ゲームのためのものという扱いで作りたいと思っています。今のところ、勢いで作った構造体の一部が完成してるので、それと関数の枠が決まったらまたここに載せます。しばしお待ちくださいませ。
/* グラフィックシステムライブラリ定義用構造体 */
struct GSL_SYSTEM
{
struct LIB_GRAPHBOX *gbox; /* 描画先グラフィックボックス */
struct GSL_BGSCREEN *bg; /* BG画面定義の先頭アドレス */
struct GSL_SPRSCREEN *spr; /* スプライト画面定義の先頭アドレス */
unsigned char bg_count; /* BG画面の枚数 */
struct GSL_PATTERN *ptrn; /* パターン定義の先頭アドレス */
unsigned int max_ptrn; /* パターンの最大数 */
struct GSL_PAL *pal; /* パレット定義の先頭アドレス */
unsigned char max_pal; /* パレットの最大数 */
unsigned int width; /* 実画面の横幅(1dot単位) */
unsigned int height; /* 実画面の縦幅(1dot単位) */
unsigned int v_width; /* 仮想画面の横幅(1dot単位) */
unsigned int v_height; /* 仮想画面の縦幅(1dot単位) */
unsigned char mozaic; /* モザイクの度合い(無効0 - 31最大) */
unsigned char fade; /* 暗さの度合い(明るい0 - 31暗い) */
};
/* BG画面定義用構造体 */
struct GSL_BGSCREEN
{
unsigned int *tile; /* (タイルモード時)タイルマップ配列の先頭アドレス */
unsigned short *pixel; /* (ピクセルモード時)ピクセルマップ配列の先頭アドレス */
unsigned char pal; /* (タイルモード時)使用するパレットの番号 */
int x; /* 横座標(1dot単位) */
int y; /* 縦座標(1dot単位) */
unsigned char mode; /* 0=タイルモード,1=ピクセルモード */
unsigned char trnsprnt; /* 1=半透明表示,0=通常表示 */
unsigned char mask; /* 特定の画面との演算マスク */
/* bit0-bit3=BG画面1-4,bit5=スプライト画面 */
};
/* スプライト画面定義用構造体 */
struct GSL_SPRSCREEN
{
struct GSL_SPRITE *spr; /* スプライト配列の先頭アドレス */
unsigned int max_spr; /* スプライトの最大数 */
unsigned char priority; /* 0=BG1の上,1=BG2の上,2=BG3の上,3=BG4の上,3=BG4の下 */
};
/* パターン定義用構造体 */
struct GSL_PATTERN
{
unsigned char *adr; /* パターンの先頭アドレス */
unsigned char size; /* パターンのサイズ0=無効,1=8*8,2=16*16,3=32*32 */
};
/* スプライト定義用構造体 */
struct GSL_SPRITE
{
unsigned int ptrn; /* 定義パターンの番号 */
unsigned char pal; /* 使用するパレットの番号 */
int x; /* 横座標(1dot単位,実画面上) */
int y; /* 縦座標(1dot単位,実画面上) */
unsigned char visible; /* !0=表示,0=非表示 */
};
/* パレットデータ形式 */
struct GSL_PAL{
union{
struct{
char b : 5; /* 青 00000000 000?????*/
char g : 6; /* 緑 00000??? ???00000*/
char r : 5; /* 赤 ?????000 00000000*/
}p;
unsigned short u;
}n[16];
};
/* ライブラリ内でアプリ側のGSL_SYSTEMを扱うためのポインタ */
struct GSL_SYSTEM *gsl_sysp;
/*@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
初期化(アプリ側のGSL_SYSTEMを*gsl_syspに代入)*/
void gsl_init(struct GSL_SYSTEM *org){
gsl_sysp = org;
}
/*@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
描画 */
void gsl_draw(void){
/* BG画面の最大番号から描画 */
/* スプライトのプライオリティで指定された深度に達したらスプライトを描画 */
/* モザイクの度合いが指定されていればモザイク化 */
/* 暗さが設定されていれば暗くする */
/* グラフィックボックスのフラッシュはしない */
}
/*@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
kaodunで使用した描画関数 */
void drawpattern_8t(int x, int y, unsigned char *padr);
void drawpattern_8m(unsigned short *dest, int x, int y, int width, unsigned char *src);
void drawpattern_8tm(unsigned short *dest, int x, int y, int width, unsigned char *src);
void drawpattern_16t(int x, int y, unsigned char *padr);
void drawpattern_16m(unsigned short *dest, int x, int y, int width, unsigned char *src);
void drawpattern_16tm(unsigned short *dest, int x, int y, int width, unsigned char *src);
void drawpattern_32t(int x, int y, unsigned char *padr);
void drawpattern_32m(unsigned short *dest, int x, int y, int width, unsigned char *src);
void drawpattern_32tm(unsigned short *dest, int x, int y, int width, unsigned char *src);
void putstring_16bgbox(int x, int y, int col, char *strings);
void putbox(int x, int y, int width, int height, int r, int g, int b);
/* これらを以下のように改名/仕様変更して使う */
void gsl_drawptrn8g(int x, int y, unsigned char *padr);
void gsl_drawptrn8(unsigned short *dest, int x, int y, unsigned char *src);
void gsl_drawptrn8t(unsigned short *dest, int x, int y, unsigned char *src);
void gsl_drawptrn16g(int x, int y, unsigned char *padr);
void gsl_drawptrn16(unsigned short *dest, int x, int y, unsigned char *src);
void gsl_drawptrn16t(unsigned short *dest, int x, int y, unsigned char *src);
void gsl_drawptrn32g(int x, int y, unsigned char *padr);
void gsl_drawptrn32(unsigned short *dest, int x, int y, unsigned char *src);
void gsl_drawptrn32t(unsigned short *dest, int x, int y, unsigned char *src);
void gsl_drawstr16(unsigned short *dest, int x, int y, unsigned short col, char *strings);
void gsl_drawbox(unsigned short *dest, int x, int y, int w, int h, unsigned short col);
/* メモリ転送系関数の引数widthはGSL_SYSTEM.v_widthに置き換える */
/* 文字描画関数と矩形描画関数はメモリへの転送命令にする。 */
- 2005-03-17 (木) 19:06:10 聖人 : 骨組みを完成させました。また、仕様の変更を上のリストに反映させました。BG画面のパレットはパターン単位ではなく画面単位で設定するようにしました。それでは、続きはよろしくお願いしますm(_ _)m。
- 2005-03-20 (日) 15:50:03 くーみん : GSL_SYSTEMのstruct GSL_PATTERN *ptrn;/* パターン定義の先頭アドレス */、というのと、予定仕様の(タイル)1パターンのサイズは画面単位で設定可能はぶつかると思うんですが、ここも変更されたのでしょうか、BG画面ごとにループをまわすのと、基本タイルサイズごとにループをまわすのと2通り組んでおこうと思います。(手間はあまり増えないと思う)高速化のときどっちか良さそうな方がありそうです。それから、GSL_BGSCREENの中に使うパレットの設定があるのは、例えば春夏秋冬をパレットを変えるだけで簡単に変えられるから…かな、それならBGごとにパレット持った方がいいかも、あと、パターン毎にパレット持たせるように構造体持つとか…(でも肥大化しますね)少しその辺りの理由がしりたいです。コードは気にせず組んでおきます。分岐がかなり増えそうです。あと、drawptrnに、t,m,tmの種類があるみたいなんですが、最新のkdunとは違うような…指定がないやつと、tは自前描画用なのかな?gsl_drawptrnを使ってグラフィックボックスにすぐに書いてしまう気だったのですが…グラフィックシステム分室欲しいです、中途のソースupしたりとか。勝手に作っていいですか?長文すいません。
- 2005-03-20 (日) 22:39:59 聖人 : 分室作りました。>分室欲しいです 続きはそちらに書きます。
Ver0.1の感想スレ - あっきぃ (2004-10-15 (金) 00:48:31) †
Ver0.1の動作報告・感想・要望はここに書くべ!
- 2004-10-15 (金) 00:49:58 あっきぃ : 難易度めちゃくちゃアップしててビックリしました!あと、ゲームオーバーしたときに結果の文字が浮かび上がってくるのがすごかったです!これからも頑張ってくださぃ~!応援してますょん~!!
- 2004-10-16 (土) 23:35:43 聖人 : 早速遊んでいただいてどうもです。これからも気の向くままに作っていきたいと思います。またスローペースになると思いますが気長に応援してやって下さい。
- 2004-12-03 (金) 00:48:24 K : ver.4.7にバンドルさせていただきます。sarアーカイブにして、32.4KBになりました。
- 2004-12-05 (日) 11:18:32 聖人 : 了解しました。stk5圧縮したファイルの合計よりもさらに小さくなりましたね。
- 2004-12-20 (月) 17:55:33 K : 640x480の16bitカラーモードでプレイすると最高に楽しいです。
最初の公開バージョン - nisi (2004-05-03 (月) 10:51:28) †
最初の公開バージョンについての報告はこちらへ
- DL:本家
- 2004-05-07 (金) 08:25:16 I.Tak. : Kaoちゃんの攻撃アニメーションの最後の方で, 一コマだけ空白がある (Kaoちゃんが消える) ようです。左向きのときだけは消えませんが, 代わりに右斜め上を向くパターンが出ます。遅いマシンでお試しあれ。私はTOWNSでやりました。
- 2004-05-07 (金) 18:19:18 聖人 : 報告ありがとうございます。そのバグは制作中に遭遇してたので直したと思い込んでたのですが、直ってませんでしたか。次のバージョンで修正しますので、しばしお待ちくださいませ。
ダンジョンゲームすごい! †
- 面白いし、技術的にもすごそう!!
- あるいてたら落ちてしまったので(なぜか)ここで報告します。
- OsaskWiki:OSASK_Faultsに原因が載っているみたいですが、もしかするとqemuのタイマー問題かもしれません。
- 2004-04-28 (水) 20:26:31 K : だんじょんすごい!しかしEPIA-VE5000上のqemuではかなり遅いので(当然なんですが)なんかもっと速くならないものかと思案中。一番利きそうな関数部分だけをASKAにしようと思っています。効果があるかどうかは分かりませんが。
- 2004-04-28 (水) 20:42:55 K : drawpattern系が高負荷なのかな?(dung_grp.c)
- 2004-04-28 (水) 21:18:44 聖人 : 早速遊んでいただいてどうもです >御二方。実機だとこういう落ち方をしたことがないので、QEMUが問題になっている可能性が高そうです >あるいてたら落ちてしまった。 しかも、うちではQEMUが上手く動いてくれないので、確認できません…。
- 2004-04-28 (水) 21:19:36 聖人 : dung_grp.cは全体的に負担が高い関数が多いです。今は、GOのコンパイルオプションで-O2を指定して最適化しているのですが、それでもTOWNSでコマ送りが限界なので…。4bppにしたのが失敗だったかもしれません(^^;
- 2004-04-28 (水) 21:25:42 あっきぃ : 先ほどK6-2(450Mhz)マシンでテストしてみましたが、滑らかに動いていました。聖人さんが気にするほど重たくもないかな? で、このマシンでも落ちなかったので、qemuが原因ですねぇたぶん
- 2004-04-28 (水) 21:27:00 あっきぃ : ↑実機ね^^;
- 2004-04-28 (水) 21:31:29 聖人 : K6-2(450Mhz)でも快適でしたか! よかったよかった。…ということはうちの環境が貧弱すぎるのかなぁ。
- 2004-04-28 (水) 21:50:00 聖人 : やっぱりqemuが原因っぽいですか…。よっぽど余裕のある環境でない限り、実機で遊んでほしいです。なにしろデバッグも実機でしたもので…。
- 2004-04-28 (水) 22:38:31 K : gg00libcのdefsghdl.nasにバグ発見。僕のミスです。聖人さんはきっと苦労なさったことでしょう。どうもすみませんでした。
- 2004-04-28 (水) 23:40:01 K : putbox_transをちょこっといじって、劇的に速くなりました(通路に入っても遅くならない感じ)。こうごきたい。ちなみにまだASKAを使っていません。Cレベルでかなり改善できそうなので、まずはそれからやっています。
- 2004-04-29 (木) 01:18:57 ひげぽん : こんばんは。感動したので記念に書き込みを。小柳さんが配布されているVmware用4.4イメージで試してみたところ起動はしましたが矢印キーで何も反応しませんでした。あまり役に立たない情報ですいません。
- 2004-04-29 (木) 01:31:47 K : ほんのちょっとだけいじって結構高速化した(と思う)バージョン。良かったら参考にしてください。make済みバイナリも入れておきました。Celeron733でもフルスピードが出るかもしれません。 http://k.hideyosi.com/kdun00a.lzh (18.6KB)
- 2004-04-29 (木) 01:34:19 K : ひげぽんさんこんばんは。キー入力ですが、長く押しつづける必要があるので、その関係でキーが反応しないように思われたのかもしれません。ちなみにこれは斜め移動に対応するための仕様だと思われます。それと、qemuでは動くのでqemuでプレイするのをお勧めいたします(もちろん実機が最高ですが)。
- 2004-04-29 (木) 11:48:55 ひげぽん : Kさんありがとうございます。やってみます。
- 2004-04-29 (木) 21:25:25 聖人 : (高速版)ありがとうございます。早速試してみた所、Duron機ではLOADFACでわかるほど高速になりました。Celelon733では残念ながらあまり変わりませんでした…。グラフィックカードがネックになっているのかなぁ……。それから、下に降りる時に0007:0003FC1で一般保護違反になってしまったのですが…。STACKSIZEが足らないのでしょうか…(以前、32768Kにしていた時にも似たような事があった)。
- 2004-04-29 (木) 21:31:11 聖人 : >ひげぽんさん 遊んでいただいてどうもありがとうございます。これと似たような事が256色モードのTOWNS(i486SX 33MHz)でも確認しているので、多分Kさんの言う通り、キー入力を拾いきれていないのだと思います。QEMUを動かせられないのでQEMUがどういう感じかはわからないのですが、もし時間があるのでしたら実機で遊んでみてほしいです。
- 2004-04-29 (木) 22:03:00 K : スタックサイズのせいではなく、もっと深刻な原因だろうと思われます(ざっと見たところスタックを大量に使いそうな理由がないので)。ポインタが狂っているとかそういう可能性を全てつぶしてから、スタックを広げるようにしてください。
- 2004-04-29 (木) 22:59:57 聖人 : わかりました。今日はちょっとできないので、明日原因を探ってみます。
- 2004-05-02 (日) 23:57:59 あっきぃ : そろそろこいつをどっかに移そうとおもいますが、どの辺がいいですか?
- 2004-05-03 (月) 10:54:00 nisi : ここ>http://plantl.org/l/rpg/hiki.cgi?%B7%C7%BC%A8%C8%C4 はどう?
- 2004-05-07 (金) 15:31:33 I.Tak. : 画像のエラーの問題ですが, 私もqemuで自作アプリを動かしてたら遭遇しました。とりあえず, タイマーをstartする前にstopして回避してます。なんか悔しい解決ですが。
- 2004-05-09 (日) 01:15:36 K : 実は聖人さんのRPGの場合、まさにタイマをstartする直前に念のためにstopするコードが入っているのです。それなのにエラーになるんです。実に解せません。qemu側の問題である可能性が濃厚ですが、OSASK側のバグの可能性もあります。少なくともアプリ側のバグではないと思います。
スクリーンショット! - nisi (2003-07-16 (水) 09:50:06) †
でましたね!!
- 2003-07-17 (木) 17:30:34 nisi : つーか、楽しそうだな・・キャラ作り・・会社で暇な時間が無いのでちと無理ぽ
- 2003-07-26 (土) 12:53:52 nisi : I.Tak.さん参戦
- 2003-07-26 (土) 13:00:34 あっきぃ : カッコイイ!
- 2003-07-28 (月) 11:46:13 I.Tak. : KaOSや狐と並べると小人天狗に見える罠
- 2003-07-29 (火) 12:17:09 聖人 : カオちゃん、でかすぎたかも…(汗
- 2003-08-04 (月) 16:39:52 nisi : RPGなんかでは昔からあるジレンマですよね、キャラサイズ・・・ドラクエの犬とか
- 2003-08-06 (水) 11:45:00 あっきぃ : ナオミさんが動くのかぁ。楽しみだ~~!
- 2003-08-08 (金) 11:42:11 I.Tak. : 頭の大きさだけ揃えれば見られそうなので, 二頭身に書き直してます>キャラサイズ
- 2004-04-27 (火) 15:49:57 nisi : おー>>現状
- 2004-04-28 (水) 22:05:50 聖人 : お待たせしました。やっと公開できました。時間かかりすぎました…。
- 2004-04-29 (木) 10:18:08 Zakky : 紹介しておきました。リンク等問題あればお早めに(ぉ
- 2004-04-29 (木) 21:14:26 聖人 : 紹介していただいてどうもありがとうございます! 非常に光栄です。
- 2004-05-01 (土) 10:31:27 nisi : やりました。すごいですね!とりあえずキャラ増やして、レベル上げつけるだけでも(記録競争とかで)遊べそうです 今後が楽しみです。
- 2004-05-02 (日) 18:46:16 聖人 : どうもです。記録競争のためには、ゲームオーバー後にステータスなどを表示したりしたほうが遊べそうですね。次の版では、もっとゲームとして遊べる様にしたいです。
|