ゲームプログラミングについてあれこれ語るスレです。
まあ、主に私の独り言がメインですが・・・。

・相手のいる方向を向く処理

前提条件
　角度は一周を256分割して表す。90°= 64, 180°= 128

今の自分の向きを a とし、a-b 〜 a+b の範囲に相手がいるかを判定する。
相手のいる方向を c とすると、
　a-b <= c <= a+b
が成立するかを調べればいいのだが、a が 0 付近の値だと面倒なことになる。

ここで、a = 5, b = 10 とすると
　a-b = -5 <= c <= a+b = 15
c の取りうる値は 0〜255 なので
　0 <= c <= 15 or 251 <= c <= 255

同様に a = 250, b = 10 とすると
　a-b = 240 <= c <= a+b = 260
　240 <= c <= 255 or 0 <= c <= 4


これを効率よく判定するにはどうすればいいだろうか・・・？

if(a-b < 0) {
　if((c >= 0 && c <= a+b) || (c >= a-b+256 && c <= 255)) return true;
　return false;
}
else if(a+b > 255) {
　if((c >= 0 && c <= a+b-256) || (c >= a-b && c <= 255)) return true;
　return false;
}
else if(c >= a-b && c <= a+b) return true;
return false;

こうかな・・・。
unsigned char型 を使ってもっと短く出来そうな気がするんだけど・・・。

・親子関係
サイドビューのアクションゲーム（例えばスーパーマリオなど）では
移動する足場といった、別のオブジェクトの上に乗るというアクションが日常的に出てきます。

そして、上に乗っていると、足場の移動にあわせて自分も動きます。


これを実現するには二つのアプローチがあります。

１．自分が何に乗っているかを知っている
２．足場が上に乗っているのは何かを知っている

どちらを採用すべきなのか・・・？

１．自分が何に乗っているかを知っている

◎利点
自分が乗っているオブジェクト（親）のポインタを知っているだけでよい。

×欠点
同時に複数の親を持てない。
親は誰かに参照されているうちは消えることが出来ないのに、
誰に参照されているか知ることが出来ない。


２．足場が上に乗っているのは何かを知っている

◎利点
親子関係を直感的に把握しやすい。
親を好きなときに消滅させることが出来る。
子が親の存在を意識せずに済む。

×欠点
親の上に不特定多数の子が乗る場合、子を管理するポインタの数が不定となる。


他にもいろいろありそうだが・・・。

さて、２の方法を実現したい。

子の数が不定になることを簡単に解決する方法は、メモリを動的に確保することです。
が・・・リアルタイムのゲームでは小さなメモリの確保解放が
短時間で無数に繰り返されることになります。そんな危険なことはやりたくありません。
（何故危険なのかわからない人は少しOSの勉強をしましょう）

不定がダメなら固定にすればいい。
しかし、そうすると、ひとつの親の上に乗れる子の数が制限されてしまいます。
（ちなみにスーパーマリオでは、足場に乗れるのはマリオ一人だけだったので、
子ポインタをひとつ知っているだけで済む）

「メモリなんてケチらず湯水のように使えばいいじゃん」とばかりに
子ポインタを格納する配列の要素を 1000 とかにしちゃえばきっと幸せになれるでしょう。

が、あまりに美しくないし、メモリの無駄遣いです。
もっといい方法はないものか？

子管理リストを導入するのはどうでしょうか？
これなら最初に一括してメモリを確保することが出来るし、
メモリの無駄遣いになることもありません。いけるかも！？


ここでいうリストとは、「線形リスト」のことです。
ゲームプログラミングにおいて、必須とも言えるデータ構造でしょう。

不特定多数のオブジェクトを順番に参照することが出来、
リストの任意の位置に対する追加削除を少ないコストで行うことが出来ます。

詳しいことは適当に Google ででも探してみてください。

>>3
unsigned char c, a0, a1;
a0 = a-b;
a1 = a+b;
if(a-b < 0 || a+b > 255) {
if(c <= a1 || c >= a0) return true;
return false;
}
else if(c >= a0 && c <= a1) return true;
return false;

こうか。
そこそこ短くなったかな。

■シューティングゲームで敵を出現させる方法
最も簡単な方法は1フレームごとにカウントアップするタイマーを用意し、
そのタイマーの値を見て、敵を出現させるというものです。

long event[256][2] = {
　{10, 1}, {20, 1}, {40, 2}};

main_loop() {
　c++;
　if(event[idx][0] == c) {
　　switch(event[idx][1]) {
　　case 1:
　　　// 敵１出現
　　case 2:
　　　// 敵２出現
　　}
　　idx++;
　}
}

非常にシンプルな構造です。

当然、このアルゴリズムでは対応できない要素はいくらでもあります。
たとえば敵の早回しや、中ボスの存在です。

どうやって解決すればいいでしょうか・・・。

「早回し」というのは、画面上の敵を全滅させると次の敵が出現するというシステムの
ゲームに見られる要素です。
敵を素早く破壊することで、次の敵の出現が早くなります。
これを利用すると通常より多くの敵を出現させることが出来、高得点を狙えたりします。

「中ボス」はゲームによって扱いが異なりますが、
大抵は破壊するまでゲームの進行がストップします。

早回しの具体例を挙げ、それを実現する方法を考えます。

下のようにイベントが発生するとします。
なお、カッコ内はステージ開始からの経過時間です。

ステージスタート(0)
　雑魚A出現(10)
　雑魚B出現(20)
　雑魚C出現(30)
敵全滅(x)
　雑魚D出現(x+10)
　雑魚E出現(x+20)
　雑魚F出現(x+30)
ボス出現(100)

雑魚D,E,F は敵が全滅してからの経過時間を見て出現します。
ボス出現時刻までに出現しなかったものは出てきません。

つまり、敵が全滅したフレームによって
　30〜69：D,E,F出現
　70〜79：D,E出現
　80〜89：D出現
と変化します。

D,E,F の出現を制御するには以下の要素が絡んできます。
・敵の全滅を監視
・敵全滅時からカウント開始するタイマー
・次のイベント(ボス出現)の発生時刻

これらの要素を含んだイベントタスクを用意してやるのがよさそうです。

long event[][2] = {
{10, 'D'},{20, 'E'},{30, 'F'}
};
ev001::init() {
　phase = 0;
　cnt = 0;
　idx = 0;
　end_time = 100;
}
ev001::loop() {
　if(stage_counter >= end_time)
　　return false;

　switch(phase) {
　case 0:
　　if(敵残存数() <= 0)
　　　phase++;
　　break;
　case 1:
　　cnt++;
　　if(event[idx][0] == c) {
　　　敵出現(event[idx][1]);
　　　if(++idx >= 3) return false;
　　}
　}
　return true;
}

>>12
ev001::init() でカウンタ類を初期化します。
end_time = 100 と固定値を代入していますが、本来は引数で外部から指定します。

ev001::loop() はinit()が実行されたあと、毎フレーム実行します。
戻り値がfalseの時、イベントタスクは終了します。

終了の条件は、「次のイベント(ボス出現)の発生時刻になった」
「全てのイベントを消化した」の二つです。

さて、この段階では早回し用イベントと通常のイベントの発生テーブルが
分かれてしまっています。これはよろしくない。
一つにまとめましょう。

>>9
ではイベントデータの参照位置を idx 変数で指定しています。
イベントが一つ発生するごとにインクリメントしていますが、
これを任意の値に変更できれば、必要のないデータ（早回し用イベントデータ）を
読み飛ばすことが出来ます。

そのためには、いくつ読み飛ばすかをデータに持たせる必要があります。
また、早回しイベントは終了時刻の値も必要としています。


今まで、イベントの情報には「発生時刻」「イベントタイプ」の二つしか
必要ありませんでした。これを拡張しましょう。

event[][0] = 発生時刻
event[][1] = イベントタイプ (敵の種類など)
event[][2] = 汎用パラメータ１
event[][3] = 汎用パラメータ２

汎用パラメータはイベントタイプによって意味が変わります。
例えば、敵A だったら出現するX,Y座標とか。
早回し用イベントの場合は、読み飛ばし数、終了時刻にしましょう。

これなら上手くいきそうですね。


なお、ここでは二次元配列を使っていますが、
構造体の配列にするほうが一般的でしょう。

以上の事から、このようなプログラムになりました。

event[][4] = {
{10, 'A', 320, 100}, {20, 'B', 0, 0}, {30, 'C', 100, 1},
{30, 'Z', 3, 100},
{10, 'D', 0, 0}, {20, 'E', 255, 255}, {30, 'F', 1, 1},
{100,'X', 0, 0}};

ev001::init(long *ev) {
　ev001::phase = 0;
　ev001::cnt = 0;
　ev001::idx = event::idx + 1;
　ev001::ev_max = ev[2]+ev001::idx;
　ev001::end_time = ev[3];
　event::idx += ev[2];
}
ev001::loop() {
　if(Application::GetStageCounter() >= ev001::end_time) return false;

　switch(ev001::phase) {
　case 0:
　　if(Application::GetExistEnemies() <= 0) ev001::phase++;
　　break;
　case 1:
　　ev001::cnt++;
　　　if(event[ev001::idx][0] == ev001::cnt)
　　　　Application::AppearEnemy(event[ev001::idx]);
　　if(++ev001::idx >= ev001:ev_max) return false;
　　break;
　}
　return true;
}

Application::main_loop() {
　Application::stage_counter++;
　if(event[event::idx][0] == Application::stage_counter) {
　　Application::ApperEnemy(event[event::idx]);
　　event::idx++;
　}
}

さて、「床の上にオブジェクトを置く」という処理を考えてみましょう。
「置く」というのはどういうことか。

床の当たり判定と、オブジェクトの当たり判定が重なり合わずに、
接触している状態ということです。
そして、床より上にオブジェクトが存在している必要があります。


当たり判定が接触しているかどうかを調べるのは、非常に難しいことです。
任意の多角形同士で接触判定なんてことを考え出すととんでもないことになります。
というわけで矩形同士の接触判定のみを考えます。

床の矩形を (px1, py1)-(px2, py2)
オブジェクトの矩形を (ox1, oy1)-(ox2, oy2) とします。

このとき、床の上にオブジェクトが乗っていると見なせる条件は
py1 == oy2 && px1 < ox2 && px2 > ox1
こうなります。

py2 == oy1 であれば、オブジェクトの上に床が乗っていることになり、
py1 < oy2 && py2 > oy1 であればオブジェクトが床にめり込んでいることになります。

接触判定については上で書いたように、ほぼクリアになったと思います。
次の段階は接触判定を行うまでのプロセスです。

まず、前提条件から。
・自由落下するオブジェクト
・床に接触するとそこに停滞する
・床は動かない

オブジェクトを下方向に移動。
移動後、下に床があるかどうかをチェック。
床がある場合は、オブジェクトを床と接触する位置に座標補正。
以後、移動処理は行わない。

接触した後、どちらも動かないのであれば、これだけですみます。
もっとも、これで済むケースはレアでしょうが・・・。

次に、床が左方向に移動している場合で考えてみます。

　オブジェクトを下方向に移動。
　移動後、下に床があるかどうかをチェック。
　床がある場合は、オブジェクトを床と接触する位置に座標補正。

ここまでは一緒です。
A.
　床にオブジェクトが乗ったことを知らせる。
　床を左に移動し、上に乗っているオブジェクトも左に移動させる。
B.
　オブジェクトが、自分の乗っている床を記憶する。
　床の移動量を見て自分も移動する。

ABどちらを選ぶかは好みの問題のような気もしますね・・・。
コーディングはBの方が楽です。

次に、オブジェクトが落下し、床と接触したら右に移動というケースを考えてみます。

基本的に >>18 と同じです。
>>18 の B の方法でこれを実現する場合、床の移動量と、
オブジェクト自身の移動量を合計し、その値を最終的な移動量とします。

問題はオブジェクトが移動するため、床から落ちる可能性があるということです。
よって、床との接触判定を常に行う必要が出てきます。
床との接触判定は、オブジェクトの性質によりますが
主に以下のようなパターンが考えられるでしょう。

1.足元に床があるか
2.前方に床があるか
3.前方に壁があるか

面倒でもオブジェクトの性質に合わせて必要な分だけ接触判定を行うことで
実現するしかありません。床が二つあるならその両方に対して接触判定を行います。

床を記憶するというより、床に着いた瞬間に床の世界に切り替えると考え方が楽になりますね。
逆に離れる時は全体の世界の逆に変換。
ただし、重力だけはどの世界にいても常にかかってるので その床の世界に
逆変換して力を加える必要があります。
まぁ単純に乗った→固定、なら簡単にＢのやりかたで問題ないですけど。

床にモノを乗せて、床を傾けるとどうなるかを考えると面白いですｗ

>ただし、重力だけはどの世界にいても常にかかってるので その床の世界に
>逆変換して力を加える必要があります。

ふむ・・・つまり、床は重力と同じ大きさで逆向きのベクトルを持っていて、
重力とつりあっているから静止している、と考えるわけですか。


>床にモノを乗せて、床を傾けるとどうなるかを考えると面白いですｗ

物理の授業を思い出しますね。もうほとんど忘れちゃいましたが。

2chのスレでも紹介してみますか。
この二つのスレは趣味でシューティング作ってる人は必見だと思います。
私も頻繁に書き込んでいますし。
2ch避難所のゲーム製作技術板は他のスレも役に立つものが多いですね。

■PCで出来る2Dシューティング(STG)総合スレ5
http://game2.2ch.net/test/read.cgi/game/1058538369/l50
このスレの成立当初はかなり揉めてましたね。今はかなり落ち着いてﾏﾀｰﾘしたスレになっています。
とにかく、遠慮のない鋭い感想が多くて、非常に参考になります。
シューティングで遊ぶ人だけじゃなく、作る人も沢山見に来ているようです。

■シューティングゲーム製作技術総合
http://bbs.gamdev.org/test/read.cgi?bbs=gamedev&key=1056635103&ls=50
スレタイ通りの内容です。あまりに初歩的な話はそんなにありませんが、むしろその方が好都合かと。
このスレも勉強になります。私もたまに質問してます。

シューティングゲームの背景接触時の位置補正について。
どうやって実現するべきか・・・。

前提として、地形といっても内部的には破壊出来ない敵キャラ扱いです。
複雑な地形は複数の敵キャラを配置して実現します。
1フレームの間に位置補正で動かせるドット数を決めておきます。（縦横、別々にカウント）

１．自機と地形の当たり判定ルーチンで接触しているものを探す。
２．上下方向で判定が重ならない位置までずらす。
　　ただし、位置補正で動かせるドット数の範囲内で。
　　この範囲内で移動できなければ死亡。
　　ずらした分だけ移動可能ドット数を減らす。
３．左右方向についても同様。
４．次の地形との接触判定。同様に上下・左右方向でチェックする。
　　ただし、一度左に位置補正した場合は、右側には動かせない。

こんな感じかな？
座標補正が終わった後、もう一度地形との接触チェックが必要だが・・・
なんとか、一度だけで済ませられないかなぁ。

画面端との挟まれチェックは、
移動後に自機の判定が画面外に出てしまった時を条件にすればよさそう。

よく考えてみたけど、この方法だと上･左の判定で1ループ、下･右の判定で1ループと
かならず2回ループしないとダメだ。

1回のループで上下左右の4方向をチェックすると壁にめり込んでしまう。
まあ、地形オブジェクトは出現する数が少ないから大して影響は出なさそうだ。

それだと、ナナメの地形とかのヒットを取るのが面倒になりそうですねーｗ
あと、鈍角な地形とか。
今時のマシンはそれなりに高速だし、おそらく２回が１０回に増えたくらいでは
びくともしないと思われます。　接触判定は一つ作っておけば ある程度汎用は効くし
それなりに後づけで拡張できるような形にしとくと ヒットの種類が増えた時に楽かもｗ

斜めの地形は根性で矩形を並べるつもりです。

斜線も当たり判定に使うとなると、接触（重なり合わずに隣り合っているか）の判定を
どうすりゃいいのかと。
まあ、ほかにも色々めんどくさそうだったので回避したかったわけで・・・。

線分同士の交差チェックくらいはすぐ思いつきますけどねぇ。

はじめまして。
とあることからここのHPにきました。
かなり日付が前のものになりますが、マリオなどのアクションゲームででてくる
足場が移動するブロックについて知りたくて検索したらこのHPがでてきました。
読ませていただきましたがもう少し理解できていません。
すいませんが誰か居られましたら教えていただけませんか。

私も試行錯誤しているところなので、これが正解、というようなことは書けませんけども。

アプローチとしては2種類考えられます。
１．マリオが足場の情報を取得する
２．足場がマリオの情報を取得する

取得する、というのは相手のインスタンスにアクセスできるようにするということです。
これにより相手の座標や状態を知ることができます。

１の方法では、マリオがどの足場に乗っているかをチェックし、
乗っている足場の移動情報を利用して、マリオを移動させます。
この場合、マリオの移動ルーチン内で一度だけ処理をすることで動作が完了します。

２の方法では、足場が今、上に乗っているキャラがいるかどうかをチェックし
乗っているキャラ全てに対して移動を行います。
この場合、足場がマリオに移動したことを伝え、
その後マリオがその情報を使って移動することで動作が完了します。


どちらを採用すべきかは場合によりけりだと思いますが
１の方がプログラムは簡単になるのでは。
２はやや複雑になりますが、応用がきくのであとあと便利になると思います。

ありがとうございます。
実は現在３Dのアクションゲームを作っておりまして、ぱっと見、簡単な処理に
思えていたのですがMAPを画面に表示する度にMAP情報を書き換えるのは明らかに
効率が悪いと思いまして質問させていただきました。
本当にありがとうございます。

去年の秋頃から色々あって、まだ決着してないわけなんですが
とりあえず、今後の方向性をおぼろげに決めました。

シューティングゲーム制作はしばらく凍結します。
そのかわりに、別の計画を始動させます。

まずはパレットブロック機能を持つスプライトパッケージの作成から。
位置から作っていく時間も気力もないので、既存のフリーライブラリに機能追加するかたちで。

いわゆる色違いキャラをソフト的に実現させるためのものですね。
最初から色違いキャラを用意しておくというのは、今の構想には、全くもって不向きなので。

DirectXのことはよくわからないけど、構想としてはこんな感じ。

1. テクスチャの元画像を用意する
2. パレットブロックデータを用意する
3. 空のテクスチャを用意する
4. 1.の画像から表示したい領域を読み取る
5. 4.のデータにパレットブロックを適用して3.のテクスチャに書き込む
6. 5.で作ったテクスチャをDrawPrimitiveかなにかで描画

果たして、これでうまくいくのかな？

具体的には1,2,3のデータはひとつのインスタンスになり、
そのインスタンスを参照するスプライトクラスのインスタンスが沢山作成できる。

表示プライオリティはどうやって解決しようか・・・。

IDirect3DTexture8 が保持しているビットマップにどうやってアクセスすればいいのか
ずいぶん悩んでしまいました。

LockRectでロックするとビットマップ領域へのポインタが得られるのね。

そんな感じで最低限の機能を作ったので、
実際に試してみたら真っ白な矩形が表示されるだけでした。

うーん、まだまだ、かな。

表示テスト用の画像データは X68k で作ったスプライトデータを変換して用意しました。
この程度の簡単な作業なら VC ではなく HSP でやる方が楽ですね。

というか、VCではやりかたがよくわからんのですが。


スプライトデータのタイムスタンプを何気に見てみたら
古いものでは1994年なんてのがあったりして。

10年前じゃないか・・・。
10年経ってもやってることは大して変わらんということを痛感しました。

テクスチャが画面に表示出来ない〜。

テクスチャには期待通りの絵が作成されているようなのですが
画面に表示させると、真っ白の四角にしかなりません。

この白は頂点カラーで指定した色ですね。
テクスチャをマッピングする方法に問題があるカンジです。

デキたー！
PCGを展開する先のテクスチャを D3DPOOL_SYSTEMMEMで作成していたのが原因でした。
D3DPOOL_MANAGED にしたらうまく表示されました。

うーむ？
D3DPOOL_DEFAULTとD3DPOOL_SYSTEMMEMの二つのテクスチャを確保して
CopyRectsでコピーするほうがいいのかな・・・？

水平,垂直反転機能も実装しました。
って、テクスチャのUV座標指定をいじるだけですが。

パレットも機能しているので、あとはどれだけのスピードが出せているかですね。
誰かに生贄になってもらうしかないな・・・。

只今、当たり判定エディタの作成中。
最低でもこれだけは先に作っておかないと、ゲーム本体の作成に取り掛かれないので。

これは今月中に終わらせないとな。

あとはデータのセーブ機能をつければほぼ完成、ってとこまで出来ました。
今月中には余裕で終わりそう。


このエディタも例によってHSPで作ってるわけですけど
わりと何でも出来ちゃいますね。
VCでGUIプログラムの作り方を勉強するよりこっちのが楽そうだ。

今頃になって、編集エリアが128*128では狭すぎるということが発覚。
あー、どうしようかなぁ・・・。
編集エリアをもっと広げるか、表示倍率を可変にするか。


でもまあ、編集エリアにはスクロールバーがついていて実質256*256なので
十分かもしれませんが。

バイナリデータを出力する機能を除いてエディタの作成が完了。
バイナリデータの仕様はゲームを作りながら詰めていくので、
ひとまずエディタ作成はここで中断です。

さーて、ここからが本番だぞ。

ゲーム本体部分のプログラムを作成中ですが
非常に進みが遅い・・・。

キー入力クラスを汎用的かつ、自由なキーアサインが可能なようにしたのですが
これだけで一日かかってしまいました。

C++の習熟度がいまひとつなせいもありますが、時間かかりすぎです。

ひぃぃぃぃ・・・・。
今までテクスチャを D3DPOOL_MANAGED で作って、そこに直接書き込んでいたんですが
D3DPOOL_SYSTEMMEM に作成してから D3DPOOL_DEFAULT にコピーするようにしたら遅い！

IDirect3DDevice8::UpdateTexture()って超高速なのかと思ってたけど
全然そんなんじゃありませんのだ。


ダーティ領域をしっかり設定すればもっと速くなるだろうけど
それでも MANAGED に直接描くのと大差なさそうだなぁ・・・。

やっぱり事前に全部展開して DEFAULT に置いとくべきか・・・？

UpdateTexture() はダーティ領域をしっかり設定してやれば
MANAGED に直接書き込むのとほとんど同じスピードになりました。

しかし、UpdateTexture()がフルスクリーンモード時でだけ妙に遅いことが発覚。
どういう仕様だ。
ビデオカードに原因がある可能性もあるけど。

誰かこの現象を説明できる人はいないですかねぇ・・・。


とにかくこのスプライトルーチンの使用は
必要最小限にとどめる必要があるようです。
1フレームに4枚くらいなら問題ないかな・・・？

二つ目のデータエディタの作成中。
予定では他にもう一つ必要です。

ちなみにゲーム本体のプログラムは通勤中の電車の中で書いてたり。
ノートPCのグラフィック機能が貧弱なせいで動作確認はできませんが
コードを書くだけなら十分です。

今月中に当たり判定無しでキャラを動かせるところまでは作りたいなぁ。

メンバ関数へのポインタとそのポインタを介したメンバ関数の実行。
C++を使い始めて日が浅いものだから、↑のようなことが出来るとは今まで知りませんでした。

Cで出来ていたことがC++で出来ないのも変だよなーと思いつつ
switch 文を書いていましたが、これですっきり書けそうです。

しかし、これとポリモーフィズムを組み合わせて期待通りに動くんだろか・・・？

ふぅー。やっと数値の上ではレバーを入れた方向に動くことが確認できたよ。
最近、電車の中でしかプログラム書いてないから進みが遅いの何のって。

DirectSoundで、イントロ部分とループ部分の二つのWAVデータを
つなげて再生する方法を模索中。

調べてみた感じでは IDirectSoundNotify を使って
再生終了イベントを起こしてもらうことになりそう。

今回使っているライブラリでは、サウンド処理用スレッドを立てて
そこでイベント待ちをしているので基本部分はあまりいじらなくてもいいかも。

しかし、Notifyの起こすイベントと他のイベントのハンドラを1つの配列に
押し込まなきゃいけないのがまずいかな。

Notifyのイベント発生が遅れる可能性もあるようだし。


それにしても、イントロ＋ループという構成のBGMはいくらでもあるのに、
これに関する具体的な解説というか資料が見つからないのは何故だろ？

データを分割しないで最後まで再生したら、
また頭から再生で対処してるゲームも多いし。

BGMとSEの再生を同列に扱うクラスを考えていたのだけど
ひとつのDirectSoundオブジェクトで多重再生が出来ないことに気づいて
ご破算に。

多重再生のありえないBGM用WAVデータを多重再生用に複数持つなんて
愚の骨頂ですよ！


別々のクラスにしなきゃダメだ。

DirectX9を始めて間もない者なのですが、
二次元配列を使用して円弧を作成しろという課題が出てしまったのですが、
いかんせん初心者な者でどう手をつけてよいのかわかりません。
どなたかご教授宜しくお願いします。
ちなみに、始点と終点と中心(半径r)を決めて始点と終点を結んだ扇形を作りたいです。
このとき中心から始点、中心から終点の線は表示しないで始点と終点のみを結びます。
あと、今DirectX　グラフィックのチュ−トリアル４を参考に勉強させていただいてます。
宜しくお願いします。

なぜここで質問するのかよくわかりませんが・・・。
円周上の点を(x,y) = (r*cosθ, r*sinθ)で表せることはわかりますか？

これを使って半径rを固定してθを少しずつ大きくしていけば
等間隔で円周上の点を求めることが出来ます。
そしたら、あとはこれを結ぶだけ。


DirectXの使い方は教えられるほど詳しくないんで
勘弁してください。

イントロ有りの無限ループ再生はとりあえず実験に成功。
あとは、ループ位置をどこに持たせるかとか、
Notifyの遅れ補正が必要なのかとか、細かい部分を調整すればOKかな。

コンピューターの画像上で円を描くのに三角関数を使うのはどうかと思います。
プロットされるのが格子点上の点に限定されるのですから、加減算数、ビットシフト
（/2,*2)だけの計算で高速に計算できます。

いや、それはもう昔の話です。

DirectXでは座標の指定にfloatを使います。
下手に全部整数でやろうとすると、整数からfloatにキャストする分、余計な手間がかかります。

ついでに、実数計算でかかる時間と画面描画にかかる時間を比較したら
実数計算にかかる時間なんて、無いも同然なんですよ。

1クロックでベクトルの内積や外積を得られるご時世に
整数化＆ビットシフトでの高速化は焼け石に水です。

さらに高速化の常套手段であったループ展開やテーブル化も、
今ではキャッシュを食いつぶすので逆効果。


もう、そんな時代なんですよ・・・。

嫌な時代だ。
そうやってどんどんちゃんとしたプログラムを書けない
だめだめプログラマーが増えて行くんだ。

DirectX8 から、描画は全て3次元空間に対して行うようになったので
実数空間の座標を指定する必要があります。これがfloatを使う理由です。

> プロットされるのが格子点上の点に限定されるのですから、

そして、もう、この前提からして違うのです。
「画面上に1ドットの点を打つ」というのは
DirectXでは「画面上で1ドットの大きさに見えるポリゴンを3次元空間内に描く」ことです。

円を描きたいならドットを打つのではなく、
円周上の点を求めて、それを繋げる線分を描く必要があるのです。


私もしばらくはカルチャーショックを受けて馴染めずにいましたが
本来は考える必要のない部分（高速化のためのテクニックなど）に時間をかけず
実現したいことのみを考えればいいわけで、こういう時代も悪くはないと思います。


それでも、コンピュータの仕組みを知っているかどうかで
コードの質に影響が出ると思いますけどね。

描くのはOS(?)の仕事でも、その座標を指定するのはプログラマの仕事ですよね。
それを実質的に整数で指定するか実数で指定するかは別にしても、
計算を高速にする、メモリを食わないなどは常に考えないといけないんじゃ
ないかなぁ（考え方が古い？）

Windowsでプログラムを書くことを前提にするなら
整数だろうと実数だろうとスピードは変わりません。
メモリはうなるほどあります。

よほどタコなプログラムを書かない限り
見易さ優先で書くほうがいいと思います。

IDirect3DDevice::Present() の引数で指定するコピー元、コピー先矩形を
異なる値に設定すると何故かバイリニアフィルタが適用されてしまいます。

例
src=(0, 0, 320, 240)
dst=(0, 0, 640, 480)

整数倍になるよう指定してもダメ。
当然テクスチャステージステートはTEXF_POINTを指定しています。
バックバッファからのコピーだから適用されないんでしょうけど。

ここでバイリニアフィルタを無効化するには・・・どうすればいいんだろう。

この局面でフィルタを無効化する方法がないようなので別の方法で回避しました。
処理速度に激しく違いが出ますけどね。

といっても、これが必要になるのは一部の液晶ディスプレイだけなので
コンフィグで選べるようにして、通常は高速に動作するモードを使ってもらうということで。

おじゃましますm(._.*)mﾍﾟｺｯ
なんか分からないけど、あたしのＨＰで、日記書くときのパス間違えると、必ずここが出てきますｗ
なんでだろ？ｗ
なので、覗いて見ました| 冫､)ｼﾞｰ　　　　　|)彡ｻｯ
http://www.geocities.jp/ox_asami_xo/

うちの日記CGIを利用されているんですね。ありがとうございます。

で・・・パスを間違えると、勝手にここに飛ぶわけじゃないですよね？
それなら表示されたリンクをクリックしないで戻るようにしてください。

どうしてもリンクをクリックしたいというのなら止めませんけど。

始めまして
格闘ゲームの項目を見てＨＰを知りました。
質問なのですが、やられアニメパターンの種類
とその移動距離をどれぐらい必要なんでしょうか？
よろしくお願いします。

どうもこんにちは。
アニメパターンの種類というのが何を指しているのかちょっとわからないのですが
私のゲームの場合、立ちのけぞり(3枚)、しゃがみのけぞり(3枚)、吹き飛びダウン(12枚)の
絵を用意してあります。

吹き飛びダウンのパターンは、叩きつけや足払いダウン、投げられにも流用します。

移動距離はゲームによって様々だと思うので、
ご自分で気に入った値を選ぶのが一番良いのではないでしょうか。

返答ありがとうございます。
　　言われる通りわかりにくくてすみません。
　　何が必要か１つ１つ調べなおしてみます。
　　言おうとしたのは立ちくらいやふきとばしのことを言おうとし、
　　今の現状が立ちくらいしかないので、攻撃ボタンのみでもくらうとはまりやすくなってます。
　　どれぐらい入れればはまりにくくなるかと思い質問しました。