ゲームプログラミング相談室【Part6】

**名前は開発中のものです。** · 04/03/06 01:25

ゲームプログラミング全般の質問スレッド。
扱う話題のダイナミックレンジはやや広め。包容力高め。
他の初心者質問スレとの棲み分けを探りつつ
これからもマターリと活用しておくれ。
　
■過去スレ
【Part2】http://pc.2ch.net/tech/kako/985/985540361.html
【Part3】http://pc.2ch.net/tech/kako/1002/10028/1002894129.html
【Part4】http://game.2ch.net/gamedev/kako/1005/10050/1005040025.html
【Part5】http://pc2.2ch.net/test/read.cgi/gamedev/1036410116/
■関連スレなど
>>2-5

**名前は開発中のものです。** · 04/03/06 01:26

■関連スレ
【初心者歓迎】ｽﾚを立てる前にｺｺで質問を【Part5】
http://pc2.2ch.net/test/read.cgi/gamedev/1078502309/
鬱だ氏のう DirectX (Part 12)
http://pc2.2ch.net/test/read.cgi/tech/1076651336/
初心者のためのゲームプログラミング
http://pc2.2ch.net/test/read.cgi/gamedev/1023119134/
ズブの初心者がゲーム作れるまで勉強するスレ
http://pc2.2ch.net/test/read.cgi/gamedev/1005132370/

**名前は開発中のものです。** · 04/03/06 14:28

　　　　　　　。 ◇◎｡ｏ.:O☆οo.
　　　　　　　。:゜ ◎::O☆∧_∧☆｡∂:o゜
　　　　　　／。○。 ∂（*ﾟーﾟ）O◇。☆
　　　　　／　　◎|￣￣∪￣∪￣￣￣|:◎:
　　　／　　 ☆｡|..　　新スレおめ　　.|☆
　 ▼ 　　　。○..ｉｏ.｡◇.☆＿＿＿＿| 。.:
∠▲―――――☆ :∂ｉo☆ ゜◎∂:.

**名前は開発中のものです。** · 04/03/06 16:00

windowsでアクションRPGを作ろうとしています。
２Dで作りたいのですが、その場合の最適な方法を教えて
下さい。
DirectXのスプライトやテクスチャを使うよりひょっとして
GDIを使った方が早いとか・・その辺どうなのでしょうか？
プログラミングに関してわりと初心者なので、ご助言よろしく
お願します。

**名前は開発中のものです。** · 04/03/06 16:08

>>4
DirectXとC/C++で作る。
描画まわりを自分で組むのは面倒だし、
よくわからないので誰かのライブラリを使わせてもらう。
誰のライブラリを使うかは自分で探す。

これでとりあえずゲームを作れる環境は整う。

**名前は開発中のものです。** · 04/03/06 16:32

GDI使え

**名前は開発中のものです。** · 04/03/06 17:05

>>4
2Dなら、GDI（DIBSection）の方が開発はやりやすい。
描画性能に関しては、少なくとも「画面への描画速度」は問題ない
場合が多い（内部への描画処理については、単純にメモリを読み書き
るDIBectionの方が有利な可能性もある）。また、スプライトは32
ビットフルカラーなどピクセル単位の処理を容易にできるシステム
でやる分には、ピクセルをすべて自力で処理しても大丈夫だろうね。

ただし「滑らかな画面更新」を重視するのなら、DirectXで全画面
占有タイプにした方が有利なことは有利かもしれない（開発の労力
は一気に増すがｗ）。

**名前は開発中のものです。** · 04/03/06 17:36

web上でゲームを公開しようと思っているのですが、
javaかflashだと重さを考えたらflashのほうがいいですか？

**名前は開発中のものです。** · 04/03/06 20:59

>>5-7
ご助言ありがとうございます。
とりあえずDirectGraphicsのテクスチャと
ヤネ氏のライブラリで速度を比べてみようかと
思います。（DirectX9.0には大分慣れたのですが、
Win32は、不慣れなので・・。）

**名前は開発中のものです。** · 04/03/10 19:48

DirectXのスプライトとテクスチャってどう違うの？
描画速度に違いはあるのかしら？

**名前は開発中のものです。** · 04/03/10 23:17

スプライトは概念、テクスチャは実装。

**名前は開発中のものです。** · 04/03/10 23:32

スプライトってのがD3DXSpriteのことを指してるなら、
それはテクスチャを含むDirect3Dのラッパーだよ。
で、ラッパーは常に元より遅い。
実際にどれくらい遅いかは知らん。

機能の違いは、2Dと3Dの違いだ。3Dは2Dを包含する。

**名前は開発中のものです。** · 04/03/11 12:01

ただまぁ、Summer 2003でスプライトの速度は改善されたそうです。
↓にもちょっとした話が。
http://www.plustarnet.com/aspil/Programming/2d06.htm

**名前は開発中のものです。** · 04/03/13 03:10

みなさん、浮動小数点数の型はどうやって決めていますか？
とりあえずは、思いつくのを列挙してみます。
ついでに、それぞれに個人的な意見を添えてみました。

1) 全部 double
+ルールとして単純。
+ゲームプログラム以外では、ほぼ常識？
-メモリ使用量が倍
-「浮動少数点」という言葉と直接繋がらないのが嫌。

2) 全部 float
+ルールとして単純。
+見た目が美しい。
+メモリにやさしい。
+ゲームプログラムではほぼ常識？
-精度が少なめ。
-環境によっては速度も double を下回る？

3) 目的別に typedef （float32,float64,fast_float,precise_float,...）
+移植性が高い。
+目的がコードに直接現れる。
+後で変更できる。
-どれだけ、どんな名前で定義したらいいのか？
-既存のインターフェースとやりとりするときに問題が？

とりあえず、3が正解っぽいなぁ、と思っています。
これら以外の選択肢があれば教えてほしいです。
また、意見のところの、「？」が付いてるもの（特に3のもの）について、
より確かな情報をいただけるとありがたいです。

**名前は開発中のものです。** · 04/03/13 03:16

>>14
DirectXだからfloat

**名前は開発中のものです。** · 04/03/13 03:29

DirectX9はfloat中心の方が速度的にイイ？

**名前は開発中のものです。** · 04/03/13 04:48

>>14
Cだけど整数型でやっている。3を3000としたりして。

**名前は開発中のものです。** · 04/03/13 05:30

>>17
割り算よりシフトの方がいいらしよ

**名前は開発中のものです。** · 04/03/13 11:35

PS2なんかは単精度しかないんだっけか。

そのうちdoubleが標準になるんかねえ。
floatだと広大なフィールドをリニアに扱えんし。

**名前は開発中のものです。** · 04/03/13 18:14

ファイヤーエムブレムとかタクティクスオウガみたいなシミュレーションＲＰＧを作ってるんだけど
敵の思考を考えるのが難しい

プレイヤー側ユニットとの距離を調べる
↓
一番近いユニットに近づく
↓
攻撃できる距離だったら攻撃する

みたいな感じで組んでるんだけど

・障害物
・攻撃スキルの特性（2マス離れてても攻撃可、とか回復スキルとか）
・移動した後攻撃するか、攻撃したあと移動するか　　etc...
そういう色々な要素が入ってくるとわけわからなくなる
素人は手を出さないほうがいいジャンルなんだろうか…

なにかコツとかあったら教えて下さい

**名前は開発中のものです。** · 04/03/13 18:26

障害物とか地形の異動量とかがある場合の最短距離の求め方は、
Ａ*サーチアルゴリズムとかを参考にすべし。
たとえば↓。探せばいっぱいあるはず。
http://gamdev.org/w/?%5B%5BAStarAlgorithmTutorial%5D%5D

どの行動を取れば一番いいかについては、可能な行動を全て列挙し、
それぞれに点数をつけ、一番点数の高かった行動を取らせるという方法が一般的。
この点数をつける評価関数を返ることによって、敵の強弱、特徴を出すことが出来る。

どうやって評価関数を作るかは、ゲーム内容による。一般的にこうすればよいとかいった
マニュアルは無い。行動の選択肢が非常に多くある場合、どう刈り取るかも問題となる。

というか、ＡＩの日本語で書かれた入門資料ってあるのかな？

参考リンク：
http://ai-depot.com/
http://www.gameai.com/
http://www.aiwisdom.com/index.html
http://www.ai-junkie.com/ai-junkie.html
http://www-cs-students.stanford.edu/~amitp/gameprog.html#ai

**名前は開発中のものです。** · 04/03/13 18:35

>>21
サンクスです

やはり難しそう・・・
やれるだけやってみます
いざとなったら要素削ってシンプルにするかな・・・

**名前は開発中のものです。** · 04/03/14 00:40

>>20
自分はFE風のを作った事があったが、その場合。

1:すべての移動できる位置、使用できるアイテムから、使用対象がいるか調べる。
　攻撃系なら敵、回復系なら味方。複数あるなら効果が一番高いものを選ぶ。
　攻撃系なら相手のHPを大きく減らせて(量ではなく%)、命中率がよく、
　逆に相手からはそれが低くなるもの、回復系の場合は回復%、命中が高いもの。
　同じアイテム、同じ対象に対して使用できる位置が複数あるなら、
　地形効果が高い場所から行動する。地形効果が同じなら歩数が一番少ない所から。
2:1の対象がいない、または攻撃すると逆に自分に及ぶ被害のほうが大きそうな時、
　移動のみを行い、強い味方によっていく、又は弱い敵によって行く。
　地形効果はもちろん高い所へ。

1はカウンタで全部調べればよいので簡単だったけど、
2は抽象的なので思うように動いてくれなくて難しかった。

作る順序としてはまずは1を作ってみるといいと思う。
全部調べるから速度的に大丈夫かと思うかもしれないけど
使用可能アイテム4つ、移動力10以上でも、遅くても2、3秒以内だったと思う。

**名無しさん、君に決めた！** · 04/03/14 03:50

>>17
それは浮動少数でなく固定少数ですな

普通は1024（=2＾10）とか4096（=2^12）を1とするのが速度的にいいよ。

**名前は開発中のものです。** · 04/03/14 14:32

2D時代は、2^8でずっとやってきたな。
ハードの制約だけど、その頃はこれが一番。

**名前は開発中のものです。** · 04/03/14 15:14

今もスケーリングを普通にやってるなー
↓みたいな感じで

dest[0] = dest[0] + ((dest[0] - src[0]) * alpha / 256);
...

**名前は開発中のものです。** · 04/03/14 15:18

src[0] - dest[0]の間違いか・・・

MMX命令よりもSSE命令で今は行うのが一般的なのかな？

**名前は開発中のものです。** · 04/03/15 10:22

固定小数点をマクロにしとくと（・∀・）ｲｲ

/* 固定小数点型 */
typedef signed long fix;

/* 整数⇔固定小数点 */
#define FIX_TO_INT( a ) (( a ) >> 16)
#define INT_TO_FIX( a ) (( a ) << 16)

/* 浮動小数点⇔固定小数点 */
#define FLOAT_TO_FIX( a ) (fix)(( a ) * 0xffff)
#define FIX_TO_FLOAT( a ) ((float)( a ) / (float)(0xffff))

**名前は開発中のものです。** · 04/03/15 12:11

いっそクラスにする手もあり。
コンパイラを信じられる漢におすすめ。

**名前は開発中のものです。** · 04/03/15 13:23

Windowsのメッセージループで質問なのだけど、GetMessage()を使うのと、
PeekMessage()を使うのはどちらが主流なのかな？
GetMessage()+SetTimer()はFPSが微妙に安定しないし、PeekMessage()だと
CPUを100%使いかねない。
個人的にはCPUを100%使ってしかもムダ使いというのはマルチタスクOSでの
プログラミングとしては礼儀違反と思うし、例えば落ちゲーとかブロック崩し
なんかでCPU100%てのは納得もいかない。
SetTimer()での安定の悪さを考えて、1msecでWM_TIMERを発生させたあとに
timeGetTime()で実際の時間を取得、ずれを調整するようにしてみた。
WM_TIMER自体が１～20msecで発生しているようで、とても60fpsなゲームなんて
作れないなあと思った。
常識的な方法があるなら知りたい。

**名前は開発中のものです。** · 04/03/15 13:26

あともう一つ。
よくベンチマークで、400fpsとかいう数値があったりするけれど、
あれって何？　画面自体はせいぜい120fpsでるかどうかでしょ。
オレのモニタは液晶だから60だけど、CRTでも80とかじゃない？
400って表示しているFPSじゃなくて、演算可能な理論値ってことなのかな？

**名前は開発中のものです。** · 04/03/15 13:33

>CPUを100%使いかねない。
Sleep入れればいいじゃん。

>よくベンチマークで、400fpsとかいう数値があったりするけれど、
>あれって何？　画面自体はせいぜい120fpsでるかどうかでしょ。
blitやポリゴン描画なんかの処理とモニタに出力する処理はほぼ平行に行われるから
そういう「描画処理」自体はモニタの同期信号の周波数とは関係ない。
普通HBLANKを待つから最大fps＝リフレッシュレートなことが多い、というだけ。

**名前は開発中のものです。** · 04/03/15 14:54

>>30
GetMessageで。WindowsなどＶブランクをシステムが管理している場合は
ゲームスピードをＦＰＳ基準にすべきではない。75Hzの人もいれば60Hzの
人もいるのでＶブランクではなく時間を基準にすべし。WM_TIMERは200ms
程度の精度（実際は変動あり）しかないのでMultiMediaTimerを使うしかない
と思われる。

Ｖブランクに関係なく処理が終わったら画面更新という設計にしておいて、
アニメーションは時間単位で制御する方針で。

>>31
Ｖブランクを待たずに画面更新をした場合の１秒間のフレーム更新回数。
コンシューマゲームと違ってVSyncはシステムが管理しているので、描画
ラスターがどこにいるかは意識する必要がない。

**名前は開発中のものです。** · 04/03/15 15:05

あと、タイマーの精度については↓こんな文書があるので参考にしましょう！

GetTickCount, timeGetTime等の精度について
http://www.emit.jp/prog/prog_t1.html

**名前は開発中のものです。** · 04/03/15 16:34

FF風のRPGのゲームを作るプログラムは何が最適かな？
2Dで作りたいんですが。

**名前は開発中のものです。** · 04/03/15 16:58

FFのどれだよ

**名前は開発中のものです。** · 04/03/15 17:43

>>32 >>33
おー。レスありがと。30&31です。
そか、fps表示は理論値ってことだね。納得。

IDirectDraw7::WaitForVerticalBlankでVSYNC待ちをするよう
作っていた。そのあとでバックサーフェースからフロントサーフェースに
IDirectDrawSurface7::Bltで画面転送していたけれど、試しにVSYNC待ちを
削ってみても問題なく動作した。そういうものだったのか。
Blt後にGetScanLineでVライン位置を取ってみると1027～1031くらいの
数値が出る（縦1024のモニタ）から、自動的にVSYNC待ちをしてたんだね。
無駄なことをしてたワ。

なるほど、Sleep()はtimeBeginPeriod()と使うと誤差が減るのか。
PeekMessage()+Sleep()を試してみるよ。サンクス！

**名前は開発中のものです。** · 04/03/15 18:25

VC.NET2003にて
デバッグモードだと普通に動いてるのに
リリースモードにするとエラります(；´д⊂)
このような状況に陥る可能性にはどんな物があるでしょうか

**名前は開発中のものです。** · 04/03/15 18:33

>>38
メモリリーク。
あるいはライブラリとのデバッグ/リリースモードの不整合。

**名前は開発中のものです。** · 04/03/15 18:50

加えて
・変数、配列の初期化ミス
・配列や確保したメモリの境界を越えたアクセスにより他の変数が壊れた
とかも。
いずれもデバッガじゃ追いにくいやつやね。
がんがれ。

**名前は開発中のものです。** · 04/03/15 19:08

半透明ポリゴンのZソートを高速に行う方法を教えてください。
検索をかけたのですが、アルゴリズムを見つけられませんでした。

今やってるやり方は、
３角形の重心を透視変換して計算したＺ値 0.0～1.0を
もとにクイックソートをつかって並び替えています。

この方法が一般的でしょうか？

**名前は開発中のものです。** · 04/03/15 19:49

いいんじゃない

**名前は開発中のものです。** · 04/03/15 23:18

俺がこの前作ったゲームは、面倒だったのでstable_sort一発にしてしまった。
仮のつもりだったのに何の問題もないから不思議だ。富豪的プログラミングマンセー

**名前は開発中のものです。** · 04/03/16 16:37

>>41
0.0～1.0の値を、たとえば0-255とか0-1023の値にマッピングする。
あとは256個なり1024個なりのインデックステーブルを用意して、
マップした値のテーブルにポリゴンを登録する。

全部の登録が終わったら、テーブル順に描画すればいい。

**名前は開発中のものです。** · 04/03/16 20:05

バケツソートですな。

**名前は開発中のものです。** · 04/03/16 23:07

>>41
「Bitonic sort」これって関係あり？
当方、画像プログラムをやった事の無いヘタレなんで、
もし勘違いだったらスマソ。
t-potさんところが詳しいです。

**名前は開発中のものです。** · 04/03/16 23:40

これは一種の未来技術かと。

41 · 04/03/17 01:12

＞＞44
ありがとうございます。

Ｚ値をある程度の配列に割り振って、
精度的に問題があれば配列の数を増やしていくということですね。

ただちょっと疑問があるのですが、
インデックステーブルが 100 などの値でなく
256、1024　のように２の乗数なのはなにか理由があるのでしょうか？

Z値1.0から1024個のインデックスを求めるときには
int index = (int)(z * 1024.0f);
といった具合に計算するのでしょうか？

**名前は開発中のものです。** · 04/03/17 15:40

>>48
単純にシフトで計算しやすい値というだけの話。別に１０個でも１００個でも１０００個でも
好きな数を割り当てればいい。
それから、ある１つのテーブル要素に対して複数のポリゴンが割り当てられる可能性を
考慮して組むこと。具体的にはインデックステーブルをポインタテーブルにして、リンク
各要素からリンクリストがぶらさがるようなイメージかな。

**名前は開発中のものです。** · 04/03/18 09:07

OTってやつ?

**名前は開発中のものです。** · 04/03/18 09:47

OTZではない。

**名前は開発中のものです。** · 04/03/19 23:21

**名前は開発中のものです。** · 04/03/24 09:40

QVGA(320×240) の解像度ってどんなグラフィックカードでもサポートしてる?

**名前は開発中のものです。** · 04/03/24 10:02

してないと思った方がいい
３２０＊２４０で処理して６４０＊４８０へ拡大ｂｌｔがいいだろう

**名前は開発中のものです。** · 04/03/29 09:22

>>41
ちょっと複雑になるけど、BSP（２分空間分割)木を使ってもできると思う。
それぞれの半透明ポリゴンを一つのノードとして半透明ポリゴンモデルの
BSPデータベースを作っておいて、
ランタイムで、
・BSP空間へ視点を変換。
・視点の裏面になるノードを選び続けて、葉（末節）に達したらそのノードの
半透明ポリゴンをバーテックスバッファにコピー。
・以降、木を表面に遡っていけば、結果バーテックスバッファにポリゴンが
ソートされている。
ノード毎に視線ベクトルと面の内積を計算しなきゃいけないのが難か？
素直にソートした方が早そうだ。

**名前は開発中のものです。** · 04/03/29 09:26

>>48
＞int index = (int)(z * 1024.0f);

z=0.0のとき index=0,
z=1.0のとき index=1023
にしたいんだから、
int index = (int)(z * 1023.0f);

**名前は開発中のものです。** · 04/03/29 12:02

いつでも60fpsを目指した結果以下のようなコードになったのですが
なんかもう頭が混乱して自分でやってることが良くわからなくなってしまいました。
一応思ったとおりに動作するのですが、どうも不安です。
改善点などのアドバイスをお願いします。

DWORD fps60wait[] = {17,17,17,16};

ima_time = timeGetTime();
dtime = ima_time - sakki_time;
if ( dtime < 11 )
{
　lpDD->WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN, 0);
}
counter = (counter % 4) + 1;
wait = fps60wait[counter - 1];

do {
　ima_time = timeGetTime();
　dtime = ima_time - sakki_time;
　Sleep(0);
} while(dtime < wait);

sakki_time = ima_time;

＜描画＞
＜処理＞

**名前は開発中のものです。** · 04/03/29 13:33

>>57
Windows環境のプログラムでしょ。なぜ60FPSにこだわる必要があるんだろう。
>>33参照。

57 · 04/03/29 23:22

>>58
60FPSは実はどーでもいいんですが
既に60固定で作っちゃったんで>>57に問題がないか知りたいんです。
>>33はとにかくVSYNCは無視しろってことですよね。

**名前は開発中のものです。** · 04/04/03 11:39

ゲームを作るうえでいきなりシュミレーションゲームを作る
のはやはり無謀でしょうか？
もっと簡単なのから作るのが普通でしょうか？

**名前は開発中のものです。** · 04/04/03 12:04

>>60
シミュレーションってウォーシミュレーション？
ならここ↓の問題設定で手も足も出ないと感じたら
http://pc5.2ch.net/test/read.cgi/gamedev/1079745509/
ブロック崩しとかから五目並べみたいなのからやってみた方がいいと思う。
サンプルも探しやすいしね。

62 · 04/04/03 14:32

動く絵を表示させるプログラムで、綺麗にプログラムを書きたいと思っているのですが自分ではどうにも・・・。
とりあえず自分がいま使ってるやり方を書きます。

if(a>1&&a<10){
a++;
１枚目の絵を表示させる}
if(a>11&&a<20){
a++;
２枚目の絵を表示させる}
if(a>21&&a<30){
a++;
３枚目の絵を表示させる}
if(a==30)
a==1;

こんな感じで動く絵を表示させているのですが、どうも見た目が汚いと思います。
うまい方々はこうゆうプログラムをどう書くのでしょうか？

**名前は開発中のものです。** · 04/04/03 14:40

aってナニ
絵ってナニ
いつ実行してるの

62 · 04/04/03 15:06

aは整数の変数を表しています。
絵というのは絵１・絵２・絵３でパラパラ漫画の用になっています。

つまり、これは段々と絵が１・２・３へと変わっていくプログラムです。
自分がしたい事はメインのループを１０回ループすると絵が１枚づつ変わっていくようなものです。

わかりましたでしょうか？

**名前は開発中のものです。** · 04/04/03 15:39

Picture *lPicture[3];
int indexPic = 0;

lPicture[0] = &picture1;
lPicture[1] = &picture2;
lPicture[2] = &picture3;

for(int i=0; ; i++)
{
　　if (i%10 == 0)
　　{
　　　　indexPic ++;
　　　　if (indexPic > 3)
　　　　{
　　　　　　indexPic = 0;
　　　　　　i = 0;
　　　　}
　　}
　　DrawPicture(lPicture[indexPic]);
}

**名前は開発中のものです。** · 04/04/03 15:52

>>62

こんな感じで、タイマー使ってやんないと、まともにタイミング取れないと思う。
タイマーは独立したスレッドで、タイマー満了コールバックとかでやる方法もある。

const int numPictures = 20; //フレーム数２０枚
const float secPerFrame = 0.1f; // １フレーム0.1秒＝毎秒10枚
int idx = 0;
float sumDt = 0;
long prevTime = timeGetTime();
while( true )//永久に
{
　float dt;
　long currentTime = timeGetTime();
　dt = float(currentTime - prevTime)/1000.0f;
　prevTime = currentTime;
　sumDt += dt;
　if( sumDt >= secPerFrame )
　{
　　//idx番目の絵を表示
　　idx++;
　　if( idx == numPictures )
　　　idx = 0;
　　sumDt = 0;
　}
}

**名前は開発中のものです。** · 04/04/03 21:02

>>62 正直やりすぎた
template<unsigned int Max, typename Son = EmptyCounter>
class LoopCounter
{
protected:
　　Son　　　　　　 m_Son;
　　unsigned int　　m_Count;
public:
　　LoopCounter() : m_Count(0) {}
　　bool Inc()
　　{
　　　　if (m_Son.Inc())
　　　　{
　　　　　　if (++m_Count == Max)
　　　　　　{
　　　　　　　　m_Count = 0;
　　　　　　　　return true;
　　　　　　}
　　　　}
　　　　return false;
　　}
　　unsigned int Get() const { return m_Count; }
};
struct EmptyCounter
{ bool Inc() { return true; } };
//作成
　　LoopCounter<3, LoopCounter<10> > AnmCounter;
//ループ
　　Draw(AnmCounter.Get());
　　AnmCounter.Inc();

62 · 04/04/03 22:16

返答ありがとうございます。
とりあえず、すべて試してみようと思います。

**名前は開発中のものです。** · 04/04/03 23:32

そもそも、アニメを制御するのに切り替えをプログラムで直接書こうという
考えから改めるべきだな。
データを読み取って、指定された時間に指定された絵を書くプログラムを書け。

**名前は開発中のものです。** · 04/04/05 09:52

教えて君で申し訳ないけど、
ネットリソースではなかなか見つからなかったので質問させてください。

2Dアクションゲームでモーション中に別モーションを呼ぶ場合、
（例：ダッシュ中にパンチ、パンチキャンセルでキック等など）
モーション要求はスタックに積むのが常道でしょうか？

ダッシュとジャンプはそれぞれ加速度と重力変数で判別できるのですが、
キャンセル系について、たとえばガードキャンセル＋パンチキャンセル＋キックといった
コマンド技に似たもので、自分がどんなことをしてきたかの遷移がわからないのです。

一応コーディングしてみると、直前モーションを保存するとif文の数が40個ぐらいになってしまいました。
STLって何？っていう厨房なので、スタック以外にも方法があればご教授おねがいします m(--)m

**名前は開発中のものです。** · 04/04/05 17:41

>>70
スタックに積む＝１モーション完了して次モーション
だと、いわゆるスト２の「キャンセル」っぽい動きにはならない。
ちなみにスト２のキャンセルは行きと戻りのモーションがあって、
行きモーション中にコマンドが成功したら戻りを「キャンセル」して
次モーションにつながることから。おそらく行きモーションと戻り
モーションが別コントロールになってるんだろうね。
どういう動きをさせたいのか頭の中を整理してみるほうがいい。

**名前は開発中のものです。** · 04/04/05 17:44

３Dゲーつくってます。
主人公キャラの位置をRAYにして、地形と障害物とのあたり判定をしようと思っています。
とりあえず、移動方向に1フレームの移動分だけレイを飛ばして速度ベクトルをその真下にしました。
地形に沿って移動はできるのですが、この方法では主人公とおなじ高さで垂直に立ってる壁とか、こっちに向かって傾斜しているポリゴンがあると困ります。
はじめにレイを進行方向に飛ばすときもあたり判定を計算すると2倍の計算量になってしまいますが、仕方ないのでしょうか。

**名前は開発中のものです。** · 04/04/05 20:32

>>72
何を言いたいのかさっぱりわかりません。

もっとわかりやすく書いて、
改行も入れてください。

**名前は開発中のものです。** · 04/04/08 01:27

計算量を減らすようにすればいいんじゃねぇか？
どんなやり方してるかしらないけど。
アタリを分割すれば計算量は抑えられる。
AABBツリーを調べてみて。

**名前は開発中のものです。** · 04/04/13 02:27

スーパーマリオブラザーズみたいなのを作ろうと思ってます。
今のところスクロールまで作ったのですが、画面のちらつきが気になってしかたありません。
一応バックバッファに描いてから転送するようにしています。
http://gamdev.org/up/img/475.zip

よければ解決策を教えてください。

**名前は開発中のものです。** · 04/04/13 11:44

特にちらついてないように見える
もしかしてティアリングのこといってるの？

**名前は開発中のものです。** · 04/04/13 12:33

>>75
「リフレッシュレートに関する論争」スレでも検索してみるといいことがあるかも。
解決しようとするとちょっとした闇に踏み込むことになるので、覚悟するように。

75 · 04/04/14 00:41

まさにそのティアリングってやつですね、たぶん。
スレを読んだりして見ましたけど、なんかめんどいんでこのまま進めることにします。
余力があったら考えてみたいと思います。
ありがとうございました。

**名前は開発中のものです。** · 04/04/14 01:24

フルスクリーンモードにしてフリップ使えば大概ティアリングは解消できる

が、垂直同期周波数が環境によって違うことも多いために
垂直同期とってもゲーム内の描画とのずれでカクカクしてくることもある

その辺がばっちり解決してもWinがリアルタイムＯＳでない時点で完璧には無理

どの辺で妥協するかが重要と思われ
タイマとフリップ併用が一番いいと思うけどね

**名前は開発中のものです。** · 04/04/14 02:16

リフレッシュのタイミングとゲームのタイミングが完全にシンクロしない限り
RTOSでも無理だから。

**名前は開発中のものです。** · 04/04/16 17:56

はじめまして
とあるPDAで擬似的な3ＤのGAMEを作りたいと思っています。
2Dではいくつか作って公開していますが､PDAの3Dの場合
自力で書くしかないでしょう。
今､市販されている3DプログラミングものはDirextＸを利用した3Ｄエンジンを使用したものが
多いですね
そうではなく自力で（ある程度はしょったモノになると思います。PDAだから）3Dを書きたい人におすすめな
書籍（もちろんWindows95前後の頃のものだと思うのですが）のタイトルと簡単などういう感じか
教えてもらえないでしょうか？

※こういった質問はここでよろしかったでしょうか？　よろしくお願いします。
言語はＣもしくはＣ++です。
上げさせていただいてもいいでしょうか？

**名前は開発中のものです。** · 04/04/16 18:03

>>81
D3Dのマニュアル

81 · 04/04/16 18:15

>>82
申し訳ありません　D3Dとは何かの略でしょうか？
検索してみたのですが　海外の会社ばかり引っかかるようです
フルネームを教えてくださいませんでしょうか？
お手数をおかけしますがよろしくお願いします

**名前は開発中のものです。** · 04/04/16 18:23

>>83
Direct3Dだよ。

基礎知識のページに
ジオメトリやトランスフォーム、ラスタ化ルールとか
入門に必要な情報はみんな書いてある。

81 · 04/04/16 18:43

ありがとうございます！！　Direct3Dですね
MSのサイトが引っかかりました。
ttp://www.microsoft.com/japan/msdn/academic/Articles/DirectX/01/

基礎知識のページとはここでいいでしょうか？
あとDirect3Dのヘルプにも詳しいそうですね。

**名前は開発中のものです。** · 04/04/16 19:29

>>85
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/DirectX9_c/directx/graphics/programmingguide/gettingstarted/gettingstarted.asp

ここだけど、3Dトランスフォームとかの文章がなくなっちゃってるね。
DirectX7.0迄のマニュアルを落としてきて参照するのがいいかと。

81 · 04/04/16 20:07

>>86

ありがとうございます。
ttp://www.microsoft.com/downloads/details.aspx?FamilyID=3a9531f6-577c-4748-b59c-2197014f544e&displaylang=ja
より　DirectX7.0ドキュメントを落としております。
感謝しています。

あのう……　非常に図々しいのですがDOSの時代ってDirectXとか無かったわけですよね
DOOMとか……　あのころの技術とこのDirectX7.0に載っている技術とは基本は変わらないと思っていて
いいでしょうか？
DOOMでは、見えないモノは書かない、省略、上下の省略などで稼いでいたようですがこれってこれから
生まれた技術でしょうか？　ちょっとWindows以外なのでDOOMが参考になるかと検索しているんです。
きっちりとした3Dを必要としてないものですから　

それと同時に3Ｄの基本の情報を知りたかったのでこちらは本当に助かりました。
本当にありがとうございます。

81 · 04/04/16 20:15

CMAGAZINEの　2000年　1月号にDOOMの仕組みと
2002年　6月号に3Dダンジョンの作成と表示の基本アルゴリズム（DOOMも絡む）
がありますね

これを求めたいと思います
他の人の参考になれば。

**名前は開発中のものです。** · 04/04/16 21:26

>>81
似非3DならダンジョンマスターとかWizardryとかそっち系のほうがいい気がしないでもない

**名前は開発中のものです。** · 04/04/16 22:18

>>89
その手のも作っては見ますが、升目式ダンジョンではなく同じような感じの道が
ないようにしたいわけです。
なんとなくそらで道を覚えられるみたいな感じに出来たらと考えていますので。

**名前は開発中のものです。** · 04/04/16 23:40

>81
キャノンからでたRenderWareの分厚い本。
３Ｄエンジンを作るにあたって生じた技術資料を適当にまとめて
「プロご用達！」などとうたって１万前後で販売！
ＣＤにはRenderWareが入ってるが、これを使ったソフトを配布してはならないという罠。
クラリオンに聞くと「学習用ですので」。氏ね。

81 · 04/04/17 00:32

>>91
それってプロ御用達と学習用と矛盾してますな。誰が見てもわかるところに
これを使ったソフトの配布禁止と書かれていて、学習用と書かれているのでしょうか？
（だったらこんなに怒るわけないよな……）
とあるソフトのマニュアル的なものなんでしょうねえ

そういう３Ｄプログラミング物多いですよね　以外と。

**名前は開発中のものです。** · 04/04/17 01:28

>>81
3Dプログラミングってどう言ったレベルを想定してるか分らないが
自前実装って言うならラスタライズやら必要だよね？

"コンピュータグラフィックス理論と実践"

辺りで良いんでないの？12000円と手頃だし。
特定ハードに依存(API等)しない
3Dの数学的理論、3Dの工業的理論(汎用的なコンピューター理論)
を身に付ければ、自前実装はスグできるようになる。

その前に、実装実機の理解は必須だと思うけど。

**名前は開発中のものです。** · 04/04/17 03:02

>>93
この本ってさ、１つの話題に対しての密度薄すぎねぇ？
技術の名前だけのってて「はぁ？こりゃなんも説明できてねぇよ」
ってのが多々あるぞ。
式出したらせめて各変数の意味ぐらい書いとけってのが多々あってﾑｶﾂｸ。

**名前は開発中のものです。** · 04/04/17 05:17

>>94
自分のレベルに合わない本は、皆そう感じる物じゃない？
それに、自分の望むチャプターのみで、更にそれが根ほり葉ほり事細かな内容ってありえないでしょ。

DirectXのhelp読んで、
＞１つの話題に対しての密度薄すぎねぇ？
＞技術の名前だけのってて「はぁ？こりゃなんも説明できてねぇよ」
＞式出したらせめて各変数の意味ぐらい書いとけ
何て言い出す人間の大半は
プログラムとC++と3Dプログラミングの基礎を持ってから読もうねって、感じの人間が多いと思う。
それと同じかな…？って思うけど…

違うなら、不満や不足に感じる部分は、他の本や他の情報源、
そして自分の頭で解決ってなる物でしょ？
幾ら何でも、答え頂戴、全部教えて、クレクレって方針はありえないでしょ。

普通に数学の基礎とハードの基礎とプログラムの基礎を持って読めば
十分な内容でしょ、12000円程度の価格なんだし。

**名前は開発中のものです。** · 04/04/17 07:53

>>94
あんた序文や前書きちゃんと読んでるか？
俺はこの本は持ってないが、
同系統の「Real-Time Rendering」だと
「各トピックについて深く知りたい場合は、
参考文献を充実させたのでそちらを参照してくれ」
ってちゃんと書いてあるんだが。

**名前は開発中のものです。** · 04/04/17 09:41

>>95 >>96
はてさて、どちらが正しいのやら。
>>95の方が読んだ事無いように見えるけど

**名前は開発中のものです。** · 04/04/17 16:07

>>96
＞同系統の「Real-Time Rendering」
両方もってるが、全然同系統じゃないぞ。
Real-Time Renderingの方は原本の奴で英語だけど。

コンピュータグラフィックス理論と実践は
主にはCGをコンピューターで扱う原理を解説してる。
点を定義してそれらを結んでピクセルを塗る原理(ライスライズ)とか
つまり、普段はハードやらAPIが処理してる低レベル部分の理論的説明が主。
つまり、3Dソフト自体を開発したり、
DirectX使わないでWindowsでポリゴン自力描画(WinAPIは使うけど)実装したり
(勉強で昔やった)って勉強が出来る。

Real-Time Renderingはその名の通り、もうダブルバッファ前提で
いかにリアルタイムで処理時間を稼ぐとかの技術が主にある。
しかも、参考文献ってさ、文献として上がってる
本の著者と名前が載ってるだけだと思うが？

コンピューターCGの本と3Dプログラムの本、同系統では無いと思うけど？

**名前は開発中のものです。** · 04/04/25 12:00

戦闘シュミレーションゲームつくるのに
Cは向いていますか？
またいいツールとかありませんか？

**名前は開発中のものです。** · 04/04/25 12:06

どういう物かはわからんが言語はまず関係ないと思った方がいいぞ

**名前は開発中のものです。** · 04/04/25 12:14

ということはCをちゃんと使えるようにさえなれば
作れると言うことですか？
今勉強中ですが、Cってゲーム作れるのか？
と不安になってきました。
絵の表示の仕方がいまだにわかんないし・・・

**名前は開発中のものです。** · 04/04/25 12:17

逆にいえばその程度でつまずくなら（失礼）Ｃにこだわる必要ないんじゃないの？
絵を表示するコードが１行の命令で、画面の初期化もらくちんって環境は
世の中にたくさんあるよ。

Ｃの利点は何でもやろうと思えば細かいことは出来るというだけで
その利点もハードガリガリアクセスする環境ならともかく
Winとかだとほとんどメリットないね

**名前は開発中のものです。** · 04/04/25 12:29

そうですか・・・
ちなにみ皆さんはこういうゲームを作るときは
どの言語を使ってるんですか？

**名前は開発中のものです。** · 04/04/25 13:14

確かに言語によってと喰い不得意はあるものの
結局使い慣れた物が一番だと思う

最近はスクリプト系も結構あるから言語になれて内人はそっちがいいかな
俺はやはりＣ／Ｃ＋＋を長くやっていたから言語体系が近いｊａｖａとＣだな
Ｃ＋＋で中途半端なオブジェクト指向やるくらいならｊａｖａいったほうがいいし、
シンプルにガリガリ叩くときにはＣって感じ
ｊａｖａだと画像表示やらシステム部分に時間をかけないでゲームの処理のみに
専念できてる感じがいい
Ｃとかはもちろん必要コード量が多くなるのでライブラリ整備が必須になって
変にシステムをいじってばかりでゲームに専念できないことも多い＾＾；

>>103がさわれそうな環境はＣ以外になにかあるの？
画像表示からうまくできてないということはDIBやらDirectXから出来るようになるには
かなり時間かかると思うから他を勧めたい

**名前は開発中のものです。** · 04/04/25 13:34

親が自営でC++のプログラマやっているので
もっとも勉強しやすい環境にあるのはCだと想います。

こだわりと言うわけではありませんが、
できればCで作りたいと思っています。

＞画像表示からうまくできてない
まだ勉強中なのでそこまで達していなのかもしれません
一応C入門の本は1冊読んだのですが・・・

**名前は開発中のものです。** · 04/04/25 14:07

「高校受験したいんです。小学校の課程は修了しました」
みたいなもんだな。

CでやるとしてもまずはコンソールじゃなくWindowsプログラミングやらんといかんし。
まーいっそコンソール＆glutって手もあるが。

**名前は開発中のものです。** · 04/04/25 14:22

そもそも言語が分かってさらにＧＵＩまわりも分かっていても
ゲームプログラムが全く出来ない人もたくさんいる

ゲームに必要な知識と、そのプラットフォームで絵を出すとか
システムに必要な知識は全く別物なわけで

逆にスタンドアロンのゲームは作れるけどウインドウシステム上での
ゲームは作れないという人もいる

今のちみの状態は分からないことが多すぎかと
言語自体も本読んだというレベルなら表面上のものだけだと思うので
ポインタガンガン使えるというレベルまで言ってないと思われ

一番重要なのは目的がゲームを作ることなのか、それともＣ言語を
勉強したいのかってところだよ

昔はＣ言語＆ゲーム作りたいってことが多かったと思うけどこれは
生産性を上げつつマシンスペックが低かった時代これしか選択肢がなかっただけ
8bit時代BASICでゲーム作って遅かったのでしかたなくハンドアセンブルへ
そして16bitになりメモリが多少裕福になってＣ言語へって人は多いはず

言語が目的ではないんだよ
それにプログラマは複数の言語が使えるのが普通
１つの言語で今後もいくとは思えない

**名前は開発中のものです。** · 04/04/25 14:52

とりあえず今ある知識でゲーム作ろうというのが、
かなり無謀だったみたいですね。
もちろんゲーム作成が目的ですが、
今は置いておいて、Cをがんがん使えるようになろうと思います

**名前は開発中のものです。** · 04/04/25 15:36

まずCをしっかりできるようにして、
次にC++をいくらかかじって、
あとはDirectXに進めばOK。

このQ&Aってもう何度もされてるよね。
ゲームプログラミングのまともな入門サイトor本がないということだろう。
どうにかならないもんかね？

**名前は開発中のものです。** · 04/04/25 15:47

昔はパソコンでのプログラム＝ゲーム作るだったからな
それほど山のように雑誌はあった

ベーマガ、ＭＳＸＦＡＮなど読みやすくて分かりやすいシンプルな物がないからね
あとは個人レベルで作る物と商業レベルとでできあがる物が違いすぎるというか

でも昔から初心者向けと上級者向けはあってもその間の中レベル向けが
ほとんど存在しないと言う問題もあったよ

たとえばＣ言語は分かって絵も描画できる、でも具体的にゲームで必須な
垂直同期がなんなのかとかラスター割り込みがどうとかそういった物は
なかなかいいものはなかった

DirectXやるときC++よりCでやったほうが楽な気がする

**名前は開発中のものです。** · 04/04/25 15:58

楽というか
綺麗な使い方が出来ないと思うC++

**名前は開発中のものです。** · 04/04/25 16:18

綺麗な使い方ってどんなの？
DirectXやったことないけど、呼び出すだけだからどっちでも一緒じゃ？

**名前は開発中のものです。** · 04/04/26 09:29

CだとCOMを間接的に呼ばなければならないので、
綺麗な使い方には絶対にならない。

**名前は開発中のものです。** · 04/04/26 15:22

>>113
いや、そういうことじゃなくて、アレだろ？
Ｃ＋＋なんだけどＣ風に組むとかそんなんだろ。多分。

でも、Ｃ＋＋風に組んだ方が楽だと思うけどね。俺は。

**名前は開発中のものです。** · 04/04/28 01:45

>>111
潔癖主義かつ無能なら何を使っても汚く感じるだろう。

**名前は開発中のものです。** · 04/04/28 15:15

いや、C++は特別だろ。

**名前は開発中のものです。** · 04/04/28 20:35

俺はC++でDirectX使ってるが、デザインはうっとりしてしまうほど綺麗にできてるよ。
なにが汚くなる可能性があるのか具体的に言ってみろばかー

**名前は開発中のものです。** · 04/04/28 20:38

一人よがり

**名前は開発中のものです。** · 04/04/28 20:52

思わずモニタにティンコこすりつけたくなっちゃうくらい
清純可憐で微妙なエロスの漂う穢れのないコードかけてるっつーの

**名前は開発中のものです。** · 04/04/28 23:03

じゃぁ見せろ

**名前は開発中のものです。** · 04/04/29 00:07

>>116
特別ですね。
言語レベルで厳格な貞操帯を装着しないと、猿のようにオナーニを
いえ独り善がりな汚いコードを書いてしまう無能には「C++は特別」です。
特別汚いコードを書ける言語です。彼等にとっては大きな問題です。
貞操帯を装着しなくても問題の無い一般人にとっては瑣末な問題です。

**名前は開発中のものです。** · 04/04/29 01:29

平和なやつらだ。C#とかDとか試してみたことないんだろうな。

**名前は開発中のものです。** · 04/04/29 03:54

Dは処理系がひとつしかないし、バグバグだからなぁ

**名前は開発中のものです。** · 04/04/29 04:02

class CCharacter : public CEntity, public CRenderNode, public CCollisionNode {};

CEntityは自律行動を行うクラスで主にAIの更新を行う仮想関数Update()を持つ。
CRenderNodeはレンダラに登録され描画を行う仮想関数Render()を持つ。
CCollisionNodeはデフォルトの当たり判定を実装してあって衝突を検出したら仮想関数Collide()を呼び出す。

関連性のない３つのクラスからの多重派生ですがこれは邪道でしょうか？
また、みなさんはこの３つの要素をどの様にクラス化してますか？
ご意見お聞かせくださいませ。

**名前は開発中のものです。** · 04/04/29 04:54

>>122
平和な奴だ。糞汚いコードを書いてばかりの低脳に
Java、C#、Dを試させてみたことがないんだろうな。

言語仕様上の規定（貞操）が厳格であるために
クルクルパーな悪性のハックは多少は減るが
やっぱりおかしなコードを書くんだよ。

馬鹿に付ける薬は無い。言語変えても駄目な奴は駄目。

**名前は開発中のものです。** · 04/04/29 05:01

>>124
俺の場合、

class CCharacter : public CEntity

CRenderNode,CCollisionNodeはCCharacterのメンバ

理由は、描画リソース、コリジョンはいらないキャラのいるから。
例えば、ジェネレータとか。

とある理由で、CEntityをメンバにした事もある。

**名前は開発中のものです。** · 04/04/29 05:08

>>124
邪道・正道にはとやかく言及しないが
「～Node」な２つの基底クラスの間で名前衝突が起きないってのが
ぶっちゃけあり得ない。背後にぐちゃぐちゃなメソッドの群れの気配がする。

**名前は開発中のものです。** · 04/04/29 08:15

>>124
肝心なのはその上位で、CCharacterのインスタンスの集合を管理しているクラスが
こいつをどういう風に扱うかにあると思う。
誰がどうやって生成して、どういうリストに組み込まれて、誰がメソッドを呼び出して、
誰がどうやって破棄している？

**名前は開発中のものです。** · 04/04/29 09:54

>>124
俺はちょっと違うなCharacter以外はCharacterのメンバにする。
ちょっと>>124は機能とオブジェクトをいっしょにしてるのがよくなさげ。
継承で考慮するのはオブジェクト指向の説明でよく出てくる
犬と猫は哺乳類で・・・云々の話だけでいい。
もしEnemyなんてのが出てきたら、Characterから継承するって感じの使い方かな。

EntityやRender、Collisionなんてのは明らかに
Characterが所有しちょるものなのでメンバでいいと思う。
Characterより上の方のクラスに入れるかもしれないものもあるね。描画とか。

まあ、クラスのまとめ方が、複数のクラスの処理を一括してやろうと頑張りすぎてて、
かつ、これから継承するものの違いまでカバーしようとしている感じがする。正直うまくない。
まあ、処理で考えるなら、
衝突の検出なんてのは関わるもの同士によって必要な情報が全然違うから
一括処理なんて必要ないならしないほうがいいと思うよ。（仕様変更あると思うしｗ）
逆に描画なんてのはどれも同じ処理になるはずじゃね？
Characterもしくはその基底クラスがRenderなんて関数をもってればそれでいいような気がする。

ＡＩクラスなんていったら、結構隔離できるクラスのような気がするが
実は他のクラスとの関連が一番多くなるクラス、また、他のクラスとの関連も一番特殊になるクラスだと思う。
何せＡＩの判断材料に他のクラスの情報が確実に必要になるからね。
ＡＩってのはCharacterそのものになると思うんだけどどうだろうか？
例えばCharacterから範囲１０以上に近づいたら、なんてやったらＡＩにCollisionのデータを使った衝突の検出が必要になるよね？
こういう処理自体をライブラリにするのはいいと思うけど、それに必要になる材料はもろにクラス同士の設計の関連になるわけで略ｗ

**124** · 04/04/29 13:08

>>126
CCollisionNodeをメンバにするのは考えましたが、
CRenderNodeをメンバにしてしまうと自身で描画コードを持てないので
描画情報を登録して後で一括描画してもらうって形ですよね。
この場合ちょっと複雑な事をやりたい場合にCRenderNodeに手を加えるハメになりそうですがどうでしょうか？
2Dなら描画形態は限られてくるのでメンバに持ってしまうかもしれませんが。

**124** · 04/04/29 13:09

>>127
～Node系は特定の機能を保有する事を保証するインターフェイスのような物なので今のところ名前の衝突はないですが、
拡張した場合に仰るとおりのぐちゃぐちゃなメソッドの群れになる可能性は大いにありますね。

**124** · 04/04/29 13:09

>>128
生成は各entityが任意にnewしてEntity管理クラスに突っ込み、
entityMgr.Add(new CEnemy); // class CEnemy : public CCharacter

各entityが初期化時に必要に応じて描画管理クラスやコリジョン管理クラスに自身を登録してます。
renderer.Add(this);
collisionMgr.Add(this);

各管理クラスが全登録インスタンスの仮想関数 Update(), Render(), Collide() を呼び出しており、
entity間のやりとりはentityMgr経由でメッセージを送受信して行ってます。

破棄は自分自身でentity管理クラスに破棄要求を出してentity管理クラスがインスタンスをdeleteします。
entityMgr.Remove(this);

なんだか鬱設計ですね。

**124** · 04/04/29 13:09

>>129
>>ちょっと>>124は機能とオブジェクトをいっしょにしてるのがよくなさげ。
>>EntityやRender、Collisionなんてのは明らかに
>>Characterが所有しちょるものなのでメンバでいいと思う
コリジョンや描画をメンバにするのはある程度納得出来るのですが、
自身の行動をメンバに委譲するってのはちょっとイメージが沸きません。
状態のみを委譲してそれを受けて自身の行動に変化をつけるのでしょうか？
たぶん違うぽ（つд｀）

ゲーム内に登場するオブジェクトの殆どはCCharacter派生クラスだと思うんです。
確かに画面には表示されないステージ管理クラスや当たり判定を行わないスコア表示部分などはありますが、
それらは本当に限られてくるんじゃないでしょうか。
共通のインターフェイスやリソースを含んだCCharacterを定義して全てのキャラクタをそこから派生させた方が、
より汎用性があるかなーと思った訳です。

**名前は開発中のものです。** · 04/04/29 15:51

>>132
管理クラスって作った奴が思うほど役に立たないことが多いから
もうちょっと設計考えて見た方がよくね？

>>133
>自身の行動をメンバに委譲するってのはちょっとイメージが沸きません。
どう組んでるのか詳細までは知らないけど、
結局、プロペラ付けたら空を飛んで欲しくて、車輪付けたら道を走ってほしいんでしょ？
ならそういう使い方でいいじゃない？

>共通のインターフェイスやリソースを含んだCCharacterを定義して全てのキャラクタをそこから派生させた方が、
>より汎用性があるかなーと思った訳です。
それはいいんだけど、継承を継承らしく使おうよって話なんだけど。
別にこう↓組んでも組めるっちゃあ組めると思うよ。
class CCharacter : public CEntity, public CRenderNode, public CCollisionNode {};
ただわかりづれぇって一点を除けばｗ

**名前は開発中のものです。** · 04/04/29 18:18

>>132
とりあえずそのノリなら漏れはついていけるから安心していいよ
邪道かどうかは別として、管理される側が自分を管理する側を知っているっていう
状態は改良できるとこだと思う

**名前は開発中のものです。** · 04/04/29 18:20

おまえらそんな議論は学校いってるうちにすませとけや

**名前は開発中のものです。** · 04/04/29 20:30

＞ゲームプログラミング相談室【Part6】
　　　　　　　　　　　　　　~~~~~~~~
問題は何もない。続けて良い。

**名前は開発中のものです。** · 04/04/29 21:45

邪道かどうかは別として、衝突判定が特別扱いされているのが気になる
なんでentity間のやりとりの一種として扱わないの？

**名前は開発中のものです。** · 04/04/30 02:06

>>130
スマン。やはり、CRenderNodeがどういったものか、理解せずに
答えたので、見当違いだったかも。

CRenderNodeは描画機能？をもっていて、描画する対象のインスタンスではない。
て事かな？
因みに俺はインスタンスを含むと思っていたので、あくまでも、メンバ（参照用のポインタ）という扱い。
（キャラと描画物が１対１ではないという事）

とあるミドルウェアでは、大概のクラスが、シーングラフノードの派生。という構造もあったし、
そういうのも面白いとは思うよ。

**名前は開発中のものです。** · 04/04/30 02:41

これっ

**124** · 04/04/30 04:19

>>134
>>管理クラスって作った奴が思うほど役に立たないことが多いから
全AI更新→全衝突判定→全描画
こんな感じにUpdate()やRender()ってのは一括して呼ばれるのが普通だと私は思ってます。
誰かが管理して順番に呼び出した方がスッキリしているような気がしますがどうでしょうか？

管理クラスがない場合って生成されたEntityのUpdate()はどうやって呼ばれるのだろう。
各Entityを木構造のノードにして子or兄弟のUpdate()を連鎖的に呼び出すのか、
それともリストをグローバルで持ってメインループか何処かで呼び出す？
誰かに管理させた方が不用意にノードにアクセスされないだろうしこれが普通かなーと
思ってたんですが一般的ではないんですかね。

>>結局、プロペラ付けたら空を飛んで欲しくて、車輪付けたら道を走ってほしいんでしょ？
この部分の話の流れとしてはCEntityから派生せずに
メンバとしてCEntityを持ったほうがいいよって解釈でよろしいでしょうか？
実際に移動を行う処理やアニメーションを行う処理なんかはAIと分離すべきだと思うのですが、
AIの部分をメンバに委譲して且つ自分ではUpdate()を持たないとなると
自分自身は何も行動を起こせないただの入れ物になりますよね？
うーん。

>>それはいいんだけど、継承を継承らしく使おうよって話なんだけど。
それが引っかかってたので質問した訳です。そしたらその他の部分でボロが出まくる出まくる(；´Д｀)
CRenderNodeやCCollisionNodeをメンバに持つってのはいいんですが
CEntityをメンバに持つメリットというか意味が理解できないのです。

**124** · 04/04/30 04:33

>>135
>>邪道かどうかは別として、管理される側が自分を管理する側を知っているっていう
>>状態は改良できるとこだと思う
でもリスト構造とかってそういう物ではないんですか？
ああ、ノード自身が管理クラスに登録するってのがマズイ訳ですね。
その点CEntity以外をメンバとして持った場合は
renderer.Add(this);
はアリですよね。

**124** · 04/04/30 04:35

>>135
>>邪道かどうかは別として、衝突判定が特別扱いされているのが気になる
自分の中では一括処理ってのが根底にあったので特別扱いになってます。
全ゲームオブジェクトの行動が終わってから衝突判定を一括で行うのでどうしても
管理クラスに自分を登録して後で判定を実行する必要があったんです。
Update()の中で衝突処理も行うとすればAI処理の一部として実装できますし、
自由度は増すと思いますがこれはゲームの規模や構造にもよりますよね。

**124** · 04/04/30 04:38

>>139
すみません、説明不足だったようですね。描画対象ではないです。
CRenderNodeはインターフェイスです。基本的にvirtual void Render() = 0;が定義してあるだけで、
レンダラがこれを任意のタイミングで呼び出します。
派生クラスはRender()を実装して1つもしくは複数のモデルをデバイスに対して描画してます。

**名前は開発中のものです。** · 04/04/30 05:47

>>141
>管理クラスがない場合って生成されたEntityのUpdate()はどうやって呼ばれるのだろう。
>各Entityを木構造のノードにして子or兄弟のUpdate()を連鎖的に呼び出すのか、
ん？処理の順番って基本的にこうやらないとまずくないか？
だって、親子関係では親から処理を実行していくようにしないと矛盾がおきないか？
子がワールド座標を欲しがるとき、親がすでに正しい位置に動いてくれていないと
子のワールド座標はバグるはずだけどどうよ？

>CEntityをメンバに持つメリットというか意味が理解できないのです。
俺はEntityクラスはキャラクタの行動を制御するものだと思ってたんだけど
実はただのＡＩクラスなの？

**１３５** · 04/04/30 12:37

>>142
管理される側が管理者のインスタンスを握っていて、
自分の登録と削除だけしかさせてもらえないならいいけど、
そうなってはいないでしょう？管理者を管理するクラスのために用意してある
メソッドにも自由にアクセスできるようになってしまっているはず。
インスタンスが無駄にグローバルになってるとか、
privateになっているべきメンバがpublicだったりするような程度でマズイです。
ヘッダのインクルードもクロスしてるでしょう。
そういうのはできるだけなくしていったほうがいいと思うよ。

>>143
シューティングゲームをつくってるのかな？
この衝突判定は「何に」当ったたのかみたいなことは分からなくてもいいの？
引数で衝突相手をもらうとしても、 Collide(const CollisionNode&) にならざるをえないし
これでは大抵は困ると思うけども

**124** · 04/04/30 19:52

>>145
管理クラス内にリストを持って実行順位毎に実行させるのと（現状はこれ）、
木構造にしてルートのUpdate()を呼んでやるのってのは実質的に同じだけど
木構造の方が何かと便利だよって事でしょうか。
何にせよルートノードは全ての子から見えるわけですよね？
インスタンスを晒さずに特別なアクセス関数を作るにしても
結局管理クラスと同じような存在になっていまうと思うんですがどうでしょうか？

>>実はただのＡＩクラスなの？
Entityは毎フレームUpdate()が呼ばれ続けるただのAIクラスって認識なので
EnemyはCEntityから派生させている訳です。
状態遷移や座標の更新、子entityの生成などをUpdate()内で行ってます。

**124** · 04/04/30 19:59

>>146
管理される側がインスタンスを握っているってイメージでは無いんですが、
管理クラスはシングルトンになっててほぼ全てのゲームクラスから見えてます。
単にリストのノードってのであればノードがリストのインスタンスを
知っている必要はまったく無いですが、
個が主体となるEntityでは知らないと何も出来ないですよね？
隠蔽さえ出来ればいいのであれば管理者のインスタンスを隠蔽して登録、削除は専用の
グローバルな関数経由で行うってのでも現状よりはマシなのでしょうか。

はい、シューティングです。
現状ではまさに Collide(const CollisionNode&) これですね。
CollisionNodeに相手のポインタを仕込ませているので
そのポインタ経由で相手の情報を得てますがやっぱりマズイでしょうか？

**名前は開発中のものです。** · 04/04/30 22:20

>>147
>管理クラス内にリストを持って実行順位毎に実行させるのと
この管理クラスって結局Updateを毎回読んでやるただそれだけのクラスなんだよね。
はっきりいっていらないんじゃないかなぁ。ってこと。
正直、完全自己完結処理な物体ぐらいしか恩恵が全くといっていいほどないじゃん。
一度管理クラスを捨てて１から考え直してみたらどうかな？

>Entityは毎フレームUpdate()が呼ばれ続けるただのAIクラスって認識なので
Entityクラスを継承してCharacterクラスができてるのはなんか
オブジェクト指向的にわかりにくくないか？（Ｃ＋＋の機能としてできるって意味とは別にして）
基本に戻って犬と猫は哺乳類でってところから考えると、
キャラクタはAI（脳みそ）でってなってちょっと変だ。
キャラクタは脳みそをもっていてって考えた方が綺麗に組めるんじゃないかな？

>>148
>管理クラスはシングルトンになっててほぼ全てのゲームクラスから見えてます。
こりゃグローバル変数と何も変わらないよ。
これが駄目だとわからないとなると、ちょっと修行が必要。
ちょっと面倒だけど、引数から渡すように改善できないかな？

**名前は開発中のものです。** · 04/04/30 23:35

前にも引数わたしの話がでてたけど、実際やってみるとかなりしんどかったぞ

例えば、引数を渡した関数から、他の関数を呼ぶときは同様に引数を渡さねばならない。
その関数から他の関数を呼ぶときも(以下略)
リファクタリングする度に、引数付き関数が増えていく。

さらに、引数がいらない関数から、引数がいる関数を呼ぶ必要がある時は、
呼び出し元を辿って全てを引数付き関数に変更せねばならない羽目に。
結局気づいてみると、ほとんどの関数が引数つきに。

一本の大きな関数で書ききるなら行けるが、
そうでない場合は、地獄を見ることに……

実際、引数わたしで上手く行っている人の話が聞きたい。

**名前は開発中のものです。** · 04/04/30 23:46

>>150
>例えば、引数を渡した関数から、他の関数を呼ぶときは同様に引数を渡さねばならない。
>その関数から他の関数を呼ぶときも(以下略)
>リファクタリングする度に、引数付き関数が増えていく。

漏れもハマったことあるな(w

**名前は開発中のものです。** · 04/05/01 00:08

まぁ、この辺はバランス感覚というか取捨選択になるでしょ。
何でもかんでもメッセージパッシングでやればパフォーマンス落ちるのと同じで。
　
膨大な数のインスタンスを高速処理せねばならないエンジン部に近いなら
美しさに伴う冗長性を嫌って汚いハックに走らざるを得ないし。

**名前は開発中のものです。** · 04/05/01 00:11

s/美しさ/OO的美しさ/

**名前は開発中のものです。** · 04/05/01 00:20

>>150
構造体で渡していくらか防げるかも。
でも、俺は引数増えても気にしないほうだなぁ。
DirectXがああだからしょうがないって言えばそうなんじゃない？

**名前は開発中のものです。** · 04/05/01 04:02

>>150
綺麗か汚いかじゃなくて、何を言いたいのかを考えてインターフェイスの仕様は決めるべき。
まして2chの名無しがうるさく言っていたからなんて理由では（ｒｙ

その参照の元が、そのインスタンスの一生のうちに変わる可能性があるということを示唆
するために、毎回参照を渡すようにしなさい。

その参照の元が、そのインスタンスの一生のうちに変わる可能性がないということを示唆
するために、コンストラクタで受け取り自分のメンバに格納しておくようにしなさい。

どちらが美しいとかどちらが汚いとかではない。

**名前は開発中のものです。** · 04/05/01 04:56

>>148
＞個が主体となるEntityでは知らないと何も出来ないですよね？
管理者のインスタンスで何をしたい？他entityの検索とかかな。

＞現状よりはマシなのでしょうか
インスタンスを生成した人がその人の好きな場所に登録できるのがいちばんよいよ。本当はね。

＞CollisionNodeに相手のポインタ
どういうクラスへのポインタ？

**124** · 04/05/01 06:39

>>149
そうですね。実際にコード化してみて比較しながら考えてみます。

>>キャラクタは脳みそをもっていてって考えた方が綺麗に組めるんじゃないかな？
理想はそうかもしれませんが実際キャラクタが自分の手足に命令を出したほうが
コード的に自然な作りになりませんか？
頭脳をメンバとして持った場合、親（キャラクタクラス）経由で手足クラスに命令を出す
となると複雑になりませんかね。

>こりゃグローバル変数と何も変わらないよ。
変わらないですね。
生成＆破棄が頻繁に行われるオブジェクトや状態が変化するものに関しては隠蔽すべき
だと思うんですがシステムで唯一無二の存在であろう管理クラスくらいはグローバルでも
いいと思うんですがどうでしょうか？
管理クラス的なものはそんなにポコポコ作らないでしょうし。

**124** · 04/05/01 06:42

>>150
実際それをやって幸せになりました？

**139** · 04/05/01 06:50

>>144
ああ、そんな気はしてたが、
virtual void Render() = 0;が定義してあるだけ。か。
俺ならCGameObjectてなクラス作って、メゾットにしちゃうか。
Update()も同様に。

CRenderNodeという名前は、紛らわしいね。tree構造を連想させられる。

管理クラスは、俺も用意してる。
シングルトンで、ファクトリパターンクラスの派生。

作ってるものも同じ。シューティング。
AIは用意してないけど、その辺りを用意すれば、アクションゲームもOK。
ただ、AIをハードコーディングしようとは思わないが。
ありものを作るなら、大抵、コリジョン判定、条件判定の組み合わせが違うだけだから。

**124** · 04/05/01 06:58

>>156
>>管理者のインスタンスで何をしたい？他entityの検索とかかな。
そうですね。
Entity間のやり取りでも管理者をかませた方が不正アクセスをチェック出来たり
デバッグ用のアクセスログ吐かせたり延滞メッセージ的な通知とかも出来そうだし。
仲介役が居ることのメリットはあるんじゃないかと思います。

>>どういうクラスへのポインタ？
ここで言うところのCCharacterですかね。
この部分は正直変な事になってると思います・・・。

**124** · 04/05/01 07:22

>>159
CGameObjectを管理するクラスがあってそのクラスがレンダラを持ってるんでしょうか？
例えば管理クラスが全ゲームオブジェクトのUpdate()を呼んでからレンダラの参照なんかを
Render()に渡してあげるとか。

AIはハードコーディングしてしまうかも。
部分的に再利用可能な形にする事もできるしちょっとした色付けは外部ファイルから
入力してあげれそれで十分かなーと。

**139** · 04/05/01 07:48

>>161
実際、今作ってるものには、CGameObjectというクラスはないんだけど、、。

CGameObjectもしくは、CGameObjectManagerが、必要なタイミングで
（生成時、初期化時、視界内に入ってきたとき等々）
に、描画エンジンのmanagerを使って、描画オブジェクトを生成。と。

で、擬似コード
app::Update(frame)
{
描画manager->Update( frame );
GameObjectManager->Update( frame );
}
と。
描画機能と、ゲーム（CPU）的な機能は分離してます。

**139** · 04/05/01 07:53

言葉足らずだったかな？
要するに、CGameObjectは、レンダラ機能はもたず、
レンダラがもつ描画ノードの参照を持ってるだけ。
update()時も、描画用のセットアップをしているだけ。

**名前は開発中のものです。** · 04/05/01 08:16

>>157
>頭脳をメンバとして持った場合、親（キャラクタクラス）経由で手足クラスに命令を出す
>となると複雑になりませんかね。
どうして？変わらないと思うけど。
手足クラスが何やるか知らないけど、頭脳と手足が認識できる構造なら
どういう処理にしろクラスにしちゃった方がわかりやすいじゃん。

>システムで唯一無二の存在であろう管理クラスくらいはグローバルでも
>いいと思うんですがどうでしょうか？
駄目だよ。グローバル変数が駄目な理由も理解してないな。
システムで唯一無二のものを直接コードに入れちゃうってことは
そのクラスはそこでもう身動きがとれなくなっちゃうってことだよ。
どこでもどんなタイミングでもアクセスできちゃうし、
一番怖いバグが出るパターンだよ。

**名前は開発中のものです。** · 04/05/01 10:28

>>158
なりませんでした
概念だけは美しいが、コードは美しくなく汚くなっただけ
なんだかC言語で、OOやったときのような気分

**名前は開発中のものです。** · 04/05/01 11:23

>>165
なんでそう見た目だけにかき回されるのか激しく疑問。
いくらコードが美しくたって概念が糞なら糞。
>>155のいう通りだろ。

**名前は開発中のものです。** · 04/05/01 11:31

むしろ、実装してみると、概念の方があなたの言う「見た目」に見えてくる
>>150みたになるのを防ぐ方法が挙げられなければ、
スパゲッティなコードになることを回避できない。

**名前は開発中のものです。** · 04/05/01 11:33

>むしろ、実装してみると、概念の方があなたの言う「見た目」に見えてくる
わかりにくいな

むしろ、実装してみると、概念にかき回される、と言いたい

**名前は開発中のものです。** · 04/05/01 11:42

>>167
じゃあ構造体でわたせば？（これで解決するよね？）

**名前は開発中のものです。** · 04/05/01 11:53

>>160
＞仲介役が居ることのメリットはあるんじゃないかと
なにもできないわけじゃないなら、管理される側からは管理している側が見えないように
しておいたほうがよい。管理する側の何かを変更をしたい時に、
管理される側にはその変更によって何も影響がないということを確信をもって取り組むことができる。
そのメリットの方が仲介役と管理者がいっしょにいることより大きいと思うよ。

もしも仲介役が必要ということなら仲介役クラス、というかインターフェイスをつくって
entity生成時に持たせてあげるようにしたらいい。

>>164
＞グローバル変数が駄目な理由も理解してないな。
グローバル変数は、そのクラスが変更されたとき、膨大なコードの全体に対して
影響が及んだかどうかチェックして問題がないことを確信がもてる精神力が
あるのなら使える。ぼくは精神力に自信がないのでシングル㌧をさらすことはせず
必要とされる単純な処理だけをstaticメソッドとして公開してるyo

**名前は開発中のものです。** · 04/05/01 12:28

まぁ最初はリソースやコンテクストをいちいち引数渡しする形でデザインしておいたほうがいいんじゃないか
そのクラスのそれ以外のメソッドがリソースやコンテクストなしでも動けるなら、そのほうが。
んでクラスの全部のメソッドがそのリソースやコンテクストなしでは動けないということが判明したら
コンストラクタでもらうようにしては。

**139** · 04/05/01 12:31

>>167
俺の場合、「やばい！」と感じたらｗ
とりあえず、クラスにして渡す。

作業してて「これやばいな」と感じたら、そのまま突き進まず、
別の回避策を考える事にしてる。絶対可笑しな部分があるから。

**152** · 04/05/01 13:27

>>166
というか155は抽象的極論なので一体何が言うとおりなのか理解不能です。
この際言葉遊びは捨てて（というか面倒くさいので）美しさ＝概念的合理性と
解釈てしまいますが・・・・確認なんですが
こういうものを追求することは当然なのでありますが、これらが常に計算機側の
特性とマッチするわけでない、ということはお互いの共通理解として宜しいですよね。

ゲームの場合、わりと頻繁に　この部分が絡むので論争に発展するのだと思います。
現実（ハード特性）との不整合を冷酷に示すパフォーマンスアナライザを恨めという
以外ありません。

**152** · 04/05/01 13:35

まぁ、ただ今読み返すと、ここで議論にあがってるのは
純粋に設計上の不備の部分の話なのかなぁ、とも思うので
173の内容は無粋だな。却下。

**名前は開発中のものです。** · 04/05/01 13:44

ロジックとハード特性の不整合というより、ロジックと言語仕様の不整合、かな。

**152** · 04/05/01 13:48

>>175
そんな感じですな。美しさ＝記述上の美しさ、という意味合いなら
やっぱ173は筋違いやね。

**名前は開発中のものです。** · 04/05/01 14:04

いや、俺は>>173の言ってることは当然のことなので悪いとは思わない。
ゲームにもよるが、ノードの数が物凄く多くなればキャッシュヒット
やら何やらの問題がボロボロと表出することがあるので、途中で
精度犠牲にして走査回数抑制する方向でロジックを修正することあるし。
最悪、内部データ構造から洗いなおすハメになることもあるし。

**名前は開発中のものです。** · 04/05/01 14:15

純粋にパフォーマンス上の話だと
手荷物にするか置き勉にするか、状況によっては相当違ってくるよね。

**名前は開発中のものです。** · 04/05/01 14:29

>>173
>美しさ＝概念的合理性
え？じゃあ、なんで俺にレスつけんの？
俺は
>>165の
>概念だけは美しいが、コードは美しくなく汚くなっただけ
っていう言葉に対してレスつけたんだけど。
引数で渡すことに関しては賛成ってことでいいんでしょ？

**173** · 04/05/01 14:50

概念＝抽象モデルという話なら、>>173は
抽象モデルが糞なら（結果としてそれは）糞という発想は極端だなぁ
という、やや無粋な話。

抽象モデルとして説得力のある・人の直感的に分かりやすい代物であっても
それが常にハードウェア特性との親和性を伴うわけではないならば
何が糞で何が糞でないのか、は一概には決め付けられないだろう、という話。

これは詭弁ガイドラインに抵触している気がするので、>>174で取り下げた。

**名前は開発中のものです。** · 04/05/02 00:05

スクロール処理に関して知恵をかしておくんなさい

１．２ＤのアクションＲＰＧをつくっています
２．プレイできる範囲全体を１００＊１００セルとして定義、後ろ（どっか）にもってます
３．プレイヤーの見える範囲を１０＊１０として定義、現在の座標位置より、２．でもってる内容から上下左右に１セル分多く取得してきます。
４．３．で１セル分多く取得してきているぶんをつかってプレイヤーが移動したときに、すこしずつずらしていきます
５．実際の画面への表示は、３．の内容にマスクして、１０セル分だけ表示し、スクロールにみせかけています

最初は２Ｄのスクロール処理のみを考えていたんで、この方法で、スクロール処理ができるようになってよかったんです。
が、他のプレイヤーや、キャラを追加して、そいつらの動きが入ると意味不明になってしまいました。

たとえば、プレイヤーが(x,y)=(10,10)の座標にいて、他のプレイヤーが(x,y)=(12,12)の座標にいて、
プレイヤーが(x,y)=(10,11)に移動、他のプレイヤーが(x,y)=(12,11）に移動すると
先の上で説明したような状況になったときに、どう他のプレイヤーを描画したらいいのか悩んでます

考えているつもりですが、意味不明になって悩んでしまいます

全体的な処理としては、メインのループがあって、そこで、くるくるまわして描画処理をしています。

キーボードのイベントや、マウスイベントや、ネットワークからのイベントは、別のスレッドでキューにいれて、
上のメインを回しているスレッドから読んで描画に関する処理に影響させています。

長くなってしまった上に、意味不明なことを書いているようなきがするんですが、
よかったら知恵を貸してください。

**名前は開発中のものです。** · 04/05/02 07:16

>>166みたいな、単なる貶し系の文章が書きたいだけのやつが一人いるんだよね。
それが気に入らないから俺しばらく常駐してみてるんだが。

**名前は開発中のものです。** · 04/05/02 11:23

>>181
>そいつらの動きが入ると意味不明になってしまいました。
どう上手くいかないのかわからないんだが、
とりあえず、スクロール処理の部分って
プレイヤーの現在位置から見える範囲を決めてるわけだから
他のプレイヤーってこの処理に関係ないんじゃないの？

>>182
>>182の内容が貶し系なわけだがｗ

**名前は開発中のものです。** · 04/05/02 14:39

>>181
　文章が長い割に、必要な情報が欠落している。
他のプレイヤーやキャラとはなんなのか、説明をちゃんとしろ。

**181** · 04/05/02 15:03

>>183
>>184

もうちょっとまとめてみました

プレイヤーと動かない対象（床と動いてないキャラなど）
にかんするスクロールは問題ないです

自分がスクロールしている最中に、
画面内に動く対象がいると、スクロールがうまくいかず、
飛んだみたいに見えるわけです
自分が(10,10)→(10,11)に移動し、
動く対象が(12,12)→(12,11)に移動したら、
2セルぐらい飛んだように見えるんです

また、自分が止まっている時に
画面内に動く対象がいても問題なく動いています

結果：
自分がスクロールしているときに
画面内の動く対象の描画位置を計算するルーチンがおかしい、
または、そんなルーチンが動いていないから、
飛んだように見える

あぁ、なんか解決したような兆しが見える・・・

**名前は開発中の者です。** · 04/05/02 16:53

背景に張り付いてるキャラクターが、主人公と逆に動いた場合、
倍の速度で離れていくのは、普通のことなのではないでしょうか。
ドラクエやイースもそうなってるはずですよ。

（あまり関係有りませんが）
セルという言葉を使ってるようですが、RPGツクールでいうところの
「チップ」のことでしょうか。小さい四角のことをセルというのは
PCエンジンぽいですね。でべろかなんかいじっていた人なのでしょうか。

**名前は開発中のものです。** · 04/05/02 17:07

>>185
「飛んだように見える」と言われても

**練習帳著者** · 04/05/02 17:21

>>185

スクロール時のキャラクタ描画を「現在のスクロール量（ずらして
描画しているピクセル数）を減じた座標」に対して行うようにすれ
ばよいのでは？　わかりにくければ、方眼紙に表示領域とスクロー
ル領域を描いてみて、１ピクセルずつスクロールさせるとどうなるか、
なぞってみてください。

**181** · 04/05/02 17:30

>>186
おっしゃるとおりですね。
倍速ではなれていくことを表現したいと思っています。
現状ではキャラがスクロールするというより、
飛んでるというかんじで、なんでかデバッグ中です

セルという言葉は、距離を表現するつもりでつかっています。
プログラム中では１セル中にはりつけるタイルを
チップという名前をつけています
ゲームプログラムは今回が初めてで、
詳しいこともわからず独善的に作っています
だから言葉も適当です
適切でなければ、以後、脳内で置換します

**181** · 04/05/02 17:35

>>187
そうですよね・・・。
適切な表現ができていないですよね。

>>188
すばらしいアイデアですね。
早速方眼紙にかいて試してみました。
なんか、自分のルーチンの間違いが見えてきた気がします。
サンクスです。

こーやって書いて実際に試してみるのがとても大切ですね

**181** · 04/05/02 17:55

自分の間違いがわかりました。

スクロール処理に問題があり、
>>188さんのアイデアで解決しました。
ありがとうございました。

次は、デバッグ中にわかった問題を解決していこうと思います。
自分が(10,10)にいて、動く対象が(12,12)にいて、一旦描画したとします。
その後、次の描画処理までに動く対象が(12,11)、(12,10)と移動した場合、
2セル動いているので、スクロール処理が想定している
ルーチン中で判断できず、飛んだようにみえていました。
自分の処理の中では必ず1セルしか動かないようになっていました。

これは現在作成しているプログラムで、ステップ実行などをしている際に、
動く対象が1セルずつ移動しているが、
実は2回移動して2セル動いてしまっている際に起こっているようです。

今はステップ実行などを行わない限り、こういった状況にはならないわけですが、
いずれさまざまな問題で発生する可能性があります。

で、解決案として以下を考えています。
①放置、トンでもいいじゃないか
②軌跡を事後に計算して描画処理をさせる

①でいこうと思っていますが、みなさんならどうされますか？

**名前は開発中のものです。** · 04/05/02 18:01

微分する

**181** · 04/05/02 18:07

微分して、軌跡に近いセルに描画ですか
いいアイデアですね

**名前は開発中のものです。** · 04/05/02 23:24

>>181
処理構造に問題があるんじゃないの？

移動は、そのセルとやらが何ピクセルの大きさか知らないが段階を踏んでるんだろうね？
つまり、32ピクセル x 32ピクセルの大きさなら
移動は、瞬間移動？
それとも8ピクセル程度づつスライドして滑らかに描画してる？
背景のスクロールもしかり、セル単位で瞬間移動描画してる？

というか、スクリーン描画座標と
背景セル上での座標がつじつま合ってれば、そんな問題は出ないでしょ？
どっかに構造的、発想的な問題があるんでしょ。

**181** · 04/05/02 23:43

>>194

スクロールは、1回の移動あたりが１セル（16ピクセル）
1セルあたりの移動時間を500m秒
描画時に16ピクセル＊（現在時間－移動開始時間）／1セルあたりの移動時間
としてスクロール表現のためのマージンを計算してずらす値にしています

>>どっかに構造的、発想的な問題があるんでしょ。
ありました。
自分がスクロールしている最中に、動く対象が動いた場合、
座標計算が元の位置のまま計算していたので、おかしかったです。
この問題は>>188さんのアイデアで解決しました。

**名前は開発中のものです。** · 04/05/03 00:42

＞自分がスクロールしている最中に
処理は人によって自由だけど、
普通は自分(主人公キャラでしょ？)は、MAP上を移動していて
スクロールは別処理でしょ。
つまり、スクロールがどうなってようと
キャラ(主人公だろうが、違う移動キャラだろうが)はMAP上を移動するって処理で問題でないと思うけど？
移動したMAPのセルの更にそのスクリーン座標でキャラ管理でもしてるの？

キャラのMAP上の座標(セル) ->(スクロールしてようが)-> その描画スクリーン座標って処理をかませれば？

**名前は開発中のものです。** · 04/05/03 02:17

ｃかｃ++でdirectx使ったシューティングゲームのプログラミングを
基礎から完成まで詳しく解説してたサイトがあったんですけどお気に入りを謝って消してしまって見つかりません
そこのサイトの手順にしたがって学習していくと初心者にもとてもわかりやすくかったのに…
ソースファイルをコモンファイルとかに分割する方法まで詳しく解説してくれてたサイトで
CとC++とdirectxの基礎をまなびながらシューティングゲームを作るサイトでした

gooで色々検索しましたがなにしろヒット数が多くて探しきれなかったです

もしこのようなサイトをご存知でしたらご一報お願いします

**名前は開発中のものです。** · 04/05/03 02:30

あきらめろ

**名前は開発中のものです。** · 04/05/03 07:03

Game Programming Gems 4 を読んだ人はいますか？
1とか2があればそれほど必要ではないですか？

**名前は開発中のものです。** · 04/05/03 07:52

>>198
まじでお願いします